[infinispan-dev] Infinispan URL format

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] Infinispan URL format

Tristan Tarrant-2
In the past there has been talk of representing a connection to
Infinispan using a URL, in particular for HotRod.
The Hibernate OGM team is now working on adding NoSQL datasources to
WildFly, and they've asked for they should represent connections to
various of these.

For Hot Rod:

infinispan:hotrod://[host1][:port1][,[host2][:port2]]...[/cachemanager]

The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't
currently support this, so this is forward-looking).
Obviously we will support all of the HotRod properties for specifying
things like security, etc.

For Embedded:

infinispan:embedded:file://path/to/config.xml (for specifying an
external config file)
infinispan:embedded:jndi://path/to/jndi (for referencing a cachemanager
in JNDI)
infinispan:embedded: (configuration specified as properties)

For the latter, we also need to be able to represent an infinispan
configuration using properties with a simple mapping to XML
elements/attributes, e.g.

cache-manager.local-cache.mycache.eviction.size=1000


Comments are welcome

Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan URL format

Galder Zamarreño
Comments inline:

--
Galder Zamarreño
Infinispan, Red Hat

> On 30 May 2016, at 09:46, Tristan Tarrant <[hidden email]> wrote:
>
> In the past there has been talk of representing a connection to
> Infinispan using a URL, in particular for HotRod.
> The Hibernate OGM team is now working on adding NoSQL datasources to
> WildFly, and they've asked for they should represent connections to
> various of these.

^ What's this trying to solve exactly?

> For Hot Rod:
>
> infinispan:hotrod://[host1][:port1][,[host2][:port2]]...[/cachemanager]
>
> The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't
> currently support this, so this is forward-looking).
> Obviously we will support all of the HotRod properties for specifying
> things like security, etc.

^ Hmmm, all properties? Do you envision potentially putting all HR client config inside a URL?

>
> For Embedded:
>
> infinispan:embedded:file://path/to/config.xml (for specifying an
> external config file)
> infinispan:embedded:jndi://path/to/jndi (for referencing a cachemanager
> in JNDI)
> infinispan:embedded: (configuration specified as properties)
>
> For the latter, we also need to be able to represent an infinispan
> configuration using properties with a simple mapping to XML
> elements/attributes, e.g.
>
> cache-manager.local-cache.mycache.eviction.size=1000

^ Why 'local-cache' in property name? cachemanager.mycache...etc would be enough since there can't be duplicate cache names inside a given cache manager. So, is 'local-cache' merely a hint?

Cheers,

>
>
> Comments are welcome
>
> Tristan
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan URL format

Tristan Tarrant-2
On 31/05/2016 13:33, Galder Zamarreño wrote:

> Comments inline:
>
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 30 May 2016, at 09:46, Tristan Tarrant <[hidden email]> wrote:
>>
>> In the past there has been talk of representing a connection to
>> Infinispan using a URL, in particular for HotRod.
>> The Hibernate OGM team is now working on adding NoSQL datasources to
>> WildFly, and they've asked for they should represent connections to
>> various of these.
> ^ What's this trying to solve exactly?
Similar to how a JDBC URL works, providing a convenient format for
specifying a connection to an Infinispan resource.
Look at [1]
>> For Hot Rod:
>>
>> infinispan:hotrod://[host1][:port1][,[host2][:port2]]...[/cachemanager]
>>
>> The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't
>> currently support this, so this is forward-looking).
>> Obviously we will support all of the HotRod properties for specifying
>> things like security, etc.
> ^ Hmmm, all properties? Do you envision potentially putting all HR client config inside a URL?
The use of the ?name=value[&name=value] format in the URL is not the
only way. JDBC, for example, has a separate properties param:

DriverManager.getConnection(jdbcUrl, properties);

>> For Embedded:
>>
>> infinispan:embedded:file://path/to/config.xml (for specifying an
>> external config file)
>> infinispan:embedded:jndi://path/to/jndi (for referencing a cachemanager
>> in JNDI)
>> infinispan:embedded: (configuration specified as properties)
>>
>> For the latter, we also need to be able to represent an infinispan
>> configuration using properties with a simple mapping to XML
>> elements/attributes, e.g.
>>
>> cache-manager.local-cache.mycache.eviction.size=1000
> ^ Why 'local-cache' in property name? cachemanager.mycache...etc would be enough since there can't be duplicate cache names inside a given cache manager. So, is 'local-cache' merely a hint?
This is not for connecting to an existing instance, but for actually
creating a cachemanager.

Tristan

[1] http://lists.jboss.org/pipermail/wildfly-dev/2016-May/004953.html


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan URL format

Emmanuel Bernard
In reply to this post by Galder Zamarreño

On 31 May 2016, at 13:33, Galder Zamarreño <[hidden email]> wrote:

In the past there has been talk of representing a connection to 
Infinispan using a URL, in particular for HotRod.
The Hibernate OGM team is now working on adding NoSQL datasources to 
WildFly, and they've asked for they should represent connections to 
various of these.

^ What's this trying to solve exactly?

The reasoning is as follows in a nutshell.
If Infinispan wants to be treated as a database, it needs to be friendly towards its client and offer a proper simple access. A driver + a URL scheme is a common scheme across the RDBMS and NoSQL space these days.

If we have this, then Wildfly users can start separating the data source configuration from their application deployment like they have been able to for RDBMSes (or other JCA deployment AFAIR).
The main difference is that we will not return javax.sql.DataSource objects but the natural native object of the driver. We are setting these approaches in Wildfly for various NoSQL solutions already. Infinispan is the remaining outlier.

Emmanuel

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan URL format

Paul Ferraro
In reply to this post by Tristan Tarrant-2
This also fits nicely with the JCache API, where a CacheProvider is
expected to express a connection to a CacheManager as a URI.

On Mon, May 30, 2016 at 3:46 AM, Tristan Tarrant <[hidden email]> wrote:

> In the past there has been talk of representing a connection to
> Infinispan using a URL, in particular for HotRod.
> The Hibernate OGM team is now working on adding NoSQL datasources to
> WildFly, and they've asked for they should represent connections to
> various of these.
>
> For Hot Rod:
>
> infinispan:hotrod://[host1][:port1][,[host2][:port2]]...[/cachemanager]
>
> The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't
> currently support this, so this is forward-looking).
> Obviously we will support all of the HotRod properties for specifying
> things like security, etc.
>
> For Embedded:
>
> infinispan:embedded:file://path/to/config.xml (for specifying an
> external config file)
> infinispan:embedded:jndi://path/to/jndi (for referencing a cachemanager
> in JNDI)
> infinispan:embedded: (configuration specified as properties)
>
> For the latter, we also need to be able to represent an infinispan
> configuration using properties with a simple mapping to XML
> elements/attributes, e.g.
>
> cache-manager.local-cache.mycache.eviction.size=1000
>
>
> Comments are welcome
>
> Tristan
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan URL format

Radim Vansa
In reply to this post by Galder Zamarreño
On 05/31/2016 01:33 PM, Galder Zamarreño wrote:

> Comments inline:
>
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 30 May 2016, at 09:46, Tristan Tarrant <[hidden email]> wrote:
>>
>> In the past there has been talk of representing a connection to
>> Infinispan using a URL, in particular for HotRod.
>> The Hibernate OGM team is now working on adding NoSQL datasources to
>> WildFly, and they've asked for they should represent connections to
>> various of these.
> ^ What's this trying to solve exactly?
>
>> For Hot Rod:
>>
>> infinispan:hotrod://[host1][:port1][,[host2][:port2]]...[/cachemanager]
>>
>> The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't
>> currently support this, so this is forward-looking).
>> Obviously we will support all of the HotRod properties for specifying
>> things like security, etc.
> ^ Hmmm, all properties? Do you envision potentially putting all HR client config inside a URL?
>
>> For Embedded:
>>
>> infinispan:embedded:file://path/to/config.xml (for specifying an
>> external config file)
>> infinispan:embedded:jndi://path/to/jndi (for referencing a cachemanager
>> in JNDI)
>> infinispan:embedded: (configuration specified as properties)
>>
>> For the latter, we also need to be able to represent an infinispan
>> configuration using properties with a simple mapping to XML
>> elements/attributes, e.g.
>>
>> cache-manager.local-cache.mycache.eviction.size=1000
> ^ Why 'local-cache' in property name? cachemanager.mycache...etc would be enough since there can't be duplicate cache names inside a given cache manager. So, is 'local-cache' merely a hint?

The first idea would be to make the left-hand side XPath expressions, so
it would be

cache-container[@name=myManager].local-cache[@name=myCache].eviction.size=1000

As we probably want to select only on the name attribute, this could be
sufficient and less verbose:

cache-container[myManager].local-cache[myCache].eviction.size=1000

I wouldn't mix 'schema' of the property with user-defined identifiers -
those brackets clearly separate them for good.

There are cases where you have multiple children in one element - custom
interceptors, groups, persistence (though the current schema tells me I
can have only one store defined)... and there is no clear identifier (as
cache name, or backup site). I would suggest that there a custom
identifier that is not present in configuration would help user identify
this, e.g.

cache-container[myManager].distributed-cache[myCache].persistence.store[foo].class=org.my.FooStore
cache-container[myManager].distributed-cache[myCache].persistence.store[foo].file=/some/path
cache-container[myManager].distributed-cache[myCache].persistence.store[bar].class=org.my.BarStore
cache-container[myManager].distributed-cache[myCache].persistence.store[bar].url=http://example.com

My 2c

Radim

>
> Cheers,
>
>>
>> Comments are welcome
>>
>> Tristan
>> --
>> Tristan Tarrant
>> Infinispan Lead
>> JBoss, a division of Red Hat
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan URL format

Tristan Tarrant-2
So you've been putting that XSL/Xpath knowledge to good use I see. I
like it.

Tristan

On 01/06/2016 09:02, Radim Vansa wrote:

> On 05/31/2016 01:33 PM, Galder Zamarreño wrote:
>> Comments inline:
>>
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>>> On 30 May 2016, at 09:46, Tristan Tarrant <[hidden email]> wrote:
>>>
>>> In the past there has been talk of representing a connection to
>>> Infinispan using a URL, in particular for HotRod.
>>> The Hibernate OGM team is now working on adding NoSQL datasources to
>>> WildFly, and they've asked for they should represent connections to
>>> various of these.
>> ^ What's this trying to solve exactly?
>>
>>> For Hot Rod:
>>>
>>> infinispan:hotrod://[host1][:port1][,[host2][:port2]]...[/cachemanager]
>>>
>>> The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't
>>> currently support this, so this is forward-looking).
>>> Obviously we will support all of the HotRod properties for specifying
>>> things like security, etc.
>> ^ Hmmm, all properties? Do you envision potentially putting all HR client config inside a URL?
>>
>>> For Embedded:
>>>
>>> infinispan:embedded:file://path/to/config.xml (for specifying an
>>> external config file)
>>> infinispan:embedded:jndi://path/to/jndi (for referencing a cachemanager
>>> in JNDI)
>>> infinispan:embedded: (configuration specified as properties)
>>>
>>> For the latter, we also need to be able to represent an infinispan
>>> configuration using properties with a simple mapping to XML
>>> elements/attributes, e.g.
>>>
>>> cache-manager.local-cache.mycache.eviction.size=1000
>> ^ Why 'local-cache' in property name? cachemanager.mycache...etc would be enough since there can't be duplicate cache names inside a given cache manager. So, is 'local-cache' merely a hint?
> The first idea would be to make the left-hand side XPath expressions, so
> it would be
>
> cache-container[@name=myManager].local-cache[@name=myCache].eviction.size=1000
>
> As we probably want to select only on the name attribute, this could be
> sufficient and less verbose:
>
> cache-container[myManager].local-cache[myCache].eviction.size=1000
>
> I wouldn't mix 'schema' of the property with user-defined identifiers -
> those brackets clearly separate them for good.
>
> There are cases where you have multiple children in one element - custom
> interceptors, groups, persistence (though the current schema tells me I
> can have only one store defined)... and there is no clear identifier (as
> cache name, or backup site). I would suggest that there a custom
> identifier that is not present in configuration would help user identify
> this, e.g.
>
> cache-container[myManager].distributed-cache[myCache].persistence.store[foo].class=org.my.FooStore
> cache-container[myManager].distributed-cache[myCache].persistence.store[foo].file=/some/path
> cache-container[myManager].distributed-cache[myCache].persistence.store[bar].class=org.my.BarStore
> cache-container[myManager].distributed-cache[myCache].persistence.store[bar].url=http://example.com
>
> My 2c
>
> Radim
>
>> Cheers,
>>
>>> Comments are welcome
>>>
>>> Tristan
>>> --
>>> Tristan Tarrant
>>> Infinispan Lead
>>> JBoss, a division of Red Hat
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan URL format

Sanne Grinovero-3
The implementation proposals seem slick, but I'd have some doubts
about allowing overrides to the datastore settings at this level.

The hot-rod proposal looks fine, as similarly to a RDBMs it helps to
figure how to connect to a specific database by expressing:
 - how to reach the DB
 - WHICH database you mean to connect to

In case of the proposals for Infinispan Embedded, I think we fail
these goals: you need to provide a means for multiple applications to
"connect" to the same database. So the container needs to be able to
distinguish *same* Cache instance from a different one, and this might
get complex if the URL includes a mixture of client specific settings
(i.e. how to connect) and configuration of the Cache (i.e. TTL and
CacheStore options).
It also gets messy in terms of lifecycle: do you stop the CacheManager
when the last client is undeployed?

I'd rather see an approach based on naming lookup. How the Cache is
configured, started and "bound" to that specific name should be
treated separately.

For that purpose, I think the WildFly caches configuration can be
considered the first step, and the next would be to allow a "Cache
configuration fragment" to be deployed either included with an
application, or independently from an application.

Thanks,
Sanne



On 1 June 2016 at 08:24, Tristan Tarrant <[hidden email]> wrote:

> So you've been putting that XSL/Xpath knowledge to good use I see. I
> like it.
>
> Tristan
>
> On 01/06/2016 09:02, Radim Vansa wrote:
>> On 05/31/2016 01:33 PM, Galder Zamarreño wrote:
>>> Comments inline:
>>>
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 30 May 2016, at 09:46, Tristan Tarrant <[hidden email]> wrote:
>>>>
>>>> In the past there has been talk of representing a connection to
>>>> Infinispan using a URL, in particular for HotRod.
>>>> The Hibernate OGM team is now working on adding NoSQL datasources to
>>>> WildFly, and they've asked for they should represent connections to
>>>> various of these.
>>> ^ What's this trying to solve exactly?
>>>
>>>> For Hot Rod:
>>>>
>>>> infinispan:hotrod://[host1][:port1][,[host2][:port2]]...[/cachemanager]
>>>>
>>>> The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't
>>>> currently support this, so this is forward-looking).
>>>> Obviously we will support all of the HotRod properties for specifying
>>>> things like security, etc.
>>> ^ Hmmm, all properties? Do you envision potentially putting all HR client config inside a URL?
>>>
>>>> For Embedded:
>>>>
>>>> infinispan:embedded:file://path/to/config.xml (for specifying an
>>>> external config file)
>>>> infinispan:embedded:jndi://path/to/jndi (for referencing a cachemanager
>>>> in JNDI)
>>>> infinispan:embedded: (configuration specified as properties)
>>>>
>>>> For the latter, we also need to be able to represent an infinispan
>>>> configuration using properties with a simple mapping to XML
>>>> elements/attributes, e.g.
>>>>
>>>> cache-manager.local-cache.mycache.eviction.size=1000
>>> ^ Why 'local-cache' in property name? cachemanager.mycache...etc would be enough since there can't be duplicate cache names inside a given cache manager. So, is 'local-cache' merely a hint?
>> The first idea would be to make the left-hand side XPath expressions, so
>> it would be
>>
>> cache-container[@name=myManager].local-cache[@name=myCache].eviction.size=1000
>>
>> As we probably want to select only on the name attribute, this could be
>> sufficient and less verbose:
>>
>> cache-container[myManager].local-cache[myCache].eviction.size=1000
>>
>> I wouldn't mix 'schema' of the property with user-defined identifiers -
>> those brackets clearly separate them for good.
>>
>> There are cases where you have multiple children in one element - custom
>> interceptors, groups, persistence (though the current schema tells me I
>> can have only one store defined)... and there is no clear identifier (as
>> cache name, or backup site). I would suggest that there a custom
>> identifier that is not present in configuration would help user identify
>> this, e.g.
>>
>> cache-container[myManager].distributed-cache[myCache].persistence.store[foo].class=org.my.FooStore
>> cache-container[myManager].distributed-cache[myCache].persistence.store[foo].file=/some/path
>> cache-container[myManager].distributed-cache[myCache].persistence.store[bar].class=org.my.BarStore
>> cache-container[myManager].distributed-cache[myCache].persistence.store[bar].url=http://example.com
>>
>> My 2c
>>
>> Radim
>>
>>> Cheers,
>>>
>>>> Comments are welcome
>>>>
>>>> Tristan
>>>> --
>>>> Tristan Tarrant
>>>> Infinispan Lead
>>>> JBoss, a division of Red Hat
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan URL format

Dan Berindei
+1, a URL that gives you a different CacheManager every time you use
it doesn't seem very useful.

JCache also requires the the CacheManager returned for one URL to be
more or less constant:

   * Multiple calls to this method with the same {@link URI} and
   * {@link ClassLoader} must return the same {@link CacheManager} instance,
   * except if a previously returned {@link CacheManager} has been closed.

Cheers
Dan


On Wed, Jun 1, 2016 at 12:29 PM, Sanne Grinovero <[hidden email]> wrote:

> The implementation proposals seem slick, but I'd have some doubts
> about allowing overrides to the datastore settings at this level.
>
> The hot-rod proposal looks fine, as similarly to a RDBMs it helps to
> figure how to connect to a specific database by expressing:
>  - how to reach the DB
>  - WHICH database you mean to connect to
>
> In case of the proposals for Infinispan Embedded, I think we fail
> these goals: you need to provide a means for multiple applications to
> "connect" to the same database. So the container needs to be able to
> distinguish *same* Cache instance from a different one, and this might
> get complex if the URL includes a mixture of client specific settings
> (i.e. how to connect) and configuration of the Cache (i.e. TTL and
> CacheStore options).
> It also gets messy in terms of lifecycle: do you stop the CacheManager
> when the last client is undeployed?
>
> I'd rather see an approach based on naming lookup. How the Cache is
> configured, started and "bound" to that specific name should be
> treated separately.
>
> For that purpose, I think the WildFly caches configuration can be
> considered the first step, and the next would be to allow a "Cache
> configuration fragment" to be deployed either included with an
> application, or independently from an application.
>
> Thanks,
> Sanne
>
>
>
> On 1 June 2016 at 08:24, Tristan Tarrant <[hidden email]> wrote:
>> So you've been putting that XSL/Xpath knowledge to good use I see. I
>> like it.
>>
>> Tristan
>>
>> On 01/06/2016 09:02, Radim Vansa wrote:
>>> On 05/31/2016 01:33 PM, Galder Zamarreño wrote:
>>>> Comments inline:
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Infinispan, Red Hat
>>>>
>>>>> On 30 May 2016, at 09:46, Tristan Tarrant <[hidden email]> wrote:
>>>>>
>>>>> In the past there has been talk of representing a connection to
>>>>> Infinispan using a URL, in particular for HotRod.
>>>>> The Hibernate OGM team is now working on adding NoSQL datasources to
>>>>> WildFly, and they've asked for they should represent connections to
>>>>> various of these.
>>>> ^ What's this trying to solve exactly?
>>>>
>>>>> For Hot Rod:
>>>>>
>>>>> infinispan:hotrod://[host1][:port1][,[host2][:port2]]...[/cachemanager]
>>>>>
>>>>> The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't
>>>>> currently support this, so this is forward-looking).
>>>>> Obviously we will support all of the HotRod properties for specifying
>>>>> things like security, etc.
>>>> ^ Hmmm, all properties? Do you envision potentially putting all HR client config inside a URL?
>>>>
>>>>> For Embedded:
>>>>>
>>>>> infinispan:embedded:file://path/to/config.xml (for specifying an
>>>>> external config file)
>>>>> infinispan:embedded:jndi://path/to/jndi (for referencing a cachemanager
>>>>> in JNDI)
>>>>> infinispan:embedded: (configuration specified as properties)
>>>>>
>>>>> For the latter, we also need to be able to represent an infinispan
>>>>> configuration using properties with a simple mapping to XML
>>>>> elements/attributes, e.g.
>>>>>
>>>>> cache-manager.local-cache.mycache.eviction.size=1000
>>>> ^ Why 'local-cache' in property name? cachemanager.mycache...etc would be enough since there can't be duplicate cache names inside a given cache manager. So, is 'local-cache' merely a hint?
>>> The first idea would be to make the left-hand side XPath expressions, so
>>> it would be
>>>
>>> cache-container[@name=myManager].local-cache[@name=myCache].eviction.size=1000
>>>
>>> As we probably want to select only on the name attribute, this could be
>>> sufficient and less verbose:
>>>
>>> cache-container[myManager].local-cache[myCache].eviction.size=1000
>>>
>>> I wouldn't mix 'schema' of the property with user-defined identifiers -
>>> those brackets clearly separate them for good.
>>>
>>> There are cases where you have multiple children in one element - custom
>>> interceptors, groups, persistence (though the current schema tells me I
>>> can have only one store defined)... and there is no clear identifier (as
>>> cache name, or backup site). I would suggest that there a custom
>>> identifier that is not present in configuration would help user identify
>>> this, e.g.
>>>
>>> cache-container[myManager].distributed-cache[myCache].persistence.store[foo].class=org.my.FooStore
>>> cache-container[myManager].distributed-cache[myCache].persistence.store[foo].file=/some/path
>>> cache-container[myManager].distributed-cache[myCache].persistence.store[bar].class=org.my.BarStore
>>> cache-container[myManager].distributed-cache[myCache].persistence.store[bar].url=http://example.com
>>>
>>> My 2c
>>>
>>> Radim
>>>
>>>> Cheers,
>>>>
>>>>> Comments are welcome
>>>>>
>>>>> Tristan
>>>>> --
>>>>> Tristan Tarrant
>>>>> Infinispan Lead
>>>>> JBoss, a division of Red Hat
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan URL format

Scott Marlow
In reply to this post by Tristan Tarrant-2


On 05/30/2016 03:46 AM, Tristan Tarrant wrote:

> In the past there has been talk of representing a connection to
> Infinispan using a URL, in particular for HotRod.
> The Hibernate OGM team is now working on adding NoSQL datasources to
> WildFly, and they've asked for they should represent connections to
> various of these.
>
> For Hot Rod:
>
> infinispan:hotrod://[host1][:port1][,[host2][:port2]]...[/cachemanager]
>
> The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't
> currently support this, so this is forward-looking).
> Obviously we will support all of the HotRod properties for specifying
> things like security, etc.

Once you are connected to a remote (Infinispan) database, does the
application simply use the java.util.Map api to put/get any application
get values?  Or are puts not allowed to use application classes?  I'm
trying to better understand how the marshaling works, since the remote
Infinispan database probably wouldn't have access to the application
classloader (unless it does, which I'd like to also understand).

>
> For Embedded:
>
> infinispan:embedded:file://path/to/config.xml (for specifying an
> external config file)
> infinispan:embedded:jndi://path/to/jndi (for referencing a cachemanager
> in JNDI)
> infinispan:embedded: (configuration specified as properties)
>
> For the latter, we also need to be able to represent an infinispan
> configuration using properties with a simple mapping to XML
> elements/attributes, e.g.
>
> cache-manager.local-cache.mycache.eviction.size=1000
>
>
> Comments are welcome
>
> Tristan
>
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan URL format

Emmanuel Bernard
On Wed 2016-06-01  9:31, Scott Marlow wrote:

> > The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't
> > currently support this, so this is forward-looking).
> > Obviously we will support all of the HotRod properties for specifying
> > things like security, etc.
>
> Once you are connected to a remote (Infinispan) database, does the
> application simply use the java.util.Map api to put/get any application
> get values?  Or are puts not allowed to use application classes?  I'm
> trying to better understand how the marshaling works, since the remote
> Infinispan database probably wouldn't have access to the application
> classloader (unless it does, which I'd like to also understand).

Scott, the application receives Infinspan's CacheManager and/or Cache
APIs just like in the Mongo case, one receives the Mongo specific
objects.
As far as the objects you can put in the cache: the ideal situation is
that you use a protobuf schema and the client side will marshall things
as protobuf and send these protobuf structure to the server. The server
then does not need to have the client classes in its classpath.
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Infinispan URL format

Sebastian Laskawiec
In reply to this post by Tristan Tarrant-2
Hi Tristan!

Multi tenancy is more an endpoint thing. If you look into the Configuration part of the design [1] you might notice that I'm actually routing between "hotrod-connector"s (which means between ProtocolServer instances). 

So to be consistent I believe the [/cachemanager] part should be mapped to the name used in hotrod-connector. Here is an example to make is more clear:
<hotrod-connector name="hotrod1" cache-container="default">
      ...
</hotrod-connector>
<hotrod-connector name="hotrod2" cache-container="default">
   ...
</hotrod-connector>

With the above configuration we will need the following URIs:
  • infinispan:hotrod://[host1][:port1][,[host2][:port2]].../hotrod1
  • infinispan:hotrod://[host1][:port1][,[host2][:port2]].../hotrod2
Thanks
Sebastian


On Mon, May 30, 2016 at 9:46 AM, Tristan Tarrant <[hidden email]> wrote:
In the past there has been talk of representing a connection to
Infinispan using a URL, in particular for HotRod.
The Hibernate OGM team is now working on adding NoSQL datasources to
WildFly, and they've asked for they should represent connections to
various of these.

For Hot Rod:

infinispan:hotrod://[host1][:port1][,[host2][:port2]]...[/cachemanager]

The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't
currently support this, so this is forward-looking).
Obviously we will support all of the HotRod properties for specifying
things like security, etc.

For Embedded:

infinispan:embedded:file://path/to/config.xml (for specifying an
external config file)
infinispan:embedded:jndi://path/to/jndi (for referencing a cachemanager
in JNDI)
infinispan:embedded: (configuration specified as properties)

For the latter, we also need to be able to represent an infinispan
configuration using properties with a simple mapping to XML
elements/attributes, e.g.

cache-manager.local-cache.mycache.eviction.size=1000


Comments are welcome

Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev