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

Tue Nov 7 04:03:45 EST 2006

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: manik at jboss.org
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