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

Fri Nov 24 11:54:17 EST 2006

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