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