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

+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