Re: [infinispan-dev] [Pull Request] Modular ClassloadingCompatibility
The only contract WRT to TCCL that I know of is the EE specification. Every other use case out there is going to be underspecified. Ultimately it's a very fragile contract, and is misused more than not. The only silver-bullet solution is to make the classloader part of the API interaction, either indirectly via a type, or introducing a more formal session notion. To be honest, I have long thought infinispan API needs a hibernate session style contract. The advanced invocation context feature is clunky and uses thread locals (which has problems of its own). If you had a session you can better control user interaction for things like this without screwing up your API, and you can do it with minimal perf overhead (it's just a tiny blob non-concurrent thread state that would get passed to the cache per invocation). On 5/9/11 10:37 AM, Pete Muir wrote: > Ok, let me stew on that ;-) > > On 9 May 2011, at 16:35, David Bosschaert wrote: > >> If you have a Bundle object or BundleContext object you can figure out what >> classloader is associated with that. Also, if you have a class from a bundle >> you can find out what it's classloader is (obviously). >> >> However, you need to have one of those things to find this out. There is >> nothing magically available in the current context to tell you what the >> current Bundle is. >> It's generally really easy for the caller though to find out what the >> classloader is, though... If you have bundle X, you'd know a class from that >> bundle a.b.c.D (any class will do). Then you can simply call >> D.class.getClassLoader() and you've got the Bundle Classloader. >> >> Hope this helps, >> >> David >> >> On 09/05/2011 16:27, Pete Muir wrote: >>> The issue that David raises is that in an OSGi env that this wouldn't be >>> done by OSGi so would be up to the user or would require some extra >>> integration library. I'm not even sure if this is possible in OSGi? David, >>> is there anyway for a framework to "find out" the current bundle >>> classloader in OSGi rather than having to be told it (i.e. push rather than >>> pull)? >>> >>> The idea is that in AS that by doing (a) it would require the integration >>> to make sure the TCCL is set before Infinispan is called (this is the way >>> many things are integrated into GF for example). >>> >>> On 5 May 2011, at 20:05, Emmanuel Bernard wrote: >>> Quick question. In case of 2.a (ie setting the TCCL), this is a requirement for frameworks and libraries using Infinispan, right? Not / never for a user application using Infinispan (in this case it seems that the application class loader will do the right thing and is set as the TCCL by the AS environment)? Emmanuel On 5 mai 2011, at 10:55, Pete Muir wrote: > I talked about this with Emmanuel last night, and we were > > a) concerned about the pollution of the API that this implies > b) not sure why we need to do this > > So I also spoke to Jason to understand his initial motivation, and from > this chat I think it's clear that things have gone off course here. > > Jason raised two issues with modularity/classloading in Infinispan: > > 1) Using the TCCL as the classloader to load Infinispan classes is a bad > idea. Instead we should use > org.infinispan.foo.Bar.getClass().getClassLoader(). > > 2) When we need to load application classes we need a different approach > to that used today. Most of the time the TCCL is perfect for this. > However *sometimes* Infinispan may be invoked outside of the application, > when the TCCL may not be set in AS7. Jason and I discussed three options: > > a) require (through a platform integration documentation contract) that > the TCCL must always be set when Infinispan is invoked. > b) Have some sort of InvocationContext which knows what the correct > classloader to use is (aka Hibernate/Seam/Weld design where there is a > per-application construct based on a ThreadLocal). Given this hasn't been > designed into the core, it seems like a large retrofit > c) Make users specify the CL (directly or indirectly) via the API (as we > discussed). > > Personally I think that (a) is the best approach right now, and is not > that onerous a requirement. > > We might want to make the TCCL usage pluggable for OSGI envs. Cc'd David > to get his feedback. > > On 4 May 2011, at 10:46, Dan Berindei wrote: > >> On Wed, May 4, 2011 at 5:09 PM, Pete Muir wrote: >>> On 4 May 2011, at 05:34, Dan Berindei wrote: >>> On Wed, May 4, 2011 at 10:14 AM, Galder Zamarreño wrote: > On May 3, 2011, at 2:33 PM, Sanne Grinovero wrote: > >> 2011/5/3 "이희승 (Trustin Lee)": >>> On 05/03/2011 05:08 AM, Sanne Grinovero wrote: 2011/5/2 Manik Surtani: > On 1 May 2011, at 13:38,
Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
On 9 May 2011, at 18:02, Galder Zamarreño wrote: > > On May 9, 2011, at 7:01 PM, Galder Zamarreño wrote: > >> Guys, >> >> It's funny that we're talking about this but this appears to be precisely >> the use case that we don't support as per user forum post in: >> http://community.jboss.org/thread/166080?tstart=0 >> >> Pete, do we have a JIRA for this? If not, would you mind creating one? > > If not, would you mind creating one? It's https://issues.jboss.org/browse/ISPN-1096 > >> >> Cheers, >> >> On May 9, 2011, at 5:37 PM, Pete Muir wrote: >> >>> Ok, let me stew on that ;-) >>> >>> On 9 May 2011, at 16:35, David Bosschaert wrote: >>> If you have a Bundle object or BundleContext object you can figure out what classloader is associated with that. Also, if you have a class from a bundle you can find out what it's classloader is (obviously). However, you need to have one of those things to find this out. There is nothing magically available in the current context to tell you what the current Bundle is. It's generally really easy for the caller though to find out what the classloader is, though... If you have bundle X, you'd know a class from that bundle a.b.c.D (any class will do). Then you can simply call D.class.getClassLoader() and you've got the Bundle Classloader. Hope this helps, David On 09/05/2011 16:27, Pete Muir wrote: > The issue that David raises is that in an OSGi env that this wouldn't be > done by OSGi so would be up to the user or would require some extra > integration library. I'm not even sure if this is possible in OSGi? > David, is there anyway for a framework to "find out" the current bundle > classloader in OSGi rather than having to be told it (i.e. push rather > than pull)? > > The idea is that in AS that by doing (a) it would require the integration > to make sure the TCCL is set before Infinispan is called (this is the way > many things are integrated into GF for example). > > On 5 May 2011, at 20:05, Emmanuel Bernard wrote: > >> Quick question. >> In case of 2.a (ie setting the TCCL), this is a requirement for >> frameworks and libraries using Infinispan, right? Not / never for a user >> application using Infinispan (in this case it seems that the application >> class loader will do the right thing and is set as the TCCL by the AS >> environment)? >> >> Emmanuel >> >> On 5 mai 2011, at 10:55, Pete Muir wrote: >> >>> I talked about this with Emmanuel last night, and we were >>> >>> a) concerned about the pollution of the API that this implies >>> b) not sure why we need to do this >>> >>> So I also spoke to Jason to understand his initial motivation, and from >>> this chat I think it's clear that things have gone off course here. >>> >>> Jason raised two issues with modularity/classloading in Infinispan: >>> >>> 1) Using the TCCL as the classloader to load Infinispan classes is a >>> bad idea. Instead we should use >>> org.infinispan.foo.Bar.getClass().getClassLoader(). >>> >>> 2) When we need to load application classes we need a different >>> approach to that used today. Most of the time the TCCL is perfect for >>> this. However *sometimes* Infinispan may be invoked outside of the >>> application, when the TCCL may not be set in AS7. Jason and I discussed >>> three options: >>> >>> a) require (through a platform integration documentation contract) that >>> the TCCL must always be set when Infinispan is invoked. >>> b) Have some sort of InvocationContext which knows what the correct >>> classloader to use is (aka Hibernate/Seam/Weld design where there is a >>> per-application construct based on a ThreadLocal). Given this hasn't >>> been designed into the core, it seems like a large retrofit >>> c) Make users specify the CL (directly or indirectly) via the API (as >>> we discussed). >>> >>> Personally I think that (a) is the best approach right now, and is not >>> that onerous a requirement. >>> >>> We might want to make the TCCL usage pluggable for OSGI envs. Cc'd >>> David to get his feedback. >>> >>> On 4 May 2011, at 10:46, Dan Berindei wrote: >>> On Wed, May 4, 2011 at 5:09 PM, Pete Muir wrote: > On 4 May 2011, at 05:34, Dan Berindei wrote: > >> On Wed, May 4, 2011 at 10:14 AM, Galder Zamarreño >> wrote: >>> On May 3, 2011, at 2:33 PM, Sanne Grinovero wrote: >>> 2011/5/3 "이희승 (Trustin Lee)": > On 05/03/2011 05:08 AM, Sanne Grinovero wrote: >> 2011/5/2 Manik Surtani: >>> On 1 May 2011, at 13:38, Pete Muir wrote: >>> >> As in, user API? That's a little
[infinispan-dev] JGroupsDistSync and ISPN-83
Hi, Would you please confirm my understanding and reading of javadoc for ReentrantReadWriteLock under section for "lock downgrading". It says: "Reentrancy also allows downgrading from the write lock to a read lock, by acquiring the write lock, then the read lock and then releasing the write lock. However, upgrading from a read lock to the write lock is not possible." ReentrantReadWriteLock javadoc code example with class CacheData also shows how a thread owning a read lock first has to release it in order to obtain a write lock! So a thread owning a read lock first has to release a read lock in order to obtain a write lock? This is very symptomatic in logs of ISPN-83 such as this one https://issues.jboss.org/secure/attachment/12341409/server1.log Recall how FLUSH stops all invocations on cluster and therefore all read lock acquisitions in JGroupsDistSync ultimately enabling smooth write lock acquisitions for state transfer and what not. In conclusion this leads me wondering if the culprit of all this FLUSH mess is rooted in read/write lock semantics from above? Regards, Vladimir ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
