[jbosscache-dev] easing the path for clientstogetaroundredeployment class loading issues in JBC

Wed Nov 29 21:14:35 EST 2006

Yes pls
--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat

Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani


On 29 Nov 2006, at 18:41, Galder Zamarreno wrote:

> Btw, I have committed it to Branch_JBossCache_1_4_0.
>
> Do we want this in HEAD as well? I guess so, but just double  
> checking here.
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> IT executives: Red Hat still #1 for value http://www.redhat.com/ 
> promo/vendor/
>
> -----Original Message-----
> From: Galder Zamarreno
> Sent: 29 November 2006 19:40
> To: 'Manik Surtani'
> Cc: jbosscache-dev at lists.jboss.org
> Subject: RE: [jbosscache-dev] easing the path for  
> clientstogetaroundredeployment class loading issues in JBC
>
> Ok, sounds good.
>
> I have committed the UT (o.j.c.m.RedeploymentEmulationTest) and the  
> QA entry.
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> IT executives: Red Hat still #1 for value http://www.redhat.com/ 
> promo/vendor/
>
> -----Original Message-----
> From: Manik Surtani [mailto:manik at jboss.org]
> Sent: 28 November 2006 23:31
> To: Galder Zamarreno
> Cc: jbosscache-dev at lists.jboss.org
> Subject: Re: [jbosscache-dev] easing the path for  
> clientstogetaroundredeployment class loading issues in JBC
>
> Comments below:
>
> On 28 Nov 2006, at 19:32, Galder Zamarreno wrote:
>
>> I have also been working on the QA entry to go along with this:
>>
>> Q. Can I use <literal>TreeCache</literal> Marshalling in order to
>> get around ClassCastExceptions happening when accessing data in the
>> cache that has just been redeployed?
>
>
> I'd change this to:
> 	
> 	the <literal>useRegionBasedMarshalling</literal> attribute in JBoss
> Cache ...
>
>>
>> R. Yes, you can. Originally, <literal>TreeCache</literal>
>> Marshalling was designed firstly, to provide improved performance
>> over Java serialization and secondly, as a workaround for those
>> replicated caches that upon state transfer did not have access to
>> the classloaders defining the objects in the cache.
>>
>
> This is slightly incorrect.  The original use case was a workaround
> for replicated caches that did not have context classloaders
> registered.  In 1.4.x, I added the JBoss Serialization stuff and the
> magic numbers for known types for performance.
>
>> On each deployment, JBoss creates a new classloader per the top
>> level deployment artifact, for example an EAR. You also have to
>> bear in mind that a class in an application server is defined not
>> only by the class name but also its classloader. So, assuming that
>> the cache is not deployed as part of your deployment, you could
>> deploy an application and put instances of
>> classes belonging to this deployment inside the cache. If you did a
>> redeployment and try to do a get operation of the data previously
>> put, this would result on a ClassCastException. This is because
>> even though the class names are the same, the class definitions are
>> not. The current classloader is different to the one when the
>> classes were originally put.
>>
>> By enabling marshalling, you can control the lifecycle of the data
>> in the cache and if on undeployment, you inactivate the region and
>> unregister the classloader that you'd have registered on
>> deployment, you'd evict the data in the cache locally. That means
>> that in the next deployment, the data won't be in the cache,
>> therefore avoiding the problem.
>>
>> Obviously, using marshalling to get around this problem is only
>> recommended when you have some kind of persistence backing where
>> the data survives, for example using CacheLoaders, or when
>> JBossCache is used as a second level cache in a persistence  
>> framework.
>>
>> Galder Zamarreño
>> Sr. Software Maintenance Engineer
>> JBoss, a division of Red Hat
>>
>> IT executives: Red Hat still #1 for value http://www.redhat.com/
>> promo/vendor/
>>
>> -----Original Message-----
>> From: jbosscache-dev-bounces at lists.jboss.org [mailto:jbosscache-dev-
>> bounces at lists.jboss.org] On Behalf Of Galder Zamarreno
>> Sent: 27 November 2006 12:55
>> To: Manik Surtani
>> Cc: jbosscache-dev at lists.jboss.org
>> Subject: RE: [jbosscache-dev] easing the path for
>> clientstogetaroundredeployment class loading issues in JBC
>>
>> I have been able to reproduce a similar behaviour without needing
>> to have an integration test with AS. We don't currently have tests
>> like this.
>>
>> It assumes two classloaders, the default AppClassLoader
>> (ClassLoader.getSystemClassLoader()) and another URL based one
>> (parent is null, so that it's independent from the default, similar
>> to redeployments where classloaders are siblings which don't know
>> about each other) created in the unit test.
>>
>> Once the URL one is created, I switch the context class loader to
>> it and creates a new instance of org.jgroups.Global from
>> jgroups.jar. I thought about creating a new instance of any other
>> JBC class, but I can't assume that build has been executed and the
>> ide class file location is not the same for everyone so couldn't
>> assume that either.
>>
>> Once the new instance is in the cache, I switch to the system class
>> loader and attempt to do a get which results in a
>> ClassCastException as expected.
>>
>> The original test is pretty much the same as this, but with the
>> added control over classloader registration and region inactivation.
>>
>> Once I switch to the URL based classloader, I register it to the
>> root. I create the new instance and do the put followed by
>> inactivation of the region and unregistering of the class loader.
>>
>> I then switch the context class loader to the old AppClassLoader
>> and register it. I do a get operation for the data put earlier and
>> returns null which is what is expected as the data referenced by
>> the previous class loader does not exist any more. I end up
>> inactivating and unregistering the class loader.
>>
>> I have attached the UT so that you can have a look to it.
>>
>> Galder Zamarreño
>> Sr. Software Maintenance Engineer
>> JBoss, a division of Red Hat
>>
>> IT executives: Red Hat still #1 for value http://www.redhat.com/
>> promo/vendor/
>>
>> -----Original Message-----
>> From: Manik Surtani [mailto:manik at jboss.org]
>> Sent: 24 November 2006 19:09
>> To: Galder Zamarreno
>> Cc: jbosscache-dev at lists.jboss.org
>> Subject: Re: [jbosscache-dev] easing the path for clients
>> togetaroundredeployment class loading issues in JBC
>>
>> If you can recreate the CCE on redeployment I'd prefer it.  Don't
>> worry about 1.4.1.CR1, it will probably be mid-week anyway.
>> --
>> Manik Surtani
>>
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
>>
>> Email: manik at jboss.org
>> Telephone: +44 7786 702 706
>> MSN: manik at surtani.org
>> Yahoo/AIM/Skype: maniksurtani
>>
>>
>>
>> On 24 Nov 2006, at 16:54, Galder Zamarreno wrote:
>>
>>> The UT that I have is pretty simple. You start a local cache, set
>>> use marshalling and register Thread.currentThread
>>> ().getContextClassLoader().
>>>
>>> You put some data in the cache and then you inactivate the region
>>> and unregister the classloader.
>>>
>>> Further checks on whether the data entered exists returns false.
>>>
>>> Is this good enough? I thought about creating a test where I can
>>> reproduce the ClassCastException on redeployment but I'll need more
>>> time to create a UT like that.
>>>
>>> Galder Zamarreño
>>> Sr. Software Maintenance Engineer
>>> JBoss, a division of Red Hat
>>>
>>> IT executives: Red Hat still #1 for value http://www.redhat.com/
>>> promo/vendor/
>>>
>>> -----Original Message-----
>>> From: jbosscache-dev-bounces at lists.jboss.org [mailto:jbosscache-dev-
>>> bounces at lists.jboss.org] On Behalf Of Galder Zamarreno
>>> Sent: 24 November 2006 17:11
>>> To: Manik Surtani
>>> Cc: jbosscache-dev at lists.jboss.org
>>> Subject: RE: [jbosscache-dev] easing the path for clients
>>> togetaroundredeployment class loading issues in JBC
>>>
>>> When are you planning to release 1.4.1.CR? I'm gonna try to do this
>>> over the weekend.
>>>
>>> Galder Zamarreño
>>> Sr. Software Maintenance Engineer
>>> JBoss, a division of Red Hat
>>>
>>> IT executives: Red Hat still #1 for value http://www.redhat.com/
>>> promo/vendor/
>>>
>>> -----Original Message-----
>>> From: Manik Surtani [mailto:msurtani at redhat.com]
>>> Sent: 17 November 2006 14:21
>>> To: Galder Zamarreno
>>> Cc: Brian Stansberry; jbosscache-dev at lists.jboss.org
>>> Subject: Re: [jbosscache-dev] easing the path for clients to
>>> getaroundredeployment class loading issues in JBC
>>>
>>> Ok, Galder, if you don't mind, could you put together a unit test  
>>> and
>>> an FAQ entry in the 1.4.x branch, so that this makes it in the next
>>> 1.4.1.CR release?
>>>
>>> Also raise a JIRA about this for 2.0.0.
>>>
>>> Thanks,
>>> --
>>> Manik Surtani
>>>
>>> Lead, JBoss Cache
>>> JBoss, a division of Red Hat
>>>
>>> Email: manik at jboss.org
>>> Telephone: +44 7786 702 706
>>> MSN: manik at surtani.org
>>> Yahoo/AIM/Skype: maniksurtani
>>>
>>>
>>> On 17 Nov 2006, at 11:56, Galder Zamarreno wrote:
>>>
>>>> +1
>>>>
>>>> Galder Zamarreño
>>>> Sr. Software Maintenance Engineer
>>>> JBoss, a division of Red Hat
>>>>
>>>> IT executives: Red Hat still #1 for value http://www.redhat.com/
>>>> promo/vendor/
>>>>
>>>> -----Original Message-----
>>>> From: Manik Surtani [mailto:msurtani at redhat.com]
>>>> Sent: 07 November 2006 10:01
>>>> To: Galder Zamarreno
>>>> Cc: Brian Stansberry; jbosscache-dev at lists.jboss.org
>>>> Subject: Re: [jbosscache-dev] easing the path for clients to
>>>> getaroundredeployment class loading issues in JBC
>>>>
>>>> Hi,
>>>>
>>>> Interesting that enabling a marshaller even helps with non-
>>>> replicated
>>>> cases where a marshaller is NOT needed!  :-)
>>>>
>>>> I suspect this is emergent behaviour since enabling the marshaller
>>>> allows you to attach classloaders for regions (throws exceptions
>>>> otherwise).  So the *intended* behaviour is for this to work with
>>>> replication only; if we want to make this a *feature* (and I  
>>>> suspect
>>>> we do) we should refactor and document accordingly.
>>>>
>>>> If we have a UT for this and know that this works, we could add a
>>>> FAQ
>>>> for this for the 1.4.x series, and engineer it properly in 2.0.0.
>>>>
>>>> Thoughts?
>>>> --
>>>> Manik Surtani
>>>>
>>>> Lead, JBoss Cache
>>>> JBoss, a division of Red Hat
>>>>
>>>> Email: msurtani at redhat.com
>>>> Telephone: +44 7786 702 706
>>>> MSN: manik at surtani.org
>>>> Yahoo/AIM/Skype: maniksurtani
>>>>
>>>>
>>>>
>>>> On 3 Nov 2006, at 13:05, Galder Zamarreno wrote:
>>>>
>>>>> In this specific case, it was a second level cache for EJB3 entity
>>>>> beans, so I guess there's not much of a problem in evicting on
>>>>> undeployment.
>>>>>
>>>>> This is a different use case to the one where you start JBC, state
>>>>> transfer occurs and you don't have all the classloaders.
>>>>>
>>>>> I guess another use for marshalling would be with isolated
>>>>> deployments, where JBC classloader is located in the default
>>>>> repository and u have several isolated applications populating  
>>>>> that
>>>>> cache.
>>>>>
>>>>> However, in this particular case about 2nd level cache
>>>>> redeployment, do you think it's necessary to use marshalling? A
>>>>> simple evict everything on undeployment would be sufficient. What
>>>>> do you think?
>>>>>
>>>>> Galder Zamarreño
>>>>> Sr. Software Maintenance Engineer
>>>>> JBoss, a division of Red Hat
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Brian Stansberry
>>>>> Sent: 02 November 2006 16:58
>>>>> To: Galder Zamarreno; 'jbosscache-dev at lists.jboss.org'
>>>>> Subject: RE: [jbosscache-dev] easing the path for clients to
>>>>> getaroundredeployment class loading issues in JBC
>>>>>
>>>>> Yeah, it works if it's OK that all the cached data was lost :-).
>>>>> With a replicated cache, the node going through redeploy evicts
>>>>> everything but can then recover it from another node.  With local
>>>>> cache, it's evicted and gone.  Actually, not technically evicted,
>>>>> just removed w/o going through the interceptor chain.
>>>>>
>>>>> If they want to keep the cached data, they'd need to store it in
>>>>> the cache as a byte[] or something and deserialize after redeploy.
>>>>> Or, use a non-passivating cache loader and recover from the cache
>>>>> loader.  Or use a passivating cache loader and manually evict()
>>>>> each node before undeploying.
>>>>>
>>>>> Don't think I'll document this particular use, because calling
>>>>> inactivateRegion() as a shortcut for calling evict() is not really
>>>>> what the method's meant for.  But I'm sure the docs in general on
>>>>> how to use this could be improved.
>>>>>
>>>>> Galder Zamarreno wrote:
>>>>>> I have just tried it with a local cache and it worked.
>>>>>>
>>>>>> One of the customers was using JBC 1.0, so the work was not in
>>>>>> vain :)
>>>>>>
>>>>>> It might be worth adding the redeployment case to the
>>>>>> documentation in the marshaller section.
>>>>>>
>>>>>> Galder Zamarreño
>>>>>> Sr. Software Maintenance Engineer
>>>>>> JBoss, a division of Red Hat
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: jbosscache-dev-bounces at lists.jboss.org
>>>>>> [mailto:jbosscache-dev-bounces at lists.jboss.org] On Behalf Of
>>>>>> Galder Zamarreno
>>>>>> Sent: 02 November 2006 16:31
>>>>>> To: Brian Stansberry; jbosscache-dev at lists.jboss.org
>>>>>> Subject: RE: [jbosscache-dev] easing the path for clients to
>>>>>> getaroundredeployment class loading issues in JBC
>>>>>>
>>>>>> I did suggest this to Manik, but he told me that marshalling
>>>>>> would not work on local caches, but only in replicated ones.
>>>>>> I might have misunderstood him.
>>>>>>
>>>>>> The doc focuses on the state transfer issues when class
>>>>>> loaders are not still available.
>>>>>>
>>>>>> Galder Zamarreño
>>>>>> Sr. Software Maintenance Engineer
>>>>>> JBoss, a division of Red Hat
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Brian Stansberry
>>>>>> Sent: 02 November 2006 15:58
>>>>>> To: Galder Zamarreno; jbosscache-dev at lists.jboss.org
>>>>>> Subject: RE: [jbosscache-dev] easing the path for clients to
>>>>>> get aroundredeployment class loading issues in JBC
>>>>>>
>>>>>> There's already an API for this kind of use case. I'm going
>>>>>> to speak in 1.x terms here:
>>>>>>
>>>>>> // Config for cache startup
>>>>>> TreeCache.setUseRegionBasedMarshalling(true);
>>>>>> TreeCache.inactiveOnStartup(true); // suppresses initial
>>>>>> state transfer
>>>>>>
>>>>>> // Deploy phase -- app creates a region and registers it's
>>>>>> classloader TreeCache.registerClassloader(Fqn, ClassLoader);
>>>>>> // Then transfer the state for the region, since you've now
>>>>>> go the correct classloader TreeCache.activateRegion(Fqn);
>>>>>>
>>>>>> // Operate normallly
>>>>>>
>>>>>> // Undeploy phase -- deactivate the region, which evicts all  
>>>>>> nodes
>>>>>> TreeCache.inactivateRegion(Fqn)
>>>>>> // Don't leak a classloader ref
>>>>>> TreeCache.unregisterClassloader(Fqn);
>>>>>>
>>>>>> - Brian
>>>>>>
>>>>>> jbosscache-dev-bounces at lists.jboss.org wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have seen couple of people with the same issue in the past few
>>>>>>> weeks. I already had a chat with Manik but it was more about
>>>>>>> solving
>>>>>>> the problem at the time rather than thinking how we can make it
>>>>>>> easier for the customers to get around it.
>>>>>>>
>>>>>>> Applications which are redeployed and interact with the cache  
>>>>>>> are
>>>>>>> quite likely to encounter class loading issues. They tend to
>>>>>>> enter
>>>>>>> data in the cache, they get redeployed, try accessing the data
>>>>>>> entered previously and you end up with a ClassCastException.
>>>>>>>
>>>>>>> For caches managed by Hibernate, this is not a problem cos
>>>>>>> Hibernate
>>>>>>> does the cleanup on undeployment, asking clients to close the
>>>>>>> session.
>>>>>>>
>>>>>>> In the rest of cases, clients have to iterate over evict()  
>>>>>>> calls.
>>>>>>> This will be solved in JBC 2.0 with evictSubtree() method that
>>>>>>> can
>>>>>>> be recursive.
>>>>>>>
>>>>>>> However, clients still need to code an MBean which is part of  
>>>>>>> the
>>>>>>> lifecycle of the deployment, and upon destroy, it calls
>>>>>>> evictSubtree().
>>>>>>>
>>>>>>> The cache configuration would have to depend on this MBean in
>>>>>>> case
>>>>>>> the cache deployment is done inside the client's application.
>>>>>>> Otherwise, we could assume that undeployment of JBC is quite
>>>>>>> likely
>>>>>>> due to AS undeployment in which case there's no need for  
>>>>>>> cleanup.
>>>>>>>
>>>>>>> Have you got any ideas of anything else that could be done in
>>>>>>> JBC to
>>>>>>> help speed up this implementation and make it less of daunting
>>>>>>> task
>>>>>>> for the customer?
>>>>>>>
>>>>>>> I guess the main part is documenting all this.
>>>>>>>
>>>>>>> Galder Zamarreño
>>>>>>> Sr. Software Maintenance Engineer
>>>>>>> JBoss, a division of Red Hat
>>>>>
>>>>> _______________________________________________
>>>>> jbosscache-dev mailing list
>>>>> jbosscache-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
>>
>
>