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

Fri Nov 17 09:42:03 EST 2006

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
>
>