Re: [jbosscache-dev] easing the path for clientstogetaroundredeployment class loading issues in JBC

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; &#39;jbosscache-dev(a)lists.jboss.org&#39; >>>> 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 > >