7:41 p.m.
Btw, I have committed it to Branch_JBossCache_1_4_0.
Do we want this in HEAD as well? I guess so, but just double checking here.
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: Galder Zamarreno
Sent: 29 November 2006 19:40
To: 'Manik Surtani'
Cc: jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] easing the path for clientstogetaroundredeployment class
loading issues in JBC
Ok, sounds good.
I have committed the UT (o.j.c.m.RedeploymentEmulationTest) and the QA entry.
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@jboss.org]
Sent: 28 November 2006 23:31
To: Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] easing the path for clientstogetaroundredeployment class
loading issues in JBC
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(a)lists.jboss.org [mailto:jbosscache-dev-
bounces(a)lists.jboss.org] On Behalf Of Galder Zamarreno
Sent: 27 November 2006 12:55
To: Manik Surtani
Cc: jbosscache-dev(a)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@jboss.org]
Sent: 24 November 2006 19:09
To: Galder Zamarreno
Cc: jbosscache-dev(a)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(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)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(a)lists.jboss.org [mailto:jbosscache-dev-
> bounces(a)lists.jboss.org] On Behalf Of Galder Zamarreno
> Sent: 24 November 2006 17:11
> To: Manik Surtani
> Cc: jbosscache-dev(a)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@redhat.com]
> Sent: 17 November 2006 14:21
> To: Galder Zamarreno
> Cc: Brian Stansberry; jbosscache-dev(a)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(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)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@redhat.com]
>> Sent: 07 November 2006 10:01
>> To: Galder Zamarreno
>> Cc: Brian Stansberry; jbosscache-dev(a)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(a)redhat.com
>> Telephone: +44 7786 702 706
>> MSN: manik(a)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(a)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(a)lists.jboss.org
>>>> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
>>>> Galder Zamarreno
>>>> Sent: 02 November 2006 16:31
>>>> To: Brian Stansberry; jbosscache-dev(a)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(a)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(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
>>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
3:14 a.m.
New subject: easing the path for clientstogetaroundredeployment class loading issues in JBC
Yes pls
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 29 Nov 2006, at 18:41, Galder Zamarreno wrote:
Btw, I have committed it to Branch_JBossCache_1_4_0.
Do we want this in HEAD as well? I guess so, but just double
checking here.
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: Galder Zamarreno
Sent: 29 November 2006 19:40
To: 'Manik Surtani'
Cc: jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] easing the path for
clientstogetaroundredeployment class loading issues in JBC
Ok, sounds good.
I have committed the UT (o.j.c.m.RedeploymentEmulationTest) and the
QA entry.
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@jboss.org]
Sent: 28 November 2006 23:31
To: Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] easing the path for
clientstogetaroundredeployment class loading issues in JBC
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(a)lists.jboss.org [mailto:jbosscache-dev-
> bounces(a)lists.jboss.org] On Behalf Of Galder Zamarreno
> Sent: 27 November 2006 12:55
> To: Manik Surtani
> Cc: jbosscache-dev(a)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@jboss.org]
> Sent: 24 November 2006 19:09
> To: Galder Zamarreno
> Cc: jbosscache-dev(a)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(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)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(a)lists.jboss.org [mailto:jbosscache-dev-
>> bounces(a)lists.jboss.org] On Behalf Of Galder Zamarreno
>> Sent: 24 November 2006 17:11
>> To: Manik Surtani
>> Cc: jbosscache-dev(a)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@redhat.com]
>> Sent: 17 November 2006 14:21
>> To: Galder Zamarreno
>> Cc: Brian Stansberry; jbosscache-dev(a)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(a)jboss.org
>> Telephone: +44 7786 702 706
>> MSN: manik(a)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@redhat.com]
>>> Sent: 07 November 2006 10:01
>>> To: Galder Zamarreno
>>> Cc: Brian Stansberry; jbosscache-dev(a)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(a)redhat.com
>>> Telephone: +44 7786 702 706
>>> MSN: manik(a)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(a)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(a)lists.jboss.org
>>>>> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
>>>>> Galder Zamarreno
>>>>> Sent: 02 November 2006 16:31
>>>>> To: Brian Stansberry; jbosscache-dev(a)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(a)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(a)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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
>
6350
days inactive
6351
days old
jbosscache-dev@lists.jboss.org
1 comments
2 participants
participants (2)
-
Galder Zamarreno -
Manik Surtani