[jbosscache-dev] easing the path for clientstogetaroundredeployment class loading issues in JBC
Manik Surtani
manik at jboss.org
Tue Nov 28 17:30:49 EST 2006
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
>
>
More information about the jbosscache-dev
mailing list