5:34 p.m.
Hi all,
In AS 7.0, only the those cache store implementations packaged in
infinispan-core were usable by default. While the Infinispan subsystem
schema allowed users to use any cache store implementation (via <store
class="..."/>), they need to manually add the relevant jars to the
org.infinispan module, and update the module.xml file accordingly so
that the subsystem's module classloader is aware of these cache store
classes.
To simplify the use of other common cache store implementations, I'm in
the process of working on the following jira, which aims to include the
jdbc, remote, and cloud cache store jars in the org.infinispan module by
default:
https://issues.jboss.org/browse/AS7-1713
As well as including the relevant jars, we would also like to simplify
their definition (like we did for <file-store/>, such that users don't
need to specify class names, provide as many sensible defaults as
possible, and take care of any required service dependencies.
I've created a draft of what I thought could be workable schema for the
remote and jdbc cache stores and would like some feedback.
The amended Infinispan subsystem schema can be found here:
https://github.com/pferraro/jboss-as/blob/master/build/src/main/resources...
For the jdbc cache stores, which come in 3 flavors, I've consolidated
them into a single configuration element <jdbc-store/>, where the
variant is implied the defined tables. After providing default values
for all the required fields, we arrive at the following minimal
configuration:
e.g.
<jdbc-store datasource="java:jboss/jdbc/somedatabase"/>
I started with the assumption that the database resource will always
come from an AS-managed DataSource.
To use a string-based jdbc store, we specify the type of table to use:
e.g.
<jdbc-store datasource="java:jboss/jdbc/somedatabase">
<entry-table/>
</jdbc-store>
Likewise, if we want to use a binary jdbc store:
e.g.
<jdbc-store datasource="java:jboss/jdbc/somedatabase">
<bucket-table/>
</jdbc-store>
Using both <entry-table/> and <bucket-table/> (or neither) indicates the
use of a mixed jdbc store.
The tables themselves are fully customizable (shown with their default
values):
e.g.
<jdbc-store datasource="java:jboss/jdbc/somedatabase">
<bucket-table prefix="ispn_bucket" batch-size="100"
fetch-size="100">
<id-column name="id" type="VARCHAR"/>
<data-column name="datum" type="BINARY"/>
<timestamp-column name="version" type="BIGINT"/>
</bucket-table>
<entry-table prefix="ispn_entry" batch-size="100"
fetch-size="100">
<id-column name="id" type="VARCHAR"/>
<data-column name="datum" type="BINARY"/>
<timestamp-column name="version" type="BIGINT"/>
</entry-table>
</jdbc-store>
The schema for the remote cache store is far simpler. You can specify a
specific remote cache name, server list, and hot rod client properties
are directly enumerated:
e.g.
<remote-store cache="some-named-cache"
servers="127.0.0.1:11311">
<property
name="infinispan.client.hotrod.request_balancing_strategy">...</property>
</remote-store>
If the cache attribute is omitted, we assume the default cache is to be
used.
Unfortunately, there doesn't seem to be a way to integrate the thread
pools used by RemoteCache/RemoteCacheManager with the AS7 threading
subsystem. In order to do this, RemoteCacheStoreConfig would need
methods for providing ExecutorFactory implementations, similar to the
way GlobalConfiguration works.
I haven't started on the cloud-based store yet, as it's kind of a
dependency nightmare.
Thoughts?
Paul
6:18 p.m.
On 09/15/2011 05:34 PM, Paul Ferraro wrote:
I've created a draft of what I thought could be workable schema
for the
remote and jdbc cache stores and would like some feedback.
The amended Infinispan subsystem schema can be found here:
https://github.com/pferraro/jboss-as/blob/master/build/src/main/resources...
For the jdbc cache stores, which come in 3 flavors, I've consolidated
Looks good. We need to document how a user can specify a custom key
mapper. Would this be in the documentation annotation of the
<jdbc-store> or provided elsewhere ?
The schema for the remote cache store is far simpler. You can
specify a
specific remote cache name, server list, and hot rod client properties
are directly enumerated:
e.g.
<remote-store cache="some-named-cache"
servers="127.0.0.1:11311">
<property
name="infinispan.client.hotrod.request_balancing_strategy">...</property>
</remote-store>
I see that you also exposed tcp_no_delay and socket_timeout
in your
latest code. Good.
I haven't started on the cloud-based store yet, as it's kind
of a
dependency nightmare.
Do we really want to include the low-level cloud
implementations as part
of AS7 ? We don't provide JDBC drivers.
Tristan
7:08 p.m.
----- Original Message -----
From: "Tristan Tarrant" <ttarrant(a)redhat.com>
To: infinispan-dev(a)lists.jboss.org
Sent: Thursday, September 15, 2011 12:18:59 PM
Subject: Re: [infinispan-dev] Request for feedback on cache store support in AS7
Infinispan subsystem
On 09/15/2011 05:34 PM, Paul Ferraro wrote:
> I've created a draft of what I thought could be workable schema for
> the
> remote and jdbc cache stores and would like some feedback.
>
> The amended Infinispan subsystem schema can be found here:
>
https://github.com/pferraro/jboss-as/blob/master/build/src/main/resources...
>
> For the jdbc cache stores, which come in 3 flavors, I've
> consolidated
Looks good. We need to document how a user can specify a custom key
mapper. Would this be in the documentation annotation of the
<jdbc-store> or provided elsewhere ?
The procedure for using a custom key mapper:
1. Add the following property to the <jdbc-store/>:
<property
name="key2StringMapper">class.name.of.key.mapper</property>
2. Add the jar file containing the above class and its dependencies to:
$JBOSS_HOME/modules/org/infinispan/main/.
3. Edit $JBOSS_HOME/modules/org/infinispan/main/modules.xml and add a reference to the jar
within <resources/>.
I'll make sure this gets added to the docs.
> The schema for the remote cache store is far simpler. You can
> specify a
> specific remote cache name, server list, and hot rod client
> properties
> are directly enumerated:
> e.g.
> <remote-store cache="some-named-cache"
servers="127.0.0.1:11311">
> <property
>
name="infinispan.client.hotrod.request_balancing_strategy">...</property>
> </remote-store>
I see that you also exposed tcp_no_delay and socket_timeout in your
latest code. Good.
Yep, those attributes are optional, whereas servers is required.
> I haven't started on the cloud-based store yet, as it's
kind of a
> dependency nightmare.
Do we really want to include the low-level cloud implementations as
part
of AS7 ? We don't provide JDBC drivers.
There are only 4, right?
We can certainly instruct users on the procedure to add the relevant cloud provider jar to
the jclouds module.
Tristan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:50 a.m.
On 09/15/2011 07:08 PM, Paul Ferraro wrote:
The procedure for using a custom key mapper:
1. Add the following property to the<jdbc-store/>:
<property
name="key2StringMapper">class.name.of.key.mapper</property>
2. Add the jar file containing the above class and its dependencies to:
$JBOSS_HOME/modules/org/infinispan/main/.
3. Edit $JBOSS_HOME/modules/org/infinispan/main/modules.xml and add a reference to the
jar within<resources/>.
I'll make sure this gets added to the docs.
I was thinking if there could be a better/simpler way and allow users to
deploy key2stringmappers in the same way that jdbc drivers are deployed:
by placing a jar with an appropriate
META-INF/services/org.infinispan.loaders.keymappers.Key2StringMapper in
the deployments dir.
What do you think ?
Tristan
9:56 a.m.
On 16 September 2011 09:50, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
On 09/15/2011 07:08 PM, Paul Ferraro wrote:
> The procedure for using a custom key mapper:
> 1. Add the following property to the<jdbc-store/>:
> <property
name="key2StringMapper">class.name.of.key.mapper</property>
> 2. Add the jar file containing the above class and its dependencies to:
> $JBOSS_HOME/modules/org/infinispan/main/.
> 3. Edit $JBOSS_HOME/modules/org/infinispan/main/modules.xml and add a reference to
the jar within<resources/>.
>
> I'll make sure this gets added to the docs.
>
I was thinking if there could be a better/simpler way and allow users to
deploy key2stringmappers in the same way that jdbc drivers are deployed:
by placing a jar with an appropriate
META-INF/services/org.infinispan.loaders.keymappers.Key2StringMapper in
the deployments dir.
What do you think ?
I'd love that. The problem is that the Key2StringMapper
implementations would need to depend on the key types they where
designed for.
Sanne
10:07 a.m.
On 09/16/2011 09:56 AM, Sanne Grinovero wrote:
On 16 September 2011 09:50, Tristan
Tarrant<ttarrant(a)redhat.com> wrote:
> I was thinking if there could be a better/simpler way and allow users to
> deploy key2stringmappers in the same way that jdbc drivers are deployed:
> by placing a jar with an appropriate
> META-INF/services/org.infinispan.loaders.keymappers.Key2StringMapper in
> the deployments dir.
>
> What do you think ?
I'd love that. The problem is that the Key2StringMapper
implementations would need to depend on the key types they where
designed for.
That would be a problem when deploying via the module method too,
wouldn't it ? You'd have to decouple the classes that make up your key
out of your application...
Tristan
10:10 a.m.
On 16 September 2011 10:07, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
On 09/16/2011 09:56 AM, Sanne Grinovero wrote:
> On 16 September 2011 09:50, Tristan Tarrant<ttarrant(a)redhat.com> wrote:
>
>> I was thinking if there could be a better/simpler way and allow users to
>> deploy key2stringmappers in the same way that jdbc drivers are deployed:
>> by placing a jar with an appropriate
>> META-INF/services/org.infinispan.loaders.keymappers.Key2StringMapper in
>> the deployments dir.
>>
>> What do you think ?
> I'd love that. The problem is that the Key2StringMapper
> implementations would need to depend on the key types they where
> designed for.
>
That would be a problem when deploying via the module method too,
wouldn't it ? You'd have to decouple the classes that make up your key
out of your application...
Yes: let's talk about ISPN-1224 next week :)
Sanne
4:58 p.m.
----- Original Message -----
From: "Tristan Tarrant" <ttarrant(a)redhat.com>
To: infinispan-dev(a)lists.jboss.org
Sent: Friday, September 16, 2011 4:07:23 AM
Subject: Re: [infinispan-dev] Request for feedback on cache store support in AS7
Infinispan subsystem
On 09/16/2011 09:56 AM, Sanne Grinovero wrote:
> On 16 September 2011 09:50, Tristan Tarrant<ttarrant(a)redhat.com>
> wrote:
>
>> I was thinking if there could be a better/simpler way and allow
>> users to
>> deploy key2stringmappers in the same way that jdbc drivers are
>> deployed:
>> by placing a jar with an appropriate
>> META-INF/services/org.infinispan.loaders.keymappers.Key2StringMapper
>> in
>> the deployments dir.
>>
>> What do you think ?
> I'd love that. The problem is that the Key2StringMapper
> implementations would need to depend on the key types they where
> designed for.
>
That would be a problem when deploying via the module method too,
wouldn't it ? You'd have to decouple the classes that make up your key
out of your application...
The other complication this introduces is that the Infinispan API would have to be exposed
by default, i.e. available to the application classloader the same way javax.sql, and all
spec apis are.
9:46 a.m.
On Sep 15, 2011, at 6:18 PM, Tristan Tarrant wrote:
On 09/15/2011 05:34 PM, Paul Ferraro wrote:
> I've created a draft of what I thought could be workable schema for the
> remote and jdbc cache stores and would like some feedback.
>
> The amended Infinispan subsystem schema can be found here:
>
https://github.com/pferraro/jboss-as/blob/master/build/src/main/resources...
>
> For the jdbc cache stores, which come in 3 flavors, I've consolidated
Looks good. We need to document how a user can specify a custom key
mapper. Would this be in the documentation annotation of the
<jdbc-store> or provided elsewhere ?
> The schema for the remote cache store is far simpler. You can specify a
> specific remote cache name, server list, and hot rod client properties
> are directly enumerated:
> e.g.
> <remote-store cache="some-named-cache"
servers="127.0.0.1:11311">
> <property
name="infinispan.client.hotrod.request_balancing_strategy">...</property>
> </remote-store>
I see that you also exposed tcp_no_delay and socket_timeout in your
latest code. Good.
> I haven't started on the cloud-based store yet, as it's kind of a
> dependency nightmare.
Do we really want to include the low-level cloud implementations as part
of AS7 ? We don't provide JDBC drivers.
Even before you go into cloud implementations, JClouds' dependency list is huge...
Tristan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
9:49 a.m.
On Sep 15, 2011, at 5:34 PM, Paul Ferraro wrote:
</snip>
The amended Infinispan subsystem schema can be found here:
https://github.com/pferraro/jboss-as/blob/master/build/src/main/resources...
Hmmm, is the xsd meant to show the new changes? I only see custom and file store in there
For the jdbc cache stores, which come in 3 flavors, I've consolidated
them into a single configuration element <jdbc-store/>, where the
variant is implied the defined tables. After providing default values
for all the required fields, we arrive at the following minimal
configuration:
e.g.
<jdbc-store datasource="java:jboss/jdbc/somedatabase"/>
I started with the assumption that the database resource will always
come from an AS-managed DataSource.
To use a string-based jdbc store, we specify the type of table to use:
e.g.
<jdbc-store datasource="java:jboss/jdbc/somedatabase">
<entry-table/>
</jdbc-store>
Likewise, if we want to use a binary jdbc store:
e.g.
<jdbc-store datasource="java:jboss/jdbc/somedatabase">
<bucket-table/>
</jdbc-store>
Using both <entry-table/> and <bucket-table/> (or neither) indicates the
use of a mixed jdbc store.
The tables themselves are fully customizable (shown with their default
values):
e.g.
<jdbc-store datasource="java:jboss/jdbc/somedatabase">
<bucket-table prefix="ispn_bucket" batch-size="100"
fetch-size="100">
<id-column name="id" type="VARCHAR"/>
<data-column name="datum" type="BINARY"/>
<timestamp-column name="version" type="BIGINT"/>
</bucket-table>
<entry-table prefix="ispn_entry" batch-size="100"
fetch-size="100">
<id-column name="id" type="VARCHAR"/>
<data-column name="datum" type="BINARY"/>
<timestamp-column name="version" type="BIGINT"/>
</entry-table>
</jdbc-store>
Sounds good.
The schema for the remote cache store is far simpler. You can
specify a
specific remote cache name, server list, and hot rod client properties
are directly enumerated:
e.g.
<remote-store cache="some-named-cache"
servers="127.0.0.1:11311">
<property
name="infinispan.client.hotrod.request_balancing_strategy">...</property>
</remote-store>
If the cache attribute is omitted, we assume the default cache is to be
used.
Unfortunately, there doesn't seem to be a way to integrate the thread
pools used by RemoteCache/RemoteCacheManager with the AS7 threading
subsystem. In order to do this, RemoteCacheStoreConfig would need
methods for providing ExecutorFactory implementations, similar to the
way GlobalConfiguration works.
Hmmm, mind creating a JIRA on this? The HotRod client should be play nicely to allow
executor factories to be injected.
I haven't started on the cloud-based store yet, as it's kind of a
dependency nightmare.
I know, jclouds' dependency list is huge :(
If Adrian is listening, any chance of somehow reducing it? Otherwise, I think he should be
in JUDCon (if not in JavaOne earlier), so I'll try to grab him there :)
Thoughts?
Paul
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
4:48 p.m.
New subject: Request for feedback on cache store support in AS7 Infinispan subsystem
----- Original Message -----
From: "Galder Zamarreño" <galder(a)redhat.com>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Sent: Friday, September 16, 2011 3:49:32 AM
Subject: Re: [infinispan-dev] Request for feedback on cache store support in AS7
Infinispan subsystem
On Sep 15, 2011, at 5:34 PM, Paul Ferraro wrote:
> </snip>
>
> The amended Infinispan subsystem schema can be found here:
>
https://github.com/pferraro/jboss-as/blob/master/build/src/main/resources...
Hmmm, is the xsd meant to show the new changes? I only see custom and
file store in there
Oops - wrong branch:
Here's the correct link to the updated xsd:
https://github.com/pferraro/jboss-as/blob/infinispan/build/src/main/resou...
> For the jdbc cache stores, which come in 3 flavors, I've
> consolidated
> them into a single configuration element <jdbc-store/>, where the
> variant is implied the defined tables. After providing default
> values
> for all the required fields, we arrive at the following minimal
> configuration:
> e.g.
> <jdbc-store datasource="java:jboss/jdbc/somedatabase"/>
>
> I started with the assumption that the database resource will always
> come from an AS-managed DataSource.
>
> To use a string-based jdbc store, we specify the type of table to
> use:
> e.g.
>
> <jdbc-store datasource="java:jboss/jdbc/somedatabase">
> <entry-table/>
> </jdbc-store>
>
> Likewise, if we want to use a binary jdbc store:
> e.g.
> <jdbc-store datasource="java:jboss/jdbc/somedatabase">
> <bucket-table/>
> </jdbc-store>
>
> Using both <entry-table/> and <bucket-table/> (or neither) indicates
> the
> use of a mixed jdbc store.
>
> The tables themselves are fully customizable (shown with their
> default
> values):
> e.g.
> <jdbc-store datasource="java:jboss/jdbc/somedatabase">
> <bucket-table prefix="ispn_bucket" batch-size="100"
> fetch-size="100">
> <id-column name="id" type="VARCHAR"/>
> <data-column name="datum" type="BINARY"/>
> <timestamp-column name="version" type="BIGINT"/>
> </bucket-table>
> <entry-table prefix="ispn_entry" batch-size="100"
fetch-size="100">
> <id-column name="id" type="VARCHAR"/>
> <data-column name="datum" type="BINARY"/>
> <timestamp-column name="version" type="BIGINT"/>
> </entry-table>
> </jdbc-store>
Sounds good.
> The schema for the remote cache store is far simpler. You can
> specify a
> specific remote cache name, server list, and hot rod client
> properties
> are directly enumerated:
> e.g.
> <remote-store cache="some-named-cache"
servers="127.0.0.1:11311">
> <property
>
name="infinispan.client.hotrod.request_balancing_strategy">...</property>
> </remote-store>
>
> If the cache attribute is omitted, we assume the default cache is to
> be
> used.
>
> Unfortunately, there doesn't seem to be a way to integrate the
> thread
> pools used by RemoteCache/RemoteCacheManager with the AS7 threading
> subsystem. In order to do this, RemoteCacheStoreConfig would need
> methods for providing ExecutorFactory implementations, similar to
> the
> way GlobalConfiguration works.
Hmmm, mind creating a JIRA on this? The HotRod client should be play
nicely to allow executor factories to be injected.
https://issues.jboss.org/browse/ISPN-1389
>
> I haven't started on the cloud-based store yet, as it's kind of a
> dependency nightmare.
I know, jclouds' dependency list is huge :(
If Adrian is listening, any chance of somehow reducing it? Otherwise,
I think he should be in JUDCon (if not in JavaOne earlier), so I'll
try to grab him there :)
>
> Thoughts?
>
> Paul
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
1:55 p.m.
Looks good, but one concern I have is that this config schema uses different terms from
what Infinispan uses and can lead to confusion. Pete, Tristan and I were talking about
converging EAP/EDG schemas for Infinispan with Infinispan's upstream schemas at some
point, but until then, perhaps a document mapping the equivalents could be helpful for
users trying to configure stuff.
On 15 Sep 2011, at 16:34, Paul Ferraro wrote:
Hi all,
In AS 7.0, only the those cache store implementations packaged in
infinispan-core were usable by default. While the Infinispan subsystem
schema allowed users to use any cache store implementation (via <store
class="..."/>), they need to manually add the relevant jars to the
org.infinispan module, and update the module.xml file accordingly so
that the subsystem's module classloader is aware of these cache store
classes.
To simplify the use of other common cache store implementations, I'm in
the process of working on the following jira, which aims to include the
jdbc, remote, and cloud cache store jars in the org.infinispan module by
default:
https://issues.jboss.org/browse/AS7-1713
As well as including the relevant jars, we would also like to simplify
their definition (like we did for <file-store/>, such that users don't
need to specify class names, provide as many sensible defaults as
possible, and take care of any required service dependencies.
I've created a draft of what I thought could be workable schema for the
remote and jdbc cache stores and would like some feedback.
The amended Infinispan subsystem schema can be found here:
https://github.com/pferraro/jboss-as/blob/master/build/src/main/resources...
For the jdbc cache stores, which come in 3 flavors, I've consolidated
them into a single configuration element <jdbc-store/>, where the
variant is implied the defined tables. After providing default values
for all the required fields, we arrive at the following minimal
configuration:
e.g.
<jdbc-store datasource="java:jboss/jdbc/somedatabase"/>
I started with the assumption that the database resource will always
come from an AS-managed DataSource.
To use a string-based jdbc store, we specify the type of table to use:
e.g.
<jdbc-store datasource="java:jboss/jdbc/somedatabase">
<entry-table/>
</jdbc-store>
Likewise, if we want to use a binary jdbc store:
e.g.
<jdbc-store datasource="java:jboss/jdbc/somedatabase">
<bucket-table/>
</jdbc-store>
Using both <entry-table/> and <bucket-table/> (or neither) indicates the
use of a mixed jdbc store.
The tables themselves are fully customizable (shown with their default
values):
e.g.
<jdbc-store datasource="java:jboss/jdbc/somedatabase">
<bucket-table prefix="ispn_bucket" batch-size="100"
fetch-size="100">
<id-column name="id" type="VARCHAR"/>
<data-column name="datum" type="BINARY"/>
<timestamp-column name="version" type="BIGINT"/>
</bucket-table>
<entry-table prefix="ispn_entry" batch-size="100"
fetch-size="100">
<id-column name="id" type="VARCHAR"/>
<data-column name="datum" type="BINARY"/>
<timestamp-column name="version" type="BIGINT"/>
</entry-table>
</jdbc-store>
The schema for the remote cache store is far simpler. You can specify a
specific remote cache name, server list, and hot rod client properties
are directly enumerated:
e.g.
<remote-store cache="some-named-cache"
servers="127.0.0.1:11311">
<property
name="infinispan.client.hotrod.request_balancing_strategy">...</property>
</remote-store>
If the cache attribute is omitted, we assume the default cache is to be
used.
Unfortunately, there doesn't seem to be a way to integrate the thread
pools used by RemoteCache/RemoteCacheManager with the AS7 threading
subsystem. In order to do this, RemoteCacheStoreConfig would need
methods for providing ExecutorFactory implementations, similar to the
way GlobalConfiguration works.
I haven't started on the cloud-based store yet, as it's kind of a
dependency nightmare.
Thoughts?
Paul
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
5:51 p.m.
I've raised this as a global issue across JBoss projects/products with the relevant
groups internally at JBoss, as I believe that we will hit this problem elsewhere.
I think a mapping document is a good first step. I'll raise this with Misha who is
providing docs support for EDG.
On 16 Sep 2011, at 07:55, Manik Surtani wrote:
Looks good, but one concern I have is that this config schema uses
different terms from what Infinispan uses and can lead to confusion. Pete, Tristan and I
were talking about converging EAP/EDG schemas for Infinispan with Infinispan's
upstream schemas at some point, but until then, perhaps a document mapping the equivalents
could be helpful for users trying to configure stuff.
On 15 Sep 2011, at 16:34, Paul Ferraro wrote:
> Hi all,
>
> In AS 7.0, only the those cache store implementations packaged in
> infinispan-core were usable by default. While the Infinispan subsystem
> schema allowed users to use any cache store implementation (via <store
> class="..."/>), they need to manually add the relevant jars to the
> org.infinispan module, and update the module.xml file accordingly so
> that the subsystem's module classloader is aware of these cache store
> classes.
>
> To simplify the use of other common cache store implementations, I'm in
> the process of working on the following jira, which aims to include the
> jdbc, remote, and cloud cache store jars in the org.infinispan module by
> default:
> https://issues.jboss.org/browse/AS7-1713
>
> As well as including the relevant jars, we would also like to simplify
> their definition (like we did for <file-store/>, such that users don't
> need to specify class names, provide as many sensible defaults as
> possible, and take care of any required service dependencies.
>
> I've created a draft of what I thought could be workable schema for the
> remote and jdbc cache stores and would like some feedback.
>
> The amended Infinispan subsystem schema can be found here:
>
https://github.com/pferraro/jboss-as/blob/master/build/src/main/resources...
>
> For the jdbc cache stores, which come in 3 flavors, I've consolidated
> them into a single configuration element <jdbc-store/>, where the
> variant is implied the defined tables. After providing default values
> for all the required fields, we arrive at the following minimal
> configuration:
> e.g.
> <jdbc-store datasource="java:jboss/jdbc/somedatabase"/>
>
> I started with the assumption that the database resource will always
> come from an AS-managed DataSource.
>
> To use a string-based jdbc store, we specify the type of table to use:
> e.g.
>
> <jdbc-store datasource="java:jboss/jdbc/somedatabase">
> <entry-table/>
> </jdbc-store>
>
> Likewise, if we want to use a binary jdbc store:
> e.g.
> <jdbc-store datasource="java:jboss/jdbc/somedatabase">
> <bucket-table/>
> </jdbc-store>
>
> Using both <entry-table/> and <bucket-table/> (or neither) indicates the
> use of a mixed jdbc store.
>
> The tables themselves are fully customizable (shown with their default
> values):
> e.g.
> <jdbc-store datasource="java:jboss/jdbc/somedatabase">
> <bucket-table prefix="ispn_bucket" batch-size="100"
fetch-size="100">
> <id-column name="id" type="VARCHAR"/>
> <data-column name="datum" type="BINARY"/>
> <timestamp-column name="version" type="BIGINT"/>
> </bucket-table>
> <entry-table prefix="ispn_entry" batch-size="100"
fetch-size="100">
> <id-column name="id" type="VARCHAR"/>
> <data-column name="datum" type="BINARY"/>
> <timestamp-column name="version" type="BIGINT"/>
> </entry-table>
> </jdbc-store>
>
>
> The schema for the remote cache store is far simpler. You can specify a
> specific remote cache name, server list, and hot rod client properties
> are directly enumerated:
> e.g.
> <remote-store cache="some-named-cache"
servers="127.0.0.1:11311">
> <property
name="infinispan.client.hotrod.request_balancing_strategy">...</property>
> </remote-store>
>
> If the cache attribute is omitted, we assume the default cache is to be
> used.
>
> Unfortunately, there doesn't seem to be a way to integrate the thread
> pools used by RemoteCache/RemoteCacheManager with the AS7 threading
> subsystem. In order to do this, RemoteCacheStoreConfig would need
> methods for providing ExecutorFactory implementations, similar to the
> way GlobalConfiguration works.
>
> I haven't started on the cloud-based store yet, as it's kind of a
> dependency nightmare.
>
> Thoughts?
>
> Paul
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:50 p.m.
On 16 Sep 2011, at 16:51, Pete Muir wrote:
I've raised this as a global issue across JBoss projects/products
with the relevant groups internally at JBoss, as I believe that we will hit this problem
elsewhere.
+1
I think a mapping document is a good first step. I'll raise this
with Misha who is providing docs support for EDG.
and +1 again. :)
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
10:46 a.m.
On Fri, 2011-09-16 at 17:50 +0100, Manik Surtani wrote:
On 16 Sep 2011, at 16:51, Pete Muir wrote:
> I've raised this as a global issue across JBoss projects/products with the
relevant groups internally at JBoss, as I believe that we will hit this problem
elsewhere.
+1
> I think a mapping document is a good first step. I'll raise this with Misha who
is providing docs support for EDG.
and +1 again. :)
FYI, Michal has already created such a document on docspace (does not
contain those last cache store changes):
https://docspace.corp.redhat.com/docs/DOC-69249
This can save time when writing the mapping document.
M.
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Martin Gencur
--
JBoss QE, Enterprise Data Grid
Desk phone: +420 532 294 192, ext. 62192
8:29 p.m.
New subject: Request for feedback on cache store support in AS7 Infinispan subsystem
On a separate thread, Michal, Rado and I were discussing that alignment of schema should
be a high priority item during upcoming f2F meeting. Some of problems that we have found
has been result of Infinispan subsystem in AS7 not honoring some configuration. It will be
good to see less of those. :-)
----- Original Message -----
| I've raised this as a global issue across JBoss projects/products with
| the relevant groups internally at JBoss, as I believe that we will hit
| this problem elsewhere.
|
| I think a mapping document is a good first step. I'll raise this with
| Misha who is providing docs support for EDG.
|
| On 16 Sep 2011, at 07:55, Manik Surtani wrote:
|
| > Looks good, but one concern I have is that this config schema uses
| > different terms from what Infinispan uses and can lead to confusion.
| > Pete, Tristan and I were talking about converging EAP/EDG schemas
| > for Infinispan with Infinispan's upstream schemas at some point, but
| > until then, perhaps a document mapping the equivalents could be
| > helpful for users trying to configure stuff.
| >
| >
| > On 15 Sep 2011, at 16:34, Paul Ferraro wrote:
| >
| >> Hi all,
| >>
| >> In AS 7.0, only the those cache store implementations packaged in
| >> infinispan-core were usable by default. While the Infinispan
| >> subsystem
| >> schema allowed users to use any cache store implementation (via
| >> <store
| >> class="..."/>), they need to manually add the relevant jars to
the
| >> org.infinispan module, and update the module.xml file accordingly
| >> so
| >> that the subsystem's module classloader is aware of these cache
| >> store
| >> classes.
| >>
| >> To simplify the use of other common cache store implementations,
| >> I'm in
| >> the process of working on the following jira, which aims to include
| >> the
| >> jdbc, remote, and cloud cache store jars in the org.infinispan
| >> module by
| >> default:
| >> https://issues.jboss.org/browse/AS7-1713
| >>
| >> As well as including the relevant jars, we would also like to
| >> simplify
| >> their definition (like we did for <file-store/>, such that users
| >> don't
| >> need to specify class names, provide as many sensible defaults as
| >> possible, and take care of any required service dependencies.
| >>
| >> I've created a draft of what I thought could be workable schema for
| >> the
| >> remote and jdbc cache stores and would like some feedback.
| >>
| >> The amended Infinispan subsystem schema can be found here:
| >>
https://github.com/pferraro/jboss-as/blob/master/build/src/main/resources...
| >>
| >> For the jdbc cache stores, which come in 3 flavors, I've
| >> consolidated
| >> them into a single configuration element <jdbc-store/>, where the
| >> variant is implied the defined tables. After providing default
| >> values
| >> for all the required fields, we arrive at the following minimal
| >> configuration:
| >> e.g.
| >> <jdbc-store datasource="java:jboss/jdbc/somedatabase"/>
| >>
| >> I started with the assumption that the database resource will
| >> always
| >> come from an AS-managed DataSource.
| >>
| >> To use a string-based jdbc store, we specify the type of table to
| >> use:
| >> e.g.
| >>
| >> <jdbc-store datasource="java:jboss/jdbc/somedatabase">
| >> <entry-table/>
| >> </jdbc-store>
| >>
| >> Likewise, if we want to use a binary jdbc store:
| >> e.g.
| >> <jdbc-store datasource="java:jboss/jdbc/somedatabase">
| >> <bucket-table/>
| >> </jdbc-store>
| >>
| >> Using both <entry-table/> and <bucket-table/> (or neither)
| >> indicates the
| >> use of a mixed jdbc store.
| >>
| >> The tables themselves are fully customizable (shown with their
| >> default
| >> values):
| >> e.g.
| >> <jdbc-store datasource="java:jboss/jdbc/somedatabase">
| >> <bucket-table prefix="ispn_bucket" batch-size="100"
| >> fetch-size="100">
| >> <id-column name="id" type="VARCHAR"/>
| >> <data-column name="datum" type="BINARY"/>
| >> <timestamp-column name="version" type="BIGINT"/>
| >> </bucket-table>
| >> <entry-table prefix="ispn_entry" batch-size="100"
fetch-size="100">
| >> <id-column name="id" type="VARCHAR"/>
| >> <data-column name="datum" type="BINARY"/>
| >> <timestamp-column name="version" type="BIGINT"/>
| >> </entry-table>
| >> </jdbc-store>
| >>
| >>
| >> The schema for the remote cache store is far simpler. You can
| >> specify a
| >> specific remote cache name, server list, and hot rod client
| >> properties
| >> are directly enumerated:
| >> e.g.
| >> <remote-store cache="some-named-cache"
servers="127.0.0.1:11311">
| >> <property
| >>
name="infinispan.client.hotrod.request_balancing_strategy">...</property>
| >> </remote-store>
| >>
| >> If the cache attribute is omitted, we assume the default cache is
| >> to be
| >> used.
| >>
| >> Unfortunately, there doesn't seem to be a way to integrate the
| >> thread
| >> pools used by RemoteCache/RemoteCacheManager with the AS7 threading
| >> subsystem. In order to do this, RemoteCacheStoreConfig would need
| >> methods for providing ExecutorFactory implementations, similar to
| >> the
| >> way GlobalConfiguration works.
| >>
| >> I haven't started on the cloud-based store yet, as it's kind of a
| >> dependency nightmare.
| >>
| >> Thoughts?
| >>
| >> Paul
| >>
| >> _______________________________________________
| >> infinispan-dev mailing list
| >> infinispan-dev(a)lists.jboss.org
| >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
| >
| > --
| > Manik Surtani
| > manik(a)jboss.org
| > twitter.com/maniksurtani
| >
| > Lead, Infinispan
| > http://www.infinispan.org
| >
| >
| >
| >
| > _______________________________________________
| > infinispan-dev mailing list
| > infinispan-dev(a)lists.jboss.org
| > https://lists.jboss.org/mailman/listinfo/infinispan-dev
|
|
| _______________________________________________
| infinispan-dev mailing list
| infinispan-dev(a)lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/infinispan-dev
4658
days inactive
4662
days old
infinispan-dev@lists.jboss.org
15 comments
8 participants
participants (8)
-
Galder Zamarreño -
Manik Surtani -
Martin Gencur -
Paul Ferraro -
Pete Muir -
Prabhat Jha -
Sanne Grinovero -
Tristan Tarrant