RE: [jbosscache-dev] Perf tuning for JBoss Cache
by Galder Zamarreno
Yeah, I was looking at using the VAM from TreeCache as well :-)
There's only one downside to using VAM in the JDBCCacheLoader. Any data previously stored in the JDBCCacheLoader would not be compatible from this version onwards, or I guess they'd have to revert back to the old way.
Afaik, we can switch jboss serialization on/off, but not VAM (which is used from JBossCache 2.0), can we? I guess we're moving up to 2.0 so this leap might be acceptable.
Ok, so if we have customers that want to switch to 2.0 but they have loads of data already in the database, how could we ease the transformation of any data that they might have in the database?
Any ideas?
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: 27 November 2006 17:55
To: Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] Perf tuning for JBoss Cache
On 27 Nov 2006, at 09:47, Galder Zamarreno wrote:
> I have updated it with a couple of JIRA.
>
> Are you guys happy with those? We had already talked about the
> connection pooling stuff. Check the other one regarding
> serialization in the JDBCCacheLoader.
Yes,, you have a +1 from me already. Regarding the marshallers,
could we use an instance of the VersionAwareMarshaller created in
TreeCache? Just pass this instance to the JDBCCacheLoader (and any
other cloaders that need to serialize objects, such as
TcpRemoteCacheLoader) and use the VAM's object{To|From}ByteBuffer()
methods. This way cloaders will be version-aware too, in the same
way replication code is, and we'll have some degree of interop.
(Sweet!)
I'm adding a getMarshaller() method to CacheSPI for this purpose to
cloaders have access 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: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-
> bounces(a)lists.jboss.org] On Behalf Of Manik Surtani
> Sent: 21 November 2006 17:24
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] Perf tuning for JBoss Cache
>
> Guys,
>
> Every time we see or suspect potential inefficiencies in the JBoss
> Cache codebase (stuff we spot while working on other features or
> debugging stuff) we should note these down so they can be revisited
> later.
>
> At some point I do want to do a full performance analysis as well,
> but for the time being this could be useful to capture stuff we see
> as we go along.
>
> http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCachePerfAnalysis
>
> Cheers,
> --
> 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
>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 4 months
Re: Fundamental problem with pessimistic locking
by Bela Ban
Manik Surtani wrote:
> Ok, this seems to work, making things a lot more 'correct'. But
> before I roll this into an official release and start making changes
> en-masse, porting this to 1.4.x and 2.0.0, I'd like to step back and
> think about whether this is what we really want. Here is what I've
> effectively done with 1.3.0.SP4, all related to pessimistic locking only:
>
> a) Added a mechanism for not removing nodes when remove() is called,
> and instead storing them in a map which can be referenced by
> concurrent threads and locks attempted. (Mutated version of Brian's
> original fix to JBCACHE-871)
> b) When locking nodes in PLI.lock(), added a mechanism to obtain a WL
> on a node if the next node after it needs to be created or removed.
> (JBCACHE-875)
> c) Modified PLI.lock() to start with Fqn.ROOT rather than Fqn.get(0),
> which applies the same cache-wide locking behaviour to the root as
> well. Prior to this, the root never was locked for anything.
>
> The implications of these, for the sake of accuracy and correctness,
> are possibly:
>
> 1) Performance impact on inspecting nodes in b) to decide on whether
> WLs are needed
> 2) Memory impact on maintaining a map of removed nodes in a)
- Can't we simply mark a node as REMOVED (special attribute in that
node's hashmap), so we don't need an additional list ?
- What happens if you remove an entire subtree (2000 nodes) in a TX ? Is
the current list a list of Fqns, or a copy of the nodes ?
> 3) Reduced concurrency due to overall stronger locks in b)
> 4) Much reduced concurrency because of the locking in c)
Can we resume the discussion initiated by Brian Dueck some time ago, to
provide the concept of 'multiple roots' ? We could create N buckets, and
the hashcode of the first elements of an FQN selects the bucket
(subtree) into which the FQN will go. The N buckets are NEVER removed,
but they are not visible to the user. Therefore, if we have to lock the
root, we never actually lock "/", but e.g. bucket #24.
> 5) Potential of more deadlocks/timeouts because of 3) and 4) above.
>
> Of the above, 5) manifests itself in a few unit tests that have now
> started to fail (TxCacheLoaderTest, some state transfer tests, etc.).
> Simple example, taken from one of the failing tests, leads to a deadlock:
>
> 1: mgr.begin();
> 2: Transaction tx=mgr.getTransaction();
> 3: cache1.put("/one/two/three", "key1", "val1");
> 4: assertNull(cache2.get("/one/two/three", "key1"));
> 5: tx.commit();
>
> Line 3 obtains a WL on "/" on cache1, for GTX 1
> Line 4 obtains a WL on "/" on cache2, for GTX 2
> Line 5, on replication, tries to get a WL on "/" on cache2, for GTX 1
>
> Both GTXs relate to the same TX since they are in the same thread.
> Boom, deadlock.
>
> One thing here though, in my opinion, another bug in the original PLI:
>
> When doing a get on a node that doesn't exist, intermediate nodes are
> created. E.g., cache2.get("/one/two/three", "key1") actually ends up
> creating /one/two/three first, and after the JBCACHE-875 fix, /, /one
> and /one/two will be WL'd for a get() on a nonexistent node!!
> Shouldn't the loop just be short-circuited such that at any point, if
> the next node does not exist and the lock_type requested is READ, just
> return a null? Saves us a whole bunch of unnecessary WL's ...
Absolutely, this is a bug ! We should never create nodes for GET or
REMOVE !!
--
Bela Ban
Lead JGroups / JBoss Clustering team
JBoss - a division of Red Hat
17 years, 4 months
RE: [jbosscache-dev] JBCACHE-867
by Galder Zamarreno
Hehehe, no probs! You've got a point there :)
Now, stop hijacking my threads!! ;)
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: Brian Stansberry
Sent: 27 November 2006 18:03
To: Galder Zamarreno; Manik Surtani; genman(a)noderunner.net
Cc: jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] JBCACHE-867
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> .... this is a method that could well live in Node as it does
> right now, leaving space for other things in the Cache interface.
(Galder, my apologies in advance for deliberately misinterpreting your post; the above phrasing gave me a chance to say something that's been bugging me for a while...)
I hope we can not have any concept of "available space" in the API. The API should expose what it needs to expose for users to have the intended functionality as cleanly as possible. If that means an interface has 100 methods, so be it. A really large interface may be a sign that refactoring needs to be done or the intended functionality is too broad or whatever, but if in the end the methods are required to do the job, then they should go in and should be located where they make the most sense.
The problem with the old TreeCache API wasn't so much the number of methods as it was the fact that 1) there was no public Interface separate from the internal-use-only public methods and 2) cache configuration wasn't cleanly separated from cache operation.
OK, that's off my chest; climbing down from soapbox now... ;)
17 years, 4 months
RE: [jbosscache-dev] JBCACHE-867
by Galder Zamarreno
Back to the original discussion after Brian's comment.
I guess from a users point of view, move(Fqn nodeToMove, Fqn newLocation) might be easier to understand and simpler to use. I have to agree that move in Node felt a bit strange at the beginning, but it did make sense soon after. Right now, any of the two seem valid to me.
So, +-1 from me :)
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: 27 November 2006 17:44
To: Galder Zamarreno
Cc: genman(a)noderunner.net; jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] JBCACHE-867
On 27 Nov 2006, at 09:46, Galder Zamarreno wrote:
>>> 5. Cache needs move(), not Node. The reason is clear if you see
>>> NodeImpl.
>>>
>
>> Yes, this is one I have been toying with. What do others think?
>
> Using move() does seem natural, you're in a node and want to move
> it and his children to other fqn.
>
> The only downside I can see is people using it from the Cache
> interface and not realising that this is Node method which might
> leave them wondering which node you are moving...etc.
>
> I guess a move(Node1, Node2, newFqn) might be easier to read, but
> this is a method that could well live in Node as it does right now,
> leaving space for other things in the Cache interface.
Well, it would just be
move(Fqn nodeToMove, Fqn newLocation)
>
> 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 Manik Surtani
> Sent: 20 November 2006 16:43
> To: genman(a)noderunner.net
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] JBCACHE-867
>
> On 20 Nov 2006, at 04:25, Elias Ross wrote:
>
>>
>>
>> I finished most of getting rid of the TreeCacheProxyImpl
>> references. It took
>> more time than anticipated.
>>
>> All said, it was about 1800 lines of adds and 2000 lines of removes.
>> TreeNode and DataNode are pretty empty. There's now a NodeSPI
>> which might
>> need some work, but it's pretty pleasant. I also refactored out a
>> lot of
>> lock stuff into something that hangs off of NodeSPI.
>>
>> Some tests may have been messed up (buddy replication and the move
>> feature
>> and probably some others) and I haven't had time to figure these
>> complicated
>> ones out. I hope this doesn't upset anybody. If somebody could
>> help fix
>> these, that would be great.
>
> No this is fine, this was on the cards for me but you've saved me a
> bit of work here. :-) Now just to make sure none of the
> functionality's broken.
>
>>
>> I would like to suggest the following things:
>> 1. Cache should not implement Node, it's confusing when reading an
>> implementation of Cache
>
> We toyed with this quite a bit and in the end we decided to go ahead
> with it since it lets people use the Cache directly rather than to
> get a hold of a Node first. In what ways do you feel this is
> confusing?
>
>> 2. Node sould include useful methods of TreeNode, such as getChild
>> (Object)
>> and getName()
>
> There is getChild(Fqn) - and I want to standardise on this. The Fqn
> passed in is relative to the Node in question so you can have access
> to direct children.
>
> Similarly with getName(), I prefer getFqn().getLast() simply because
> it cements the use of Fqns when it comes to identifying Nodes, and I
> don't think adding a boatload of convenience methods helps the
> interface very much.
>
>
>> 3. Cache should have a getCacheSPI()
>
> Again, -1. I had this in place initially (again as a temp measure)
> and refactored this out. The purpose of the SPI is to give users
> access to an 'advanced' API which would only be of value to people
> implementing Cache Loaders, Cache Listeners or custom Interceptors.
> Not for typical use of the cache. And as such, this interface should
> only be injected into such Cache Loaders, Listeners and Interceptors.
>
>> 4. CacheSPI should not extend Cache
>
> In the case of Cache Loaders, Listeners and Interceptors, they would
> need access to both interfaces. Don't want to pass in a Cache *and*
> a CacheSPI, and don't want Cache.getCacheSPI() for the reasons
> outlined above. :-)
>
>> 5. Cache needs move(), not Node. The reason is clear if you see
>> NodeImpl.
>>
>
> Yes, this is one I have been toying with. What do others think?
>
>
>> In the current design, CacheSPI has to have all the methods of
>> Cache. Why
>> couldn't CacheSPI be written as a separate object? (It could, but
>> then you
>> would just have to delegate ...)
>>
>>
>>
>> _____________________________________________________________________
>> _
>> ______________
>> Sponsored Link
>>
>> Mortgage rates near 39yr lows.
>> $510k for $1,698/mo. Calculate new payment!
>> www.LowerMyBills.com/lre
>> _______________________________________________
>> 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
17 years, 4 months
RE: [jbosscache-dev] JBCACHE-867
by Brian Stansberry
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> .... this is a method that could well live in Node as it does
> right now, leaving space for other things in the Cache interface.
(Galder, my apologies in advance for deliberately misinterpreting your
post; the above phrasing gave me a chance to say something that's been
bugging me for a while...)
I hope we can not have any concept of "available space" in the API. The
API should expose what it needs to expose for users to have the intended
functionality as cleanly as possible. If that means an interface has
100 methods, so be it. A really large interface may be a sign that
refactoring needs to be done or the intended functionality is too broad
or whatever, but if in the end the methods are required to do the job,
then they should go in and should be located where they make the most
sense.
The problem with the old TreeCache API wasn't so much the number of
methods as it was the fact that 1) there was no public Interface
separate from the internal-use-only public methods and 2) cache
configuration wasn't cleanly separated from cache operation.
OK, that's off my chest; climbing down from soapbox now... ;)
17 years, 4 months
RE: [jbosscache-dev] Perf tuning for JBoss Cache
by Galder Zamarreno
I have updated it with a couple of JIRA.
Are you guys happy with those? We had already talked about the connection pooling stuff. Check the other one regarding serialization in the JDBCCacheLoader.
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@lists.jboss.org] On Behalf Of Manik Surtani
Sent: 21 November 2006 17:24
To: jbosscache-dev(a)lists.jboss.org
Subject: [jbosscache-dev] Perf tuning for JBoss Cache
Guys,
Every time we see or suspect potential inefficiencies in the JBoss
Cache codebase (stuff we spot while working on other features or
debugging stuff) we should note these down so they can be revisited
later.
At some point I do want to do a full performance analysis as well,
but for the time being this could be useful to capture stuff we see
as we go along.
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCachePerfAnalysis
Cheers,
--
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
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
17 years, 4 months
RE: [jbosscache-dev] FW: [jboss-dev-forums] [Design of the JBoss EJBContainer] - Problemwith order of entity cache operations withHibernate
by Galder Zamarreno
+10 on JBC/Hibernate integration testing too, but whose responsibility would be to deal with them and make sure that they work? Hibernate or JBC developer's? Rather than splitting responsibility, I think it'd be easier to have someone in charge of it who would lease with the rest of Hibernate and JBC developers, but this is different topic already... :-)
I sent an email a month ago about the possibility of creating a Hibernate/JBC compatibility matrix but not a single person replied. These tests would give us the information we need for this.
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@lists.jboss.org] On Behalf Of Brian Stansberry
Sent: 17 November 2006 16:44
To: Manik Surtani
Cc: jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] FW: [jboss-dev-forums] [Design of the JBoss EJBContainer] - Problemwith order of entity cache operations withHibernate
+10 on JBC/Hibernate integration testing.
The EJB3 testsuite has one test in this area, which luckily uncovered
the issue. Only uses the TM that's integrated in the AS; it was a lucky
hit.
There should be more EJB3 tests as well, but the primary place for it
should be in Hibernate/JBC. E.g. this issue quite likely impacts
non-EJB3 Hibernate as well.
That's how we find such a thing. Anyone have any good thoughts on what
to do about it? Perhaps Hibernate exposes something like JBC's
OrderedSynchronizationHandler, which the JBC integration can use to
insert it's synchronization at the correct point?
Manik Surtani wrote:
> Hmm, the *correct* approach to dealing with this would be to
> put together a series of integration tests for JBoss Cache
> and Hibernate, exercising such scenarios with different TMs,
> and making sure these are run with every release of Hibernate
> and JBC. Either that, or we assume the EJB3 test suite
> covers this, and I presume this is how you uncovered this issue?
>
>
>> FYI; just posted on the EJB3 forum.
>>
>> bstansberry(a)jboss.com wrote:
>>> There appears to be a difference in behavior between JBossTM and
>>> JBossTS that's leading to failures with JBoss Cache as the 2nd
>>> level entity cache.
>>>
>>> JBC handles replication of transaction-scoped cache changes by
>>> registering as a transaction Synchronization and replicating the
>>> changes during the beforeCompletion() callback. This is failing
>>> with JBossTS because the beforeCompletion() callback is being
>>> executed *before* the Hibernate flush activity that updates the
>>> cache. No activity at time of beforeCompletion() == no
>>> replication of the tx's changes.
>>>
>>> 2006-11-16 23:48:41,250 TRACE
>>> [org.jboss.cache.interceptors.TxInterceptor] Running
>>> beforeCompletion on gtx GlobalTransaction:<192.168.1.164:2668>:1
>>> 2006-11-16 23:48:41,250 TRACE
>>> [org.jboss.cache.interceptors.TxInterceptor] Setting up
>>> transactional context. 2006-11-16 23:48:41,250 TRACE
>>> [org.jboss.cache.interceptors.TxInterceptor] Setting tx as
>>> TransactionImple < ac, BasicAction:
> -3f57ff9b:a5b:455d4cd6:10 status:
>>> 0 > and gtx as GlobalTransaction:<192.168.1.164:2668>:1 2006-11-16
>>> 23:48:41,250 TRACE [org.jboss.cache.interceptors.TxInterceptor] No
>>> modifications in this tx. Skipping beforeCompletion() 2006-11-16
>>> 23:48:41,250 DEBUG
>>> [org.hibernate.event.def.AbstractFlushingEventListener] processing
>>> flush-time cascades 2006-11-16 23:48:41,250 DEBUG
>>> [org.hibernate.event.def.AbstractFlushingEventListener] dirty
>>> checking collections 2006-11-16 23:48:41,265 DEBUG
>>> [org.hibernate.engine.Collections] Collection found:
>>> [org.jboss.ejb3.test.clusteredentity.Customer.contacts#1], was: []
>>> (initialized) 2006-11-16 23:48:41,265 DEBUG
>>> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 3
>>> insertions, 0 updates, 0 deletions to 3 objects 2006-11-16
>>> 23:48:41,265 DEBUG
>>> [org.hibernate.event.def.AbstractFlushingEventListener] Flushed: 1
>>> (re)creations, 0 updates, 0 removals to 1 collections ...
>>> followed by puts into the cache
>>>
>>> When I switched the AS back to using JBossTM, the problem went away
>>> -- the Hibernate flush activity occurred first, and then the
>>> beforeCompletion() call to JBC.
>>>
>>> I'm speculating that Hibernate is also using a Synchronization to
>>> manage the flush, and that JBossTA and JBossTS make the calls to
>>> registered Synchronizations in a different order.
>>>
>>> At this point, replication of clustered EJB3 entities is basically
>>> broken.
>>>
>>> View the original post :
>>>
>> http://www.jboss.com/index.html?
>> module=bb&op=viewtopic&p=3986745#3986745
>>>
>>> Reply to the post :
>>>
>> http://www.jboss.com/index.html?
>> module=bb&op=posting&mode=reply&p=398674
>> 5
>>> _______________________________________________
>>> jboss-dev-forums mailing list
>>> jboss-dev-forums(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-dev-forums
>>
>> _______________________________________________
>> 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
17 years, 4 months
RE: [jbosscache-dev] easing the path for clients togetaroundredeployment class loading issues in JBC
by Galder Zamarreno
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
17 years, 4 months
RE: [jbosscache-dev] easing the path for clients togetaroundredeployment class loading issues in JBC
by Galder Zamarreno
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@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
17 years, 5 months
RE: [jbosscache-dev] easing the path for clients to getaroundredeployment class loading issues in JBC
by Galder Zamarreno
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
>
>
17 years, 5 months