Re: [infinispan-dev] Why DistTxInterceptor in use with Hot Rod ?
On Sep 15, 2011, at 1:31 PM, Dan Berindei wrote:
On Thu, Sep 15, 2011 at 12:25 PM, Galder Zamarreño gal...@redhat.com wrote:
On Sep 14, 2011, at 11:40 AM, Dan Berindei wrote:
Going back to your original question Galder, the exception is most
likely thrown because of this sequence of events:
0. Given a cluster {A, B}, a key k and a node C joining.
1. Put acquires the transaction lock on node A (blocking rehashing)
2. Put acquires lock for key k on node A
3. Rehashing starts on node B, blocking transactions
4. Put tries to acquire transaction lock on node B
Since it's impossible to finish rehashing while the put operation
keeps the transaction lock on node A, the best option was to kill the
put operation by throwing a RehashInProgressException.
I was thinking in the context of transactions when I wrote this code
(see
https://github.com/danberindei/infinispan/commit/6ed94d3b2e184d4a48d4e781db8d404baf5915a3,
this scenario became just a footnote to the generic case with multiple
caches), but the scenario also occurs without transactions. Actually I
renamed it state transfer lock and I moved it to a separate
interceptor in my ISPN-1194 branch.
Right, but it shouldn't happen when transactions are off, right?
It will still happen with transactions off, because state transfer
will acquire the state transfer lock in exclusive mode and
WriteCommands will acquire the state transfer lock in shared mode
instead of PrepareCommands with transactions on.
If we don't acquire the state transfer lock than we run the risk of
pushing stale data to other nodes, are you saying that without
transactions enabled this risk is acceptable?
Hmmm, at first glance no, it does not look acceptable. Refactoring though, as
you did, is in order though to move it somewhere else, cos clearly it's logic
that's required by both transactional and non-transactional caches.
Maybe the locking changes in 5.1 will eliminate this scenario, but
otherwise we could improve the user experience by retrying the command
after the rehashing finishes.
I'd prefer that, otherwise users are likely to code similar logic which is
not nice.
After looking at the scenario again it became clear that step 2. is
not necessary at all and the locking enhancements will not change
anything.
We could change DistributionInterceptor to not hold the state transfer
lock during remote calls, which will allow rehashing to proceed on the
origin. But then the ownership of the keys might change during the
call, so we'll need a retry phase anyway.
Dan
___
infinispan-dev mailing list
infinispan-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Request for feedback on cache store support in AS7 Infinispan subsystem
On 16 September 2011 09:50, Tristan Tarrant ttarr...@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 thejdbc-store/: property name=key2StringMapperclass.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 withinresources/. 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 ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
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 Tarrantttarr...@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 ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Request for feedback on cache store support in AS7 Infinispan subsystem
On 16 September 2011 10:07, Tristan Tarrant ttarr...@redhat.com wrote: On 09/16/2011 09:56 AM, Sanne Grinovero wrote: On 16 September 2011 09:50, Tristan Tarrantttarr...@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 ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Versioned entries - overview of design, looking for comments
On Sep 14, 2011, at 4:03 PM, Manik Surtani wrote: So I've been hacking on versioned entries for a bit now, and want to run the designs by everyone. Adding an EntryVersion to each entry is easy, making this optional and null by default easy too, and a SimpleVersion a wrapper around a long and a PartitionTolerantVersion being a vector clock implementation. Also easy stuff, changing the entry hierarchy and the marshalling to ensure versions - if available - are shipped, etc. I think we might need support for other versions to be able to deal with external database or JPA versions. I'll be speaking about this next week :) Comparing versions would happen in Mircea's optimistic locking code, on prepare, when a write skew check is done. If running in a non-clustered environment, the simple object-identity check we currently have is enough; otherwise an EntryVersion.compare() will need to happen, with one of 4 possible results: equal, newer than, older than, or concurrently modified. The last one can only happen if you have a PartitionTolerantVersion, and will indicate a split brain and simultaneous update. Now the hard part. Who increments the version? We have a few options, all seem expensive. 1) The modifying node. If the modifying node is a data owner, then easy. Otherwise the modifying node *has* to do a remote GET first (or at least a GET_VERSION) before doing a PUT. Extra RPC per entry. Sucks. 2) The data owner. This would have to happen on the primary data owner only, and the primary data owner would need to perform the write skew check. NOT the modifying node. The modifying node would also need to increment and ship its own NodeClock along with the modification. Extra info to ship per commit. I'm guessing we go with #2, but would like to hear your thoughts. Cheers Manik -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] 5.1.0.ALPHA2
I'm hoping to see some of the state transfer/rehash stuff as well as the JTA refactoring pieces here. :) On 16 Sep 2011, at 08:17, Galder Zamarreño wrote: Hi, 5.1.0.ALPHA2 is scheduled for Monday, 19th of September. There's quite a few JIRAs still open: http://goo.gl/ufhFF Please go through them and if you're deferring anything, please reply. Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Request for feedback on cache store support in AS7 Infinispan subsystem
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/docs/schema/jboss-as-infinispan_1_0.xsd 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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] 5.1.0.ALPHA2
Is there hope for https://issues.jboss.org/browse/ISPN-1115 in this release? -- Eduardo .. http://emmartins.blogspot.com http://redhat.com/solutions/telco On Fri, Sep 16, 2011 at 12:49 PM, Manik Surtani ma...@jboss.org wrote: I'm hoping to see some of the state transfer/rehash stuff as well as the JTA refactoring pieces here. :) On 16 Sep 2011, at 08:17, Galder Zamarreño wrote: Hi, 5.1.0.ALPHA2 is scheduled for Monday, 19th of September. There's quite a few JIRAs still open: http://goo.gl/ufhFF Please go through them and if you're deferring anything, please reply. Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] 5.1.0.ALPHA2
On 16 Sep 2011, at 12:56, Eduardo Martins wrote: Is there hope for https://issues.jboss.org/browse/ISPN-1115 in this release? IDK. Vladimir? :-) Even an early version would be great … -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] 5.1.0.ALPHA2
Eduardo, I am still working on this feature. It will not make into ALPHA2 but it should be ready for ALPHA3. Regards, Vladimir On 11-09-16 2:02 PM, Eduardo Martins wrote: Yep, I could probably also start giving feedback about it right away. -- Eduardo .. http://emmartins.blogspot.com http://redhat.com/solutions/telco On Fri, Sep 16, 2011 at 12:59 PM, Manik Surtanima...@jboss.org wrote: On 16 Sep 2011, at 12:56, Eduardo Martins wrote: Is there hope for https://issues.jboss.org/browse/ISPN-1115 in this release? IDK. Vladimir? :-) Even an early version would be great … -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] 5.1.0.ALPHA2
Allright, no problem. -- Eduardo .. http://emmartins.blogspot.com http://redhat.com/solutions/telco On Fri, Sep 16, 2011 at 1:08 PM, Vladimir Blagojevic vblag...@redhat.com wrote: Eduardo, I am still working on this feature. It will not make into ALPHA2 but it should be ready for ALPHA3. Regards, Vladimir On 11-09-16 2:02 PM, Eduardo Martins wrote: Yep, I could probably also start giving feedback about it right away. -- Eduardo .. http://emmartins.blogspot.com http://redhat.com/solutions/telco On Fri, Sep 16, 2011 at 12:59 PM, Manik Surtanima...@jboss.org wrote: On 16 Sep 2011, at 12:56, Eduardo Martins wrote: Is there hope for https://issues.jboss.org/browse/ISPN-1115 in this release? IDK. Vladimir? :-) Even an early version would be great … -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] 5.1.0.ALPHA2
great to see more people interested in it :-) Sanne On 16 September 2011 14:11, Eduardo Martins emmart...@gmail.com wrote: Allright, no problem. -- Eduardo .. http://emmartins.blogspot.com http://redhat.com/solutions/telco On Fri, Sep 16, 2011 at 1:08 PM, Vladimir Blagojevic vblag...@redhat.com wrote: Eduardo, I am still working on this feature. It will not make into ALPHA2 but it should be ready for ALPHA3. Regards, Vladimir On 11-09-16 2:02 PM, Eduardo Martins wrote: Yep, I could probably also start giving feedback about it right away. -- Eduardo .. http://emmartins.blogspot.com http://redhat.com/solutions/telco On Fri, Sep 16, 2011 at 12:59 PM, Manik Surtanima...@jboss.org wrote: On 16 Sep 2011, at 12:56, Eduardo Martins wrote: Is there hope for https://issues.jboss.org/browse/ISPN-1115 in this release? IDK. Vladimir? :-) Even an early version would be great … -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] 5.1.0.ALPHA2
Randall Hauch is too, as is Kapil Nayar (when speaking about his MultiMap use case). I think the FineGrainedMaps will become a popular feature. On 16 Sep 2011, at 13:45, Sanne Grinovero wrote: great to see more people interested in it :-) Sanne -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] 5.1.0.ALPHA2
On 16 Sep 2011, at 12:49, Manik Surtani wrote: I'm hoping to see some of the state transfer/rehash stuff as well as the JTA refactoring pieces here. :) The Optimistic Locking stuff is not there yet: I had to do some significant changes to the original design, mainly around auto commit transactions and invocation contexts. I have about 50 failures now, once I get it down to 25 I'll issue the pull request and work on the test fixes in parallel so that we can speed up the integration process. ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Versioned entries - overview of design, looking for comments
On Sep 16, 2011, at 1:58 PM, Manik Surtani wrote: On 16 Sep 2011, at 12:11, Galder Zamarreño wrote: On Sep 14, 2011, at 4:03 PM, Manik Surtani wrote: So I've been hacking on versioned entries for a bit now, and want to run the designs by everyone. Adding an EntryVersion to each entry is easy, making this optional and null by default easy too, and a SimpleVersion a wrapper around a long and a PartitionTolerantVersion being a vector clock implementation. Also easy stuff, changing the entry hierarchy and the marshalling to ensure versions - if available - are shipped, etc. I think we might need support for other versions to be able to deal with external database or JPA versions. I'll be speaking about this next week :) Yes, that would be step 2. :) Indeed, just want to make sure the requirements of the 2LC use case are understood and the API fits nicely :). -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
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/docs/schema/jboss-as-infinispan_1_0.xsd 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@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] ISPN-1374 and ModuleProperties, static collections and class loading
On Sep 16, 2011, at 1:09 AM, Sanne Grinovero wrote: On 15 September 2011 17:25, Galder Zamarreño gal...@redhat.com wrote: On Sep 14, 2011, at 5:53 PM, Sanne Grinovero wrote: On 14 September 2011 17:37, Manik Surtani ma...@jboss.org wrote: On 13 Sep 2011, at 00:03, Sanne Grinovero wrote: For example, I suspect that you won't be able to deploy an Hibernate Search application (or Infinispan Query) and then deploy a Hibernate OGM based application in the same container. But this is not proven as I didn't try it out, so maybe my assumptions about what the goal of this classloader parameter are wrong. Ah ok, I think I see your problem: that some infinispan modules are bundled with an application, using an application-scoped class loader (a web app)? Ok, I can see how that could be a problem then. Exactly the point. Unless you can make sure that both OGM and Search are included in AS7 and special purpose caches are pre-configured out of the box :-) So I think that, iff we need to cache this information, it shouldn't be cached in a static field, as discussed as well on Well, the purpose of caching this info is to prevent each new named Cache from re-reading module properties. Each named cache only reads these properties once at startup, so caching this is useless if this isn't shared across named caches. Or perhaps we maintain one such module cache per class loader passed in? Since caches can be started only once and should happen in the context of a startCaches( ... ) context, such a cache could live in the scope of such an invocation. Besides solving the (potential?) problem that would also save some memory as this information would be released right after usage. Remember that a cache could be restarted... Since it's just caching class/resources information we can re-scan in any case you would need it. But in which cases should a cache be restarted? shouldn't it be better to throw away the CacheManager and create a new one? I was just thinking that the other day. Originally, the cache restart thing came from me playing around with RHQ management (back in 4.0). I don't recall any particular external requirement on this. I'm assuming you can't restart a single cache while maintaining the others available as that would break 1) asymmetric clusters limitation 2) requirement to start them all together. Yeah, these days 1) and 2) have become more common problem, and restarting, without being a cluster wide operation, can lead to unexpected results. When it comes to stop at least, there's ECM.removeCache() which is cluster wide. Stops and removes content of a cache cluster wide. There's no equivalent for start. Cheers, Sanne ___ infinispan-dev mailing list infinispan-dev@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Request for feedback on cache store support in AS7 Infinispan subsystem
- Original Message - From: Galder Zamarreño gal...@redhat.com To: infinispan -Dev List infinispan-dev@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/docs/schema/jboss-as-infinispan_1_0.xsd 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/resources/docs/schema/jboss-as-infinispan_1_0.xsd 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@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Request for feedback on cache store support in AS7 Infinispan subsystem
- Original Message - From: Tristan Tarrant ttarr...@redhat.com To: infinispan-dev@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 Tarrantttarr...@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. ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Request for feedback on cache store support in AS7 Infinispan subsystem
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/docs/schema/jboss-as-infinispan_1_0.xsd 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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Request for feedback on cache store support in AS7 Infinispan subsystem
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 ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] 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/docs/schema/jboss-as-infinispan_1_0.xsd | | 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 |
