[infinispan-dev] Fluent configuration wiki update
A section has been added to http://community.jboss.org/docs/DOC-14839 with some examples on how to configure Infinispan programmatically from 5.0 onwards. Any feedback appreciated 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
Re: [infinispan-dev] Fluent configuration wiki update
Nice. Perhaps you need a few basic configs though? Stuff that people would typically use? A lot of your examples demonstrate some of the more complex config examples (custom marshallers and interceptors). I think a lot of first-time users will try and copy these into their IDEs and expect a useable system. :) Maybe you should have the examples only depict common options, like cluster mode, cache stores, some simple locking and JTA config, eviction and expiry? Cheers Manik On 16 May 2011, at 08:42, Galder Zamarreño wrote: A section has been added to http://community.jboss.org/docs/DOC-14839 with some examples on how to configure Infinispan programmatically from 5.0 onwards. Any feedback appreciated 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] Infinispan Query entity discovery (Was: Re: new Infinispan Query API - ISPN-194)
On 13 May 2011, at 19:27, Sanne Grinovero wrote: Or does Reflections provide some cool way to find all subtypes of a class? Even if it's a bit expensive, we already cache all new class processing as for each new type we have to restart the Search engine which is quite expensive anyway. I don't know of any way to do this without extensive classpath scanning... :-( -- 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] Local state transfer before going over network
Not sure if the idea has come up but while at GeeCON last week I was discussing to one of the attendees about state transfer improvements in replicated environments: The idea is that in a replicated environment, if a cache manager shuts down, it would dump its memory contents to a cache store (i.e. a local filesystem) and when it starts up, instead of going over the network to do state transfer, it would load the state from the local filesystem which would be much quicker. Obviously, at times the cache manager would crash or have some failure dumping the memory contents, so in that case it would fallback on state transfer over the network. I think it's an interesting idea since it could reduce the amount of state transfer to be done. It's true though that there're other tricks if you're having issues with state transfer, such as the use of a cluster cache loader. WDYT? -- 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] Per-invocation flag wiki
Your description explains a use case / pattern but wo code showing how to implement it properly. In this case what's the best way for me to verify that the new data has indeed been pushed to the cache? put and then immediate get Put, wait, get Put all entries, then get all entries, and loop till all entries supposedly put are indeed present. Same as above but with some kind of batch size instead of all the data set? Or is there some kind of queue/log I can look for to get the reliable list of failures? Emmanuel On 16 mai 2011, at 10:20, Galder Zamarreño gal...@redhat.com wrote: More wikis. I've just created http://community.jboss.org/docs/DOC-16803 which explains what Infinispan flags are, what they're used for...etc. Feedback appreciated -- 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] Fluent configuration wiki update
On May 16, 2011, at 12:05 PM, Vladimir Blagojevic wrote: On 11-05-16 11:57 AM, Manik Surtani wrote: Nice. Perhaps you need a few basic configs though? Stuff that people would typically use? A lot of your examples demonstrate some of the more complex config examples (custom marshallers and interceptors). I think a lot of first-time users will try and copy these into their IDEs and expect a useable system. :) I thought the exact same thing. People want to get Infinispan up and running in 2 minutes. We should be really aware of this and make sure all our code samples are as generic as it gets. In some way, that's what I was trying to do with the last of the examples in http://community.jboss.org/docs/DOC-14839 but maybe it's a bit too much to have in one go. I'll add some smaller examples and move some of the other more exoteric configs to a separate section Maybe you should have the examples only depict common options, like cluster mode, cache stores, some simple locking and JTA config, eviction and expiry? Cheers Manik On 16 May 2011, at 08:42, Galder Zamarreño wrote: ___ 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] Eventing over Hot Rod vs JMS Was: Hot Rod protocol improvements JIRA
On 16 May 2011, at 13:52, Galder Zamarreño wrote: Maybe your or Sanne can build that wiki or note in down in more detail since you guys implemented it? You could use that code as sample Sanne, do you want to take this, since you had more details of the impl? 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
Re: [infinispan-dev] Fluent configuration wiki update
yes, looks good. On 16 May 2011, at 16:15, Galder Zamarreño wrote: Hmmm, maybe you caught me in the middle of updating the wiki? Check the link again... On May 16, 2011, at 5:12 PM, Mircea Markus wrote: Good stuff! My only note is that there are some code snippets that are not code: E.g. To enable global JMX statistics simply do: Or was that the intent? On 16 May 2011, at 08:42, Galder Zamarreño wrote: A section has been added to http://community.jboss.org/docs/DOC-14839 with some examples on how to configure Infinispan programmatically from 5.0 onwards. Any feedback appreciated 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 ___ 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] Per-invocation flag wiki
On May 16, 2011, at 2:23 PM, Emmanuel Bernard wrote: Your description explains a use case / pattern but wo code showing how to implement it properly. True and I think you have a point, though the use of putForExternalRead() itself is something that should be documented either its javadoc or a separate wiki. This wiki should be limited to explaining the actual flags. In this case what's the best way for me to verify that the new data has indeed been pushed to the cache? put and then immediate get Put, wait, get Put all entries, then get all entries, and loop till all entries supposedly put are indeed present. Same as above but with some kind of batch size instead of all the data set? Or is there some kind of queue/log I can look for to get the reliable list of failures? If you need immediate verification I would not use putForExternalRead() but maybe a putAsync() with the flags you want which returns you a future and allows you to verify the result in a less wacky way. The normal use case of PFER is: 1. Check the cache whether an k/v is present 2. If not present, go to db and call PFER with it. 3. Use whatever you retrieved from db to do your job. ... N. Check the cache whether k/v is present N+1. Oh, it's present, so just use it instead of going to DB. This could be a good FAQ, wdyt? Emmanuel On 16 mai 2011, at 10:20, Galder Zamarreño gal...@redhat.com wrote: More wikis. I've just created http://community.jboss.org/docs/DOC-16803 which explains what Infinispan flags are, what they're used for...etc. Feedback appreciated -- 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 -- 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] New events to reflect topology change Was: https://issues.jboss.org/browse/ISPN-977
On 13 May 2011, at 10:28, Manik Surtani wrote: So this is related to ISPN-360 which is currently titled create NodeJoinedEvent. Leaving names out for now, essentially, what we need is a notification to inform listeners that (a) a JGroups ViewChange has been detected (b) a rehash has started and (c) a rehash has completed. Possibly, being more fine-grained, that (d) a new ConsistentHash view has been installed. Does this cover it all? If so, how about: @ViewChanged (same as we have now) @RehashStarted @RehashComplete @TopologyChanged // to reflect a new CH? Thoughts? Sounds good to me. Cheers Manik On 11 May 2011, at 13:29, Sanne Grinovero wrote: First thing I thought when reading your email was OMG do we support on-the-fly hash implementation changes? crazy! That's obviously not the case, but if you name it as @ConsistenHashChangeListene that's what I would think. Wouldn't it be better to change the exact timing of the viewchange event? I don't see why Infinispan users might be more interested in knowing about the topology details according to the transport than what they are about the actual Infinispan hashing topology - I would expect that when I receive which notification the new view is already installed and ready to go; actually I thought that was the case since ever. What would be the use cases to get the notification *before* the new hash is installed? Cheers, Sanne 2011/5/11 Mircea Markus mircea.mar...@jboss.com: Hi, The basic problem behind this is that I need to be notified when a new consistent hash is installed. ATM there isn't any support (of which I know) for a @ConsistenHashChangeListener. I'm thinking to add such notifications either: a) internally: Observer pattern on DistributionManager or even on DistributionManagerImpl b) more generically, as a fully flagged listener. I favor a) and then if more people ask for it we will expose it as a fully flagged listener. Suggestions? Cheers, Mircea ___ 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 -- 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] Compilation errors in the infinispan-spring module
Hi Olaf,
Did you see any problems with RHQ + Spring interaction that determined
you to exclude the rhq-pluginAnnotations dependency in the spring
module?
dependency
groupId${project.groupId}/groupId
artifactIdinfinispan-core/artifactId
version${project.version}/version
scopecompile/scope
exclusions
exclusion
groupIdorg.rhq.helpers/groupId
artifactIdrhq-pluginAnnotations/artifactId
/exclusion
/exclusions
/dependency
I've been getting some weird errors while building the
infinispan-spring module, both with OpenJDK 1.6.0_20 and with Sun JDK
1.6.0_24 and 1.6.0_25, and they seem to appear because the compiler
doesn't have access to the RHQ annotations:
/tmp/privatebuild/home/dan/Work/infinispan/master/core/classes/org/infinispan/manager/DefaultCacheManager.class:
warning: Cannot find annotation method 'displayName()' in type
'org.rhq.helpers.pluginAnnotations.agent.Metric': class file for
org.rhq.helpers.pluginAnnotations.agent.Metric not found
/tmp/privatebuild/home/dan/Work/infinispan/master/core/classes/org/infinispan/manager/DefaultCacheManager.class:
warning: Cannot find annotation method 'dataType()' in type
'org.rhq.helpers.pluginAnnotations.agent.Metric'
An exception has occurred in the compiler (1.6.0_24). Please file a
bug at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) after checking the Bug Parade
for duplicates. Include your program and the following diagnostic in
your report. Thank you.
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
org.rhq.helpers.pluginAnnotations.agent.DataType not found
Galder has seen it too with Sun JDK 1.6.0_24, but strangely enough
everyone else is able to build without any errors.
I'm thinking of removing the rhq-pluginAnnotations exclusion from the
infinispan-spring pom.xml, the question is whether this would break
something on the Spring side. Do you know of any potential problems,
or did you do this just to reduce the number of dependencies brought
in by infinispan-spring into an application?
Cheers
Dan
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
On May 12, 2011, at 11:18 AM, Dan Berindei wrote: On Wed, May 11, 2011 at 11:18 PM, David Bosschaert da...@redhat.com wrote: On 11/05/2011 17:54, Dan Berindei wrote: On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.com wrote: Were we developing for OSGi I would certainly agree with you. However in many environments today we can reasonably expect the TCCL to be set and to be able to load the classes we need. So whilst making it part of the API is the safest option, it's also making complicated an API for the sake of the few at the cost of the many. Further this also seems kinda nasty to me. We know the class (and hence bundle/module) when we put the object into Infinispan, therefore why do we require people to respecify this again? David, can we not actually do something here akin to what we are discussing for Weld? Whereby we can serialize out the bundle id and then find the correct CL based on that when we deserialize. What if the object is a java.util.ArrayList? Each element in the list could belong to a different bundle, so you'd have to write a bundle id for every element in the list. Yes, if you know the Bundle-SymbolicName and Version (or the Bundle ID) you can find its classloader. On the other question, if you're passing in a class object then you can obtain its classloader and hence the bundle where it came from. But, and I think this is what Dan allused to above, is it always true that the class your passing in comes from the bundle that you need to have or could it also come from one of its parent class loaders? Exactly David, sorry if my message was a little cryptic. I think in order to handle every case properly you would have to go through the entire object graph being stored in the cache in order to find all the classloaders/bundle ids that you will need on get(). That seems like a lot of overhead to me, and forcing the user to provide the classloader doesn't seem that bad in comparison. Perhaps we should use something other than a thread-local for this though, so that users can do a onto the result of a cacheManager.getCache(A).usingClassLoader(A.class) and never have to provide the classloader again. In fact I think this is a good idea for the invocation flags we already have, too. It would involve creating lots of overloads in CacheDelegate with a PreInvocationContext parameter and a new CacheDelegateWithContext class to invoke those methods, but the public API would remain the same. No matter how I look at it, putting a classloader in a thread local makes me shiver. Just imagine the mayhem you can cause if you forget to clear the thread local. I've done enough of Apache Commons Logging support to understand that you should limit the references to classloaders to the minimum, particularly in system classes/infrastructure. If we need to end up forcing users to register classloaders in these scenarions, we need to do it in such way that either: - we can detect these leaks (it might be a bit primitive now but old JBoss JCA code had an interesting way of discovering unclosed open connections) - if we give you on trying to detect them, the impact of a leak is reduced as much as possible. 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
Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
On 16 May 2011, at 18:20, Galder Zamarreño wrote: On May 12, 2011, at 11:18 AM, Dan Berindei wrote: On Wed, May 11, 2011 at 11:18 PM, David Bosschaert da...@redhat.com wrote: On 11/05/2011 17:54, Dan Berindei wrote: On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.com wrote: Were we developing for OSGi I would certainly agree with you. However in many environments today we can reasonably expect the TCCL to be set and to be able to load the classes we need. So whilst making it part of the API is the safest option, it's also making complicated an API for the sake of the few at the cost of the many. Further this also seems kinda nasty to me. We know the class (and hence bundle/module) when we put the object into Infinispan, therefore why do we require people to respecify this again? David, can we not actually do something here akin to what we are discussing for Weld? Whereby we can serialize out the bundle id and then find the correct CL based on that when we deserialize. What if the object is a java.util.ArrayList? Each element in the list could belong to a different bundle, so you'd have to write a bundle id for every element in the list. Yes, if you know the Bundle-SymbolicName and Version (or the Bundle ID) you can find its classloader. On the other question, if you're passing in a class object then you can obtain its classloader and hence the bundle where it came from. But, and I think this is what Dan allused to above, is it always true that the class your passing in comes from the bundle that you need to have or could it also come from one of its parent class loaders? Exactly David, sorry if my message was a little cryptic. I think in order to handle every case properly you would have to go through the entire object graph being stored in the cache in order to find all the classloaders/bundle ids that you will need on get(). That seems like a lot of overhead to me, and forcing the user to provide the classloader doesn't seem that bad in comparison. Perhaps we should use something other than a thread-local for this though, so that users can do a onto the result of a cacheManager.getCache(A).usingClassLoader(A.class) and never have to provide the classloader again. In fact I think this is a good idea for the invocation flags we already have, too. It would involve creating lots of overloads in CacheDelegate with a PreInvocationContext parameter and a new CacheDelegateWithContext class to invoke those methods, but the public API would remain the same. No matter how I look at it, putting a classloader in a thread local makes me shiver. I also wonder why we want do this, given we already have a construct called the Thread Local Context Classloader ;-) Either we use that, or use some other mechanism. Just imagine the mayhem you can cause if you forget to clear the thread local. I've done enough of Apache Commons Logging support to understand that you should limit the references to classloaders to the minimum, particularly in system classes/infrastructure. If we need to end up forcing users to register classloaders in these scenarions, we need to do it in such way that either: - we can detect these leaks (it might be a bit primitive now but old JBoss JCA code had an interesting way of discovering unclosed open connections) - if we give you on trying to detect them, the impact of a leak is reduced as much as possible. 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 ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Per-invocation flag wiki
good place to remind that if you don't want the return value of a write operation then you need to specify both flags: cache.withFlags(Flag.SKIP_REMOTE_LOOKUP, Flag.SKIP_CACHE_LOAD).put( .. ) I guess that nobody knows that :) Sanne 2011/5/16 Emmanuel Bernard emman...@hibernate.org: Yes I think something use case driven would make a nice portal. On 16 mai 2011, at 17:22, Galder Zamarreño wrote: On May 16, 2011, at 2:23 PM, Emmanuel Bernard wrote: Your description explains a use case / pattern but wo code showing how to implement it properly. True and I think you have a point, though the use of putForExternalRead() itself is something that should be documented either its javadoc or a separate wiki. This wiki should be limited to explaining the actual flags. In this case what's the best way for me to verify that the new data has indeed been pushed to the cache? put and then immediate get Put, wait, get Put all entries, then get all entries, and loop till all entries supposedly put are indeed present. Same as above but with some kind of batch size instead of all the data set? Or is there some kind of queue/log I can look for to get the reliable list of failures? If you need immediate verification I would not use putForExternalRead() but maybe a putAsync() with the flags you want which returns you a future and allows you to verify the result in a less wacky way. The normal use case of PFER is: 1. Check the cache whether an k/v is present 2. If not present, go to db and call PFER with it. 3. Use whatever you retrieved from db to do your job. ... N. Check the cache whether k/v is present N+1. Oh, it's present, so just use it instead of going to DB. This could be a good FAQ, wdyt? Emmanuel On 16 mai 2011, at 10:20, Galder Zamarreño gal...@redhat.com wrote: More wikis. I've just created http://community.jboss.org/docs/DOC-16803 which explains what Infinispan flags are, what they're used for...etc. Feedback appreciated -- 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 -- 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 ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Per-invocation flag wiki
Couldn't you have a higher level flag that says Flag.IGNORE_RETURN_VALUE so that people wo a PhD can benefit form the feature? On 16 mai 2011, at 19:37, Sanne Grinovero wrote: good place to remind that if you don't want the return value of a write operation then you need to specify both flags: cache.withFlags(Flag.SKIP_REMOTE_LOOKUP, Flag.SKIP_CACHE_LOAD).put( .. ) I guess that nobody knows that :) Sanne 2011/5/16 Emmanuel Bernard emman...@hibernate.org: Yes I think something use case driven would make a nice portal. On 16 mai 2011, at 17:22, Galder Zamarreño wrote: On May 16, 2011, at 2:23 PM, Emmanuel Bernard wrote: Your description explains a use case / pattern but wo code showing how to implement it properly. True and I think you have a point, though the use of putForExternalRead() itself is something that should be documented either its javadoc or a separate wiki. This wiki should be limited to explaining the actual flags. In this case what's the best way for me to verify that the new data has indeed been pushed to the cache? put and then immediate get Put, wait, get Put all entries, then get all entries, and loop till all entries supposedly put are indeed present. Same as above but with some kind of batch size instead of all the data set? Or is there some kind of queue/log I can look for to get the reliable list of failures? If you need immediate verification I would not use putForExternalRead() but maybe a putAsync() with the flags you want which returns you a future and allows you to verify the result in a less wacky way. The normal use case of PFER is: 1. Check the cache whether an k/v is present 2. If not present, go to db and call PFER with it. 3. Use whatever you retrieved from db to do your job. ... N. Check the cache whether k/v is present N+1. Oh, it's present, so just use it instead of going to DB. This could be a good FAQ, wdyt? Emmanuel On 16 mai 2011, at 10:20, Galder Zamarreño gal...@redhat.com wrote: More wikis. I've just created http://community.jboss.org/docs/DOC-16803 which explains what Infinispan flags are, what they're used for...etc. Feedback appreciated -- 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 -- 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 ___ 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] [Pull Request] Modular Classloading Compatibility
I don't like the TCCL either, so I'll repeat my suggestion from two weeks ago to just have: Cache c = cacheManager.getCache( cacheName, classLoader ); sounds reasonable to me to have the application declare it's intentions once ? BTW I don't like cache.get(K key, ClassV clazz) as we're not speaking only about the get(K) method, but about many methods and this will explode the number of method of Cache; on the other hand I think it;s acceptable to have a single Cache instance used by a single application/classloader. You can still have multiple applications share the same underlying cache and use different classloaders: getCache( cacheName, classLoader ) would return a delegate to the original cache, having a specific marshaller in the invocation context as Trustin was suggesting. Cheers, Sanne 2011/5/16 Pete Muir pm...@redhat.com: On 16 May 2011, at 18:20, Galder Zamarreño wrote: On May 12, 2011, at 11:18 AM, Dan Berindei wrote: On Wed, May 11, 2011 at 11:18 PM, David Bosschaert da...@redhat.com wrote: On 11/05/2011 17:54, Dan Berindei wrote: On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.com wrote: Were we developing for OSGi I would certainly agree with you. However in many environments today we can reasonably expect the TCCL to be set and to be able to load the classes we need. So whilst making it part of the API is the safest option, it's also making complicated an API for the sake of the few at the cost of the many. Further this also seems kinda nasty to me. We know the class (and hence bundle/module) when we put the object into Infinispan, therefore why do we require people to respecify this again? David, can we not actually do something here akin to what we are discussing for Weld? Whereby we can serialize out the bundle id and then find the correct CL based on that when we deserialize. What if the object is a java.util.ArrayList? Each element in the list could belong to a different bundle, so you'd have to write a bundle id for every element in the list. Yes, if you know the Bundle-SymbolicName and Version (or the Bundle ID) you can find its classloader. On the other question, if you're passing in a class object then you can obtain its classloader and hence the bundle where it came from. But, and I think this is what Dan allused to above, is it always true that the class your passing in comes from the bundle that you need to have or could it also come from one of its parent class loaders? Exactly David, sorry if my message was a little cryptic. I think in order to handle every case properly you would have to go through the entire object graph being stored in the cache in order to find all the classloaders/bundle ids that you will need on get(). That seems like a lot of overhead to me, and forcing the user to provide the classloader doesn't seem that bad in comparison. Perhaps we should use something other than a thread-local for this though, so that users can do a onto the result of a cacheManager.getCache(A).usingClassLoader(A.class) and never have to provide the classloader again. In fact I think this is a good idea for the invocation flags we already have, too. It would involve creating lots of overloads in CacheDelegate with a PreInvocationContext parameter and a new CacheDelegateWithContext class to invoke those methods, but the public API would remain the same. No matter how I look at it, putting a classloader in a thread local makes me shiver. I also wonder why we want do this, given we already have a construct called the Thread Local Context Classloader ;-) Either we use that, or use some other mechanism. Just imagine the mayhem you can cause if you forget to clear the thread local. I've done enough of Apache Commons Logging support to understand that you should limit the references to classloaders to the minimum, particularly in system classes/infrastructure. If we need to end up forcing users to register classloaders in these scenarions, we need to do it in such way that either: - we can detect these leaks (it might be a bit primitive now but old JBoss JCA code had an interesting way of discovering unclosed open connections) - if we give you on trying to detect them, the impact of a leak is reduced as much as possible. 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 ___ 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] [Pull Request] Modular Classloading Compatibility
I don't enjoy using JBoss Logging for that reason :) I always have to get down to the JavaDoc or figure out the list of available params to understand what debug* does for example and which one I need. I guess that's taste and for something like JBoss Logging, a fluent API is costly (unnecessary object creation etc). On 16 mai 2011, at 20:01, David M. Lloyd wrote: As a rule I've never cared about exploding the number of methods on an API class as long as: 1. There are few basic functions - i.e. get is get, and regardless of which overload we're talking about it behaves consistently - and the large number of methods is due mainly to overloads 2. The end user is not expected to ever need to implement the interface For example, org.jboss.logging.Logger has about a zillion methods but they all boil down to: log, trace, debug, info, warn, error, fatal. So, there's relatively little confusion possible. Just FWIW... On 05/16/2011 12:57 PM, Sanne Grinovero wrote: I don't like the TCCL either, so I'll repeat my suggestion from two weeks ago to just have: Cache c = cacheManager.getCache( cacheName, classLoader ); sounds reasonable to me to have the application declare it's intentions once ? BTW I don't like cache.get(K key, ClassV clazz) as we're not speaking only about the get(K) method, but about many methods and this will explode the number of method of Cache; on the other hand I think it;s acceptable to have a single Cache instance used by a single application/classloader. You can still have multiple applications share the same underlying cache and use different classloaders: getCache( cacheName, classLoader ) would return a delegate to the original cache, having a specific marshaller in the invocation context as Trustin was suggesting. Cheers, Sanne 2011/5/16 Pete Muirpm...@redhat.com: On 16 May 2011, at 18:20, Galder Zamarreño wrote: On May 12, 2011, at 11:18 AM, Dan Berindei wrote: On Wed, May 11, 2011 at 11:18 PM, David Bosschaertda...@redhat.com wrote: On 11/05/2011 17:54, Dan Berindei wrote: On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.comwrote: Were we developing for OSGi I would certainly agree with you. However in many environments today we can reasonably expect the TCCL to be set and to be able to load the classes we need. So whilst making it part of the API is the safest option, it's also making complicated an API for the sake of the few at the cost of the many. Further this also seems kinda nasty to me. We know the class (and hence bundle/module) when we put the object into Infinispan, therefore why do we require people to respecify this again? David, can we not actually do something here akin to what we are discussing for Weld? Whereby we can serialize out the bundle id and then find the correct CL based on that when we deserialize. What if the object is a java.util.ArrayList? Each element in the list could belong to a different bundle, so you'd have to write a bundle id for every element in the list. Yes, if you know the Bundle-SymbolicName and Version (or the Bundle ID) you can find its classloader. On the other question, if you're passing in a class object then you can obtain its classloader and hence the bundle where it came from. But, and I think this is what Dan allused to above, is it always true that the class your passing in comes from the bundle that you need to have or could it also come from one of its parent class loaders? Exactly David, sorry if my message was a little cryptic. I think in order to handle every case properly you would have to go through the entire object graph being stored in the cache in order to find all the classloaders/bundle ids that you will need on get(). That seems like a lot of overhead to me, and forcing the user to provide the classloader doesn't seem that bad in comparison. Perhaps we should use something other than a thread-local for this though, so that users can do a onto the result of a cacheManager.getCache(A).usingClassLoader(A.class) and never have to provide the classloader again. In fact I think this is a good idea for the invocation flags we already have, too. It would involve creating lots of overloads in CacheDelegate with a PreInvocationContext parameter and a new CacheDelegateWithContext class to invoke those methods, but the public API would remain the same. No matter how I look at it, putting a classloader in a thread local makes me shiver. I also wonder why we want do this, given we already have a construct called the Thread Local Context Classloader ;-) Either we use that, or use some other mechanism. Just imagine the mayhem you can cause if you forget to clear the thread local. I've done enough of Apache Commons Logging support to understand that you should limit the references to classloaders to the minimum, particularly in system classes/infrastructure. If
Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
What about a helper that just returns a cache with a specific classloader from a cache? cache.withLoader(cl).get(K key) -a On Mon, May 16, 2011 at 11:14 AM, Galder Zamarreño gal...@redhat.comwrote: On May 16, 2011, at 7:57 PM, Sanne Grinovero wrote: I don't like the TCCL either, so I'll repeat my suggestion from two weeks ago to just have: Cache c = cacheManager.getCache( cacheName, classLoader ); sounds reasonable to me to have the application declare it's intentions once ? BTW I don't like cache.get(K key, ClassV clazz) as we're not speaking only about the get(K) method, but about many methods and this will explode the number of method of Cache; on the other hand I think it;s acceptable to have a single Cache instance used by a single application/classloader. You can still have multiple applications share the same underlying cache and use different classloaders: Guys, we're going around in circles. As I said the other week, you can't assume 1 cache = 1 classloader cos for example in the Hibernate 2LC all entities will be stored in a single cache as opposed to today where we have a cache per entity. And if all entities are stored in the same cache, we potentially have a cache that contains data belonging to multiple cache loaders. And the reason for all this is cos we don't support asymmetric clusters. Could someone start a design wiki to grab all the requirements? getCache( cacheName, classLoader ) would return a delegate to the original cache, having a specific marshaller in the invocation context as Trustin was suggesting. Cheers, Sanne 2011/5/16 Pete Muir pm...@redhat.com: On 16 May 2011, at 18:20, Galder Zamarreño wrote: On May 12, 2011, at 11:18 AM, Dan Berindei wrote: On Wed, May 11, 2011 at 11:18 PM, David Bosschaert da...@redhat.com wrote: On 11/05/2011 17:54, Dan Berindei wrote: On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.com wrote: Were we developing for OSGi I would certainly agree with you. However in many environments today we can reasonably expect the TCCL to be set and to be able to load the classes we need. So whilst making it part of the API is the safest option, it's also making complicated an API for the sake of the few at the cost of the many. Further this also seems kinda nasty to me. We know the class (and hence bundle/module) when we put the object into Infinispan, therefore why do we require people to respecify this again? David, can we not actually do something here akin to what we are discussing for Weld? Whereby we can serialize out the bundle id and then find the correct CL based on that when we deserialize. What if the object is a java.util.ArrayList? Each element in the list could belong to a different bundle, so you'd have to write a bundle id for every element in the list. Yes, if you know the Bundle-SymbolicName and Version (or the Bundle ID) you can find its classloader. On the other question, if you're passing in a class object then you can obtain its classloader and hence the bundle where it came from. But, and I think this is what Dan allused to above, is it always true that the class your passing in comes from the bundle that you need to have or could it also come from one of its parent class loaders? Exactly David, sorry if my message was a little cryptic. I think in order to handle every case properly you would have to go through the entire object graph being stored in the cache in order to find all the classloaders/bundle ids that you will need on get(). That seems like a lot of overhead to me, and forcing the user to provide the classloader doesn't seem that bad in comparison. Perhaps we should use something other than a thread-local for this though, so that users can do a onto the result of a cacheManager.getCache(A).usingClassLoader(A.class) and never have to provide the classloader again. In fact I think this is a good idea for the invocation flags we already have, too. It would involve creating lots of overloads in CacheDelegate with a PreInvocationContext parameter and a new CacheDelegateWithContext class to invoke those methods, but the public API would remain the same. No matter how I look at it, putting a classloader in a thread local makes me shiver. I also wonder why we want do this, given we already have a construct called the Thread Local Context Classloader ;-) Either we use that, or use some other mechanism. Just imagine the mayhem you can cause if you forget to clear the thread local. I've done enough of Apache Commons Logging support to understand that you should limit the references to classloaders to the minimum, particularly in system classes/infrastructure. If we need to end up forcing users to register classloaders in these scenarions, we need to do it in such way that either: - we can detect these leaks (it might be a bit
Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
2011/5/16 Pete Muir pm...@redhat.com: This is the hibernate session style contract that Jason is talking about. As the CM can be shared (e.g. in JNDI), then the same Cache object can be returned in multiple applications in the app server, meaning you can't simply associate the CL with a Cache object when it's created. A CM could be JNDI registered, but a Cache is not registered. assuming same cacheManager, two different applications could do: cacheA = cm.getCache( hibernateCache, appAClassLoader ); cacheB = cm.getCache( hibernateCache, appBClassLoader ); cacheA != cacheB still they will delegate toe the same hibernateCache, but being different only in which ClassLoader they set in their invocation context, which will be read by the Unmarshaller. Cheers, Sanne On 16 May 2011, at 18:57, Sanne Grinovero wrote: I don't like the TCCL either, so I'll repeat my suggestion from two weeks ago to just have: Cache c = cacheManager.getCache( cacheName, classLoader ); sounds reasonable to me to have the application declare it's intentions once ? BTW I don't like cache.get(K key, ClassV clazz) as we're not speaking only about the get(K) method, but about many methods and this will explode the number of method of Cache; on the other hand I think it;s acceptable to have a single Cache instance used by a single application/classloader. You can still have multiple applications share the same underlying cache and use different classloaders: getCache( cacheName, classLoader ) would return a delegate to the original cache, having a specific marshaller in the invocation context as Trustin was suggesting. Cheers, Sanne 2011/5/16 Pete Muir pm...@redhat.com: On 16 May 2011, at 18:20, Galder Zamarreño wrote: On May 12, 2011, at 11:18 AM, Dan Berindei wrote: On Wed, May 11, 2011 at 11:18 PM, David Bosschaert da...@redhat.com wrote: On 11/05/2011 17:54, Dan Berindei wrote: On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.com wrote: Were we developing for OSGi I would certainly agree with you. However in many environments today we can reasonably expect the TCCL to be set and to be able to load the classes we need. So whilst making it part of the API is the safest option, it's also making complicated an API for the sake of the few at the cost of the many. Further this also seems kinda nasty to me. We know the class (and hence bundle/module) when we put the object into Infinispan, therefore why do we require people to respecify this again? David, can we not actually do something here akin to what we are discussing for Weld? Whereby we can serialize out the bundle id and then find the correct CL based on that when we deserialize. What if the object is a java.util.ArrayList? Each element in the list could belong to a different bundle, so you'd have to write a bundle id for every element in the list. Yes, if you know the Bundle-SymbolicName and Version (or the Bundle ID) you can find its classloader. On the other question, if you're passing in a class object then you can obtain its classloader and hence the bundle where it came from. But, and I think this is what Dan allused to above, is it always true that the class your passing in comes from the bundle that you need to have or could it also come from one of its parent class loaders? Exactly David, sorry if my message was a little cryptic. I think in order to handle every case properly you would have to go through the entire object graph being stored in the cache in order to find all the classloaders/bundle ids that you will need on get(). That seems like a lot of overhead to me, and forcing the user to provide the classloader doesn't seem that bad in comparison. Perhaps we should use something other than a thread-local for this though, so that users can do a onto the result of a cacheManager.getCache(A).usingClassLoader(A.class) and never have to provide the classloader again. In fact I think this is a good idea for the invocation flags we already have, too. It would involve creating lots of overloads in CacheDelegate with a PreInvocationContext parameter and a new CacheDelegateWithContext class to invoke those methods, but the public API would remain the same. No matter how I look at it, putting a classloader in a thread local makes me shiver. I also wonder why we want do this, given we already have a construct called the Thread Local Context Classloader ;-) Either we use that, or use some other mechanism. Just imagine the mayhem you can cause if you forget to clear the thread local. I've done enough of Apache Commons Logging support to understand that you should limit the references to classloaders to the minimum, particularly in system classes/infrastructure. If we need to end up forcing users to register classloaders in these scenarions, we need to do it in such way that either: - we can detect these leaks (it might be a bit primitive now but
Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
BTW having thought about it more, this seems to be the only option that actually works at the API level, even if it will require some re-eng in Infinispan core. On 16 May 2011, at 19:29, Pete Muir wrote: On 16 May 2011, at 19:24, Sanne Grinovero wrote: 2011/5/16 Pete Muir pm...@redhat.com: This is the hibernate session style contract that Jason is talking about. As the CM can be shared (e.g. in JNDI), then the same Cache object can be returned in multiple applications in the app server, meaning you can't simply associate the CL with a Cache object when it's created. A CM could be JNDI registered, but a Cache is not registered. assuming same cacheManager, two different applications could do: cacheA = cm.getCache( hibernateCache, appAClassLoader ); cacheB = cm.getCache( hibernateCache, appBClassLoader ); cacheA != cacheB still they will delegate toe the same hibernateCache, but being different only in which ClassLoader they set in their invocation context, which will be read by the Unmarshaller. AIUI you just said what I said in different language? ___ 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] JGroupsDistSync and ISPN-83
Manik (and others),
Can you run this code on your laptops and let me know what happened!
Vladimir
public static void main (String [] arg) throws Exception {
final JGroupsDistSync ds = new JGroupsDistSync();
ds.acquireProcessingLock(false, 3, TimeUnit.SECONDS);
System.out.println(Got read lock);
Thread t = new Thread(){
public void run (){
try {
ds.acquireProcessingLock(true, 3, TimeUnit.SECONDS);
System.out.println(Got write lock);
} catch (TimeoutException e) {
System.out.println(e);
}
}
};
t.start();
}
On 11-05-13 4:53 PM, Manik Surtani wrote:
Yes, please have a look. If we are relying on lock upgrades then that's
really bad. I am aware of the inability to (safely) upgrade a RWL and I'm
pretty sure we don't try, but the dist sync codebase has evolved a lot and
could do with some careful analysis.
Sent from my mobile phone
On 12 May 2011, at 09:24, Vladimir Blagojevicvblag...@redhat.com wrote:
On 11-05-11 11:23 AM, Dan Berindei wrote:
If ReentrantReadWriteLock would allow upgrades then you would get a
deadlock when two threads both hold the read lock and try to upgrade
to a write lock at the same time.
There's always a trade-off...
I'm not familiar with the code, but are you sure the read lock is
being held by the same thread that is trying to acquire the write
lock?
Not sure and it sounds counter intuitive that a thread holding a read
lock from cluster invocation is doing state generation for state
transfer as well. But this lock business is fishy and I plan to get to
the bottom of it...
___
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] Fluent configuration wiki update
On 11-05-16 5:15 PM, Galder Zamarreño wrote: Feedback taken onboard: http://community.jboss.org/docs/DOC-14839 On May 16, 2011, at 12:05 PM, Vladimir Blagojevic wrote: Excellent wiki Galder! Finally worth its title (Configuring cache programmatically) Cheers. ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Fluent configuration wiki update
I guess I qualify as others, since I'm looking at similar issues. Got read lock java.util.concurrent.TimeoutException: Thread-1 could not obtain exclusive processing lock after 3 seconds. Locks in question are java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock@16aa37a6[Read locks = 1] and java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock@12b7eea[Unlocked] This is on the latest master. Erik -Original Message- From: infinispan-dev-boun...@lists.jboss.org [mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Vladimir Blagojevic Sent: Monday, May 16, 2011 4:27 PM To: infinispan -Dev List Cc: Galder Zamarreño Subject: Re: [infinispan-dev] Fluent configuration wiki update On 11-05-16 5:15 PM, Galder Zamarreño wrote: Feedback taken onboard: http://community.jboss.org/docs/DOC-14839 On May 16, 2011, at 12:05 PM, Vladimir Blagojevic wrote: Excellent wiki Galder! Finally worth its title (Configuring cache programmatically) Cheers. ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message. ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] JGroupsDistSync and ISPN-83
Same result here - where you expecting something different?
Cheers,
Sanne
2011/5/16 Erik Salter esal...@bnivideo.com:
EDIT: Originally posted in the wrong thread. I blame Outlook.
I guess I qualify as others, since I'm looking at similar issues.
Got read lock
java.util.concurrent.TimeoutException: Thread-1 could not obtain exclusive
processing lock after 3 seconds. Locks in question are
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock@16aa37a6[Read
locks = 1] and
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock@12b7eea[Unlocked]
This is on the latest master.
Erik
-Original Message-
From: infinispan-dev-boun...@lists.jboss.org
[mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Vladimir
Blagojevic
Sent: Monday, May 16, 2011 4:25 PM
To: infinispan -Dev List
Cc: Manik Surtani
Subject: Re: [infinispan-dev] JGroupsDistSync and ISPN-83
Manik (and others),
Can you run this code on your laptops and let me know what happened!
Vladimir
public static void main (String [] arg) throws Exception {
final JGroupsDistSync ds = new JGroupsDistSync();
ds.acquireProcessingLock(false, 3, TimeUnit.SECONDS);
System.out.println(Got read lock);
Thread t = new Thread(){
public void run (){
try {
ds.acquireProcessingLock(true, 3, TimeUnit.SECONDS);
System.out.println(Got write lock);
} catch (TimeoutException e) {
System.out.println(e);
}
}
};
t.start();
}
On 11-05-13 4:53 PM, Manik Surtani wrote:
Yes, please have a look. If we are relying on lock upgrades then that's
really bad. I am aware of the inability to (safely) upgrade a RWL and I'm
pretty sure we don't try, but the dist sync codebase has evolved a lot and
could do with some careful analysis.
Sent from my mobile phone
On 12 May 2011, at 09:24, Vladimir Blagojevicvblag...@redhat.com wrote:
On 11-05-11 11:23 AM, Dan Berindei wrote:
If ReentrantReadWriteLock would allow upgrades then you would get a
deadlock when two threads both hold the read lock and try to upgrade
to a write lock at the same time.
There's always a trade-off...
I'm not familiar with the code, but are you sure the read lock is
being held by the same thread that is trying to acquire the write
lock?
Not sure and it sounds counter intuitive that a thread holding a read
lock from cluster invocation is doing state generation for state
transfer as well. But this lock business is fishy and I plan to get
to the bottom of it...
___
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
The information contained in this message is legally privileged and
confidential, and is intended for the individual or entity to whom it is
addressed (or their designee). If this message is read by anyone other than
the intended recipient, please be advised that distribution of this message,
in any form, is strictly prohibited. If you have received this message in
error, please notify the sender immediately and delete or destroy all copies
of this message.
___
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] [Pull Request] Modular Classloading Compatibility
Not to be the guy that breaks the circle, how about the threads that handle incoming RPCs from other nodes? With storeAsBinary=false those threads have to unmarshal the objects in order to store them on the local node, so we'd need a way to register a classloader with the cache, not just with the cache session. If we use a single cache for all Hibernate entities, regardless of application, this means the cache could receive application objects from the other nodes without the application even being deployed. Does this mean we'll require storeAsBinary=true in all Hibernate 2LC configurations? Dan On Mon, May 16, 2011 at 9:54 PM, David M. Lloyd david.ll...@redhat.com wrote: I know, we can just attach the class loader to the cache! Okay, just kidding, but Galder is right, this conversation is going in circles. We already discussed that in this thread and a number of points were raised for and against. On 05/16/2011 01:20 PM, Adrian Cole wrote: What about a helper that just returns a cache with a specific classloader from a cache? cache.withLoader(cl).get(K key) -a On Mon, May 16, 2011 at 11:14 AM, Galder Zamarreño gal...@redhat.com mailto:gal...@redhat.com wrote: On May 16, 2011, at 7:57 PM, Sanne Grinovero wrote: I don't like the TCCL either, so I'll repeat my suggestion from two weeks ago to just have: Cache c = cacheManager.getCache( cacheName, classLoader ); sounds reasonable to me to have the application declare it's intentions once ? BTW I don't like cache.get(K key, ClassV clazz) as we're not speaking only about the get(K) method, but about many methods and this will explode the number of method of Cache; on the other hand I think it;s acceptable to have a single Cache instance used by a single application/classloader. You can still have multiple applications share the same underlying cache and use different classloaders: Guys, we're going around in circles. As I said the other week, you can't assume 1 cache = 1 classloader cos for example in the Hibernate 2LC all entities will be stored in a single cache as opposed to today where we have a cache per entity. And if all entities are stored in the same cache, we potentially have a cache that contains data belonging to multiple cache loaders. And the reason for all this is cos we don't support asymmetric clusters. Could someone start a design wiki to grab all the requirements? getCache( cacheName, classLoader ) would return a delegate to the original cache, having a specific marshaller in the invocation context as Trustin was suggesting. Cheers, Sanne 2011/5/16 Pete Muir pm...@redhat.com mailto:pm...@redhat.com: On 16 May 2011, at 18:20, Galder Zamarreño wrote: On May 12, 2011, at 11:18 AM, Dan Berindei wrote: On Wed, May 11, 2011 at 11:18 PM, David Bosschaert da...@redhat.com mailto:da...@redhat.com wrote: On 11/05/2011 17:54, Dan Berindei wrote: On Wed, May 11, 2011 at 7:08 PM, Pete Muirpm...@redhat.com mailto:pm...@redhat.com wrote: Were we developing for OSGi I would certainly agree with you. However in many environments today we can reasonably expect the TCCL to be set and to be able to load the classes we need. So whilst making it part of the API is the safest option, it's also making complicated an API for the sake of the few at the cost of the many. Further this also seems kinda nasty to me. We know the class (and hence bundle/module) when we put the object into Infinispan, therefore why do we require people to respecify this again? David, can we not actually do something here akin to what we are discussing for Weld? Whereby we can serialize out the bundle id and then find the correct CL based on that when we deserialize. What if the object is a java.util.ArrayList? Each element in the list could belong to a different bundle, so you'd have to write a bundle id for every element in the list. Yes, if you know the Bundle-SymbolicName and Version (or the Bundle ID) you can find its classloader. On the other question, if you're passing in a class object then you can obtain its classloader and hence the bundle where it came from. But, and I think this is what Dan allused to above, is it always true that the class your passing in comes from the bundle that you need to have or could it also come from one of its parent class loaders? Exactly David, sorry if my message was a little cryptic. I think in order to handle every case properly you would have to go through the entire object graph being
