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

Manik Surtani manik at jboss.org
Fri Nov 24 13:08:39 EST 2006 

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