[infinispan-dev] [Pull Request] Modular Classloading Compatibility

Dan Berindei dan.berindei at gmail.com
Thu May 19 10:43:16 EDT 2011


On Thu, May 19, 2011 at 1:31 PM, Galder Zamarreño <galder at redhat.com> wrote:
>
> On May 19, 2011, at 12:11 PM, Manik Surtani wrote:
>
>> Guys - what are we talking about?  Specifying ClassLoaders is only meaningful if storeAsBinary is set to true.
>
> Ok, that was not clear to me throughout the discussion.
>

That wasn't clear for me either. And we have at least one user trying
storeAsBinary==true because it has much better performance
(http://community.jboss.org/message/604831). Maybe the performance
difference isn't so great any more after the latest commits, but I'm
sure there is still a difference.

I'm not suggesting that we absolutely need to make storeAsBinary==true
work with multiple classloaders per cache or even per cache manager,
but we should support an alternative for OSGi users who want to use
storeAsBinary==true. That means at least having a clear way to specify
in one classloader per cache manager.

Note that this will also help us in the storeAsBinary==false case,
because then we will be able to set the bootstrap classloader as the
cache manager classloader and so will be able to avoid the cache
manager threads hanging on to an undeployed application's classes.


>> In general, any situation where you have code booted off different ClassLoaders running in the same JVM and sharing the same cache (or cache manager), you would *need* to set storeAsBinary to true to get around deserialization issues on remote nodes.
>>
>> StoreAsBinary = false only really works for trivial cases where caches/cache managers run in environments where only one cache loader is in effect.  I.e., *not* JBoss/Java EE/Hibernate/OSGi/etc.  This is one of the reasons why we considered setting storeAsBinary to true by default (and we see similar techniques in competing data grids).
>

We already have an example of a guy who managed to make it work, we
just need to specify the behaviour of Infinispan so that he can rely
on it working.

Cheers
Dan


> This is clear now, thanks.
>
>>
>> Cheers
>> Manik
>>
>>
>> On 19 May 2011, at 10:55, Galder Zamarreño wrote:
>>
>>> would be different cache instances. The problem then is that if an RPC comes for "entities" cache and entity P1, which of the "entities" caches do I go for? You'd need to know which classloader P1 is living in the remote node and you'd have to now that at the Infinispan level to be able to store it in a non-binary format.
>>
>> --
>> Manik Surtani
>> manik at jboss.org
>> twitter.com/maniksurtani
>>
>> Lead, Infinispan
>> http://www.infinispan.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>



More information about the infinispan-dev mailing list