Region.markNodeCurrentlyInUse
by Brian Stansberry
The purpose of this method is to allow an application to signal the
eviction policy to not evict a particular node who's data it's using.
Needed in situations where the app doesn't hold a lock on the node *and*
where evicting the node will cause a problem.
AFAICT, this use case is really just for EJB3 SFSBs, where the problem
is that evicting an "in-use" node forces the container to call
prePassivate() on the in-use EJB. This is done from a CacheListener.
This is all a bit funky. Adding methods to the API to deal with a very
specific use case. It also has a small race condition, which I won't
get into here.
Here's a different (but still funky) approach:
Add a new exception class o.j.c.eviction.NodeInUseException extends
RuntimeException.
The application implements CacheListener. When it gets a
nodePassivated(pre=true) event, if it doesn't want the passivation, it
throws the NodeInUseException. This will abort the eviction and
propagate back to the eviction policy. Eviction policies are already
written such that they catch all exceptions, and then throw the node
into a retry queue (see BaseEvictionAlgorithm.evictCacheNode()). If we
wanted to get fancy, we could specifically catch NodeInUseException and
decide from there whether to add it to the retry queue.
I don't think we should try to change this this week; more of a short
term future thing.
Thoughts?
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
IT executives: Red Hat still #1 for value
http://www.redhat.com/promo/vendor/
18 years
- 2
- 1
RE: [jbosscache-dev] Anycast: JBCACHE-813 & JGRP-338
by Brian Stansberry
Re: making multiple unicast calls from the JBC layer, doesn't this
likely increase the overall time to do the group RPC by putting each
call/response in series? You lose JGroups' ability to correlate the
responses.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Yes, you could call
> getChannel().getProtocolStack().findProtocol("UDP")
> to do this.
>
> I discussed this yesterday, and the impl of anycast is really
> quite simple. I'll do this next week.
>
> Manik Surtani wrote:
>>
>>
>> On 27 Nov 2006, at 22:01, Bela Ban wrote:
>>
>>>
>>>
>>> Manik Surtani wrote:
>>>> Bela/Vladimir:
>>>>
>>>> Regarding broadcasting calls to a subset of members in a cluster,
>>>> if I were to callRemoteMethods() to N members ( where N > 1 and N
>>>> < all members) how does this behave, especially when using TCP or
>>>> TCP_NIO? I know that with UDP, a multicast is made and the members
>>>> not on the target list ignore the messages. Is this the same with
>>>> TCP/TCP_NIO
>>>
>>> yes
>>>
>>>> i.e., is the message broadcast to all members again and the members
>>>> not on the target list ignore the messages? (Hugely wasteful, and
>>>> hence the need for anycast).
>>>
>>> Right (http://jira.jboss.com/jira/browse/JGRP-338)
>>>
>>>> In JBoss Cache 1.4.1, I've implemented JBCACHE-813 so a unicast is
>>>> used if the recipient list is 1 - a bit of a hack to work around
>>>> this inefficiency. But this in itself is not foolproof since, say
>>>> using Buddy Replication in a cluster of 30 servers and using 3
>>>> buddies per node, we still end up unicasting the message to all 30
>>>> nodes only for 27 of them to ignore it.
>>>
>>> Correct. I think anycast will be relatively simple to implement. In
>>> the meantime, you could simply send 3 unicasts yourself, e.g. for
>>> sending the message to A, B and C:
>>> callRemoteMethod(A, "foo", new Object[]{"bla", new Integer(2662)},
>>> new Class[]{String.class, Integer.class}, ...); callRemoteMethod(B,
>>> "foo", new Object[]{"bla", new Integer(2662)}, new
>>> Class[]{String.class, Integer.class}, ...); callRemoteMethod(C,
>>> "foo", new Object[]{"bla", new Integer(2662)}, new
>>> Class[]{String.class, Integer.class}, ...);
>>>
>>> This should do the job.
>>>
>>>> We could hack in a config param - a unicast threshold (UT) - where
>>>> if N <= UT and N <= all members, we use a series of forced
>>>> unicasts? The drawback is that this only makes sense with
>>>> TCP/TCP_NIO. Using this with UDP will probably result in worse
>>>> performance since a single broadcast would be better.
>>>
>>> Yes, the idea is to let the transport handle optimal message
>>> distribution, e.g. as described in the above JIRA issue. This will
>>> be available in 2.5.
>>>
>>
>> Another option (equally hacky, but again temporary until JG 2.5) is
>> for TreeCache (or RpcManager in 2.0.0) to test whether UDP is a
>> registered protocol in the channel (Iterate through the Vector
>> returned by channel.getProtocolStack().getProtocols() and look for an
>> instance of o.j.p.UDP). If UDP is registered, then ALWAYS use
>> callRemoteMethods() otherwise ALWAYS use separate callRemoteMethod()
>> invocations.
>>
>> Which would be cleaner/more efficient? I'd go for option 2, provided
>> there is no efficiency lost when broadcasting to the entire cluster
>> using a series of callRemoteMethod() invocations over a single
>> callRemoteMethods() invocation when using TCP.
18 years
- 3
- 5
Re: intellij 5 linux
by Manik Surtani
Well, let's chat about this on the forums or on jbosscache-
dev(a)lists.jboss.org
IDEA 6 is much, much better than 5. A worthwhile upgrade.
--
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 30 Nov 2006, at 15:50, Heiko Braun wrote:
> actually we are just discussing integration of jbossCache with
> jbossws for certain features. maybe this brings up some issues ...
>
> thanks
>
> Manik Surtani schrieb:
>> Here you go - call this a bribe so you will contrib some code to
>> JBoss Cache in the future. :-)
>> User Name: JBossCache
>> License key 1: 25392-WSW2M-95ZOH-DWPNS-ZC4RR-IXQU6
>> --
>> 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 30 Nov 2006, at 15:42, Heiko Braun wrote:
>>> hehe, i will think about it ;)
>>>
>>> /Heiko
>>>
>>> Manik Surtani schrieb:
>>>> Well, if you contributed some code to JBoss Cache I could give
>>>> you a copy of the JBoss Cache license... ;)
>>>> --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 30 Nov 2006, at 15:34, Heiko Braun wrote:
>>>>> unfortunately mine doesn't.
>>>>>
>>>>> /Heiko
>>>>>
>>>>> Manik Surtani schrieb:
>>>>>> Don't licenses for IDEA 5 work on IDEA 6 as well? Mine did,
>>>>>> both on Linux and OS X. Not sure if it was something specific
>>>>>> about my license though (a free license donated by Jetbrains
>>>>>> for JBoss Cache)
>>>>>> --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 30 Nov 2006, at 14:25, Heiko Braun wrote:
>>>>>>> I own a license for it.
>>>>>>> But I just realized that it's still available from JetBrains.
>>>>>>>
>>>>>>> Tnx
>>>>>>>
>>>>>>>
>>>>>>> Manik Surtani schrieb:
>>>>>>>> Not 5. Why would you want 5 anyhows?
>>>>>>>> --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 30 Nov 2006, at 14:10, Heiko Braun wrote:
>>>>>>>>>
>>>>>>>>> does some still have an intellij 5 linux installer available?
>>>>>>>>>
>>>>>>>>> /Heiko
>>>>>>>
>>>>>>> ----
>>>>>>> Heiko Braun
>>>>>>> JBoss, a division of Red Hat
>>>>>>> T: +49 89 52350383
>>>>>>> M: +49 178 1496854
>>>>>
>>>>> ----
>>>>> Heiko Braun
>>>>> JBoss, a division of Red Hat
>>>>> T: +49 89 52350383
>>>>> M: +49 178 1496854
>>>
>>> ----
>>> Heiko Braun
>>> JBoss, a division of Red Hat
>>> T: +49 89 52350383
>>> M: +49 178 1496854
>
> --
> --
> Heiko Braun
> JBoss, a division of Red Hat
> T: +49 89 52350383
> M: +49 178 1496854
18 years
- 2
- 2
Re: Fundamental problem with pessimistic locking
by Manik Surtani
So we still haven't discussed my biggest concern here, which is item
5) below in the list of implications. Is this performance penalty
and potential for deadlocks small enough a price to pay for the
correctness of concurrent access on the root node? What do people
think?
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Monday, November 27, 2006 7:19 PM
> To: Manik Surtani
> Cc: Bela Ban; Ben Wang; Brian Stansberry; Vladimir Blagojevic;
> Galder Zamarreno
> Subject: Re: Fundamental problem with pessimistic locking
>
> 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)
> 3) Reduced concurrency due to overall stronger locks in b)
> 4) Much reduced concurrency because of the locking in c)
> 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 ...
>
> Sorry about the long and rambling email. Thoughts and opinions?
> --
> 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 27 Nov 2006, at 10:16, Manik Surtani wrote:
>
>> Ok, take away the crap about it being a bug in the util.concurrent
>> code. It's a bug in JBC, specifically on line 75 in TreeCache.java:
>>
>> protected DataNode root = NodeFactory.getInstance().createDataNode
>> (NodeFactory.NODE_TYPE_TREENODE, SEPARATOR, Fqn.fromString
>> (SEPARATOR), null, null, this);
>>
>> :-) The root node is initialised when new TreeCache() is called,
>> well before isolation levels, etc. are set, which causes the root
>> node to be created with isolation level of NONE. Hence the insane
>> behaviour when trying to content for write locks on the root node.
>>
>> Just fixed this, running a bunch of regressions now.
>>
>> 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
>>
>>
>>
>> On 26 Nov 2006, at 19:04, Bela Ban wrote:
>>
>>> Forwarding to the entire group
>>>
>>> Manik Surtani wrote:
>>>> Ok, boiled it down to a contention issue on locking Fqn.ROOT,
>>>> which prior to JBCACHE-875, was never locked - either for
>>>> reading or writing. (I do this by changing the loop in the lock
>>>> () method in PLI to first consider the root before the
>>>> individual Fqn elements). (This problem is also apparent in
>>>> o.j.c.transaction.DeadlockTest on a multi-cpu box).
>>>>
>>>> 2006-11-26 14:58:09,566 DEBUG [Node] (Thread-2) acquiring WL:
>>>> fqn=/, caller=GlobalTransaction:<null>:2, lock=<unlocked>
>>>> <snip>
>>>> 2006-11-26 14:58:09,572 DEBUG [Node] (Thread-3) acquiring WL:
>>>> fqn=/, caller=GlobalTransaction:<null>:3, lock=<unlocked>
>>>> <snip>
>>>> 2006-11-26 14:58:09,576 DEBUG [Node] (Thread-2) acquired WL:
>>>> fqn=/, caller=GlobalTransaction:<null>:2, lock=write
>>>> owner=GlobalTransaction:<null>:2
>>>> <snip>
>>>> 2006-11-26 14:58:09,581 INFO [TxInterceptor] (Thread-3) There
>>>> was a problem handling this request
>>>> java.lang.IllegalStateException: there is already a writer
>>>> holding the lock: GlobalTransaction:<null>:2 and caller is
>>>> GlobalTransaction:<null>:3
>>>> at org.jboss.cache.lock.LockMap.setWriterIfNotNull(LockMap.java:
>>>> 101)
>>>> at org.jboss.cache.lock.IdentityLock.acquireWriteLock
>>>> (IdentityLock.java:187)
>>>> at org.jboss.cache.Node.acquireWriteLock(Node.java:557)
>>>> at org.jboss.cache.Node.acquire(Node.java:517)
>>>> < snip - lots>
>>>> 2006-11-26 14:58:09,850 DEBUG [Node] (Thread-2) created child:
>>>> fqn=/, child_name=NODE
>>>>
>>>> I can't understand why concurrent WL acquisition in
>>>> IdentityLock.acquireWriteLock() behaves correctly for all nodes
>>>> except the root node. As you can see in the log snippet above,
>>>> both Thread-2 and Thread-3 call IdentityLock.acquireWriteLock
>>>> (line 178) and get a 'true', and one of the threads cause an
>>>> exception on line 187.
>>>>
>>>>
>>>> --
>>>> 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 26 Nov 2006, at 13:54, Manik Surtani wrote:
>>>>
>>>>> I didn't want to acquire the WL immediately since it involved
>>>>> an additional test to check if the next node in the fqn needed
>>>>> creation. But I went with that algorithm in the end since the
>>>>> locks had problems with concurrent readers attempting to
>>>>> upgrade to writers.
>>>>>
>>>>> So most of the regressions pass, as well as the new tests
>>>>> introduced, and I am very close to something working, EXCEPT
>>>>> one very strange problem with the IdentityLock and
>>>>> ConcurrentCreationDeadlockTest.testLocalCacheLoader2Modifications(
>>>>> ) - get the latest on the 1.3.0 branch for this to make any
>>>>> sense. The problem is between lines 178 and 187 of
>>>>> IdentityLock, in the acquireWriteLock() method.
>>>>>
>>>>> Attempting to get a hold of a write lock returns true, but
>>>>> setting the writer throws an exception since another writer
>>>>> exists. Odd that this happens since the calling thread should
>>>>> have the semaphore by then, also odd that this only seems to
>>>>> happen in this one test which is meant to test concurrency in
>>>>> the CacheLoaderInterceptor.
>>>>>
>>>>> I'm still investigating, but if you have any ideas about how
>>>>> and why this may happen, I'd love to hear it ... :-)
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> On 24 Nov 2006, at 15:25, Bela Ban wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Manik Surtani wrote:
>>>>>>>
>>>>>>> On 24 Nov 2006, at 14:44, Bela Ban wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> The first one you mentioned can lead to race conditions,
>>>>>>> depending on the order of whether the upgrade on b or the
>>>>>>> creation/WL on c happens first. What I've implemented is
>>>>>>> more like:
>>>>>>>
>>>>>>> 1: Acquire RL on a
>>>>>>> 2: Acquire RL on b
>>>>>>> 3: Identify that we need to create c.
>>>>>>> 4: Upgrade RL on b to WL
>>>>>>> 5: *now* create c, and acquire WL on it.
>>>>>>>
>>>>>>> So there is a possibility that step 4 may block until other
>>>>>>> readers on b release their locks, but no one else could grab
>>>>>>> the WL since the current TX will have a RL.
>>>>>>
>>>>>> I see. Why don't you acquire a WL on b (step 2) *immediately*
>>>>>> rather than going through the upgrade if you know you have to
>>>>>> acquire a WL later anyway ? You might still deadlock:
>>>>>> 2: acquire RL on b
>>>>>> (in the meantime): some other TX acquires a RL on b, possibly
>>>>>> upgrades to WL
>>>>>> 3: you want to acquire a WL on b and block on the other TX's
>>>>>> RL or WL
>>>>>>
>>>>>> --
>>>>>> Bela Ban
>>>>>> Lead JGroups / JBoss Clustering team
>>>>>> JBoss - a division of Red Hat
>>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Bela Ban
>>> Lead JGroups / JBoss Clustering team
>>> JBoss - a division of Red Hat
>>
>
18 years
- 2
- 2
RE: [jbosscache-dev] easing the path for clientstogetaroundredeployment class loading issues in JBC
by Galder Zamarreno
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
>
>
18 years
- 2
- 1
RE: [jbosscache-dev] easing the path for clientstogetaroundredeployment class loading issues in JBC
by Galder Zamarreno
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
>
>
18 years
- 1
- 0
RE: [jbosscache-dev] Fwd: [JBossCache] - Jboss Cache not working inweblogic 9.2
by Brian Stansberry
Channel.getState() returning false indicates a problem either with the
communications or with the coordinator's preparation of the state.
Hmm...something I just thought of. We:
1) connect the channel
2) call Channel.getState()
3) if that returns false, block until we get a view so we can see if we
are coord. If not coord, throw an exception as getState() returning
false is an error condition.
There's a race between 2 and 3, i.e. getState() returns false but then a
merge happens and in 3 we find we are not the coord. Perhaps better is
to:
1) connect the channel.
2) block until we get a view
3) if we aren't coord, call channel.getState(), throw exception if
returns false
Don't particularly see how any of the above relates to WebLogic though.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> I've seen this a couple of times on the user forums lately -
> do we have a problem with state transfers on WebLogic?
>
>> From: Kavipriya <do-not-reply(a)jboss.com>
>> Date: 29 November 2006 10:18:03 GMT
>> To: manik.surtani(a)jboss.com
>> Subject: [JBossCache] - Jboss Cache not working in weblogic 9.2
>>
>> In the cluster environment. I have two servers. When i start the
>> first server i dont have any problems but when i start the second
>> server it is throwing the following exception in the back end.
>>
>> org.jboss.cache.CacheException: Initial state transfer failed:
>> Channel.getState( ) returned false
>> at org.jboss.cache.TreeCache.fetchStateOnStartup
>> (TreeCache.java:2749) at
> org.jboss.cache.TreeCache.startService(TreeCache.java:1330)
>> at
>>
> com.taxware.twe.common.storage.impl.MessagingServiceImpl.startService
>> (MessagingServiceImpl.java:117)
>> at com.taxware.twe.common.storage.StartupServlet.startInit
>> (StartupServle t.java:185)
>> at com.taxware.twe.common.storage.StartupServlet.init
>> (StartupServlet.jav a:113)
>> at
> javax.servlet.GenericServlet.init(GenericServlet.java:256)
>> at weblogic.servlet.internal.StubSecurityHelper
>> $ServletInitAction.run(St ubSecurityHelper.java:276)
>> at weblogic.security.acl.internal.AuthenticatedSubject.doAs
>> (Authenticate dSubject.java:321)
>> at weblogic.security.service.SecurityManager.runAs
>> (SecurityManager.java: 121)
>> at
>>
> weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecuri
>> tyHelper.java:68)
>> at
>>
> weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubL
>> ifecycleHelper.java:58)
>> at weblogic.servlet.internal.StubLifecycleHelper.
>> (StubLifecycleHel per.java:48)
>> at weblogic.servlet.internal.ServletStubImpl.prepareServlet
>> (ServletStubI mpl.java:504)
>> at
>>
> weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppS
>> ervletContext.java:1698)
>> at
>>
> weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(
>> WebAppServletContext.java:1675)
>> at
>>
> weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAp
>> pServletContext.java:1595)
>> at weblogic.servlet.internal.WebAppServletContext.start
>> (WebAppServletCon text.java:2734)
>> at weblogic.servlet.internal.WebAppModule.startContexts
>> (WebAppModule.jav a:892)
>> at weblogic.servlet.internal.WebAppModule.start
>> (WebAppModule.java:336) at
>> weblogic.application.internal.flow.ModuleStateDriver
>> $3.next(ModuleSta teDriver.java:204) at
>> weblogic.application.utils.StateMachineDriver.nextState
>> (StateMachineD river.java:26) at
>>
> weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStat
>> eDriver.java:60)
>> at
>>
> weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedMod
>> uleDriver.java:200)
>> at
>>
> weblogic.application.internal.flow.ModuleListenerInvoker.start(Module
>> ListenerInvoker.java:117)
>> at weblogic.application.internal.flow.ModuleStateDriver
>> $3.next(ModuleSta teDriver.java:204)
>> at weblogic.application.utils.StateMachineDriver.nextState
>> (StateMachineD river.java:26)
>> at
>>
> weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStat
>> eDriver.java:60)
>> at
>>
> weblogic.application.internal.flow.StartModulesFlow.activate(StartMod
>> ulesFlow.java:26)
>> at weblogic.application.internal.BaseDeployment$2.next
>> (BaseDeployment.ja va:641)
>> at weblogic.application.utils.StateMachineDriver.nextState
>> (StateMachineD river.java:26)
>> at weblogic.application.internal.BaseDeployment.activate
>> (BaseDeployment. java:229)
>> at
>>
> weblogic.application.internal.DeploymentStateChecker.activate(Deploym
>> entStateChecker.java:154)
>> at
>>
> weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(Ap
>> pContainerInvoker.java:80)
>> at
>>
> weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicD
>> eployment.java:181)
>> at
>>
> weblogic.deploy.internal.targetserver.BasicDeployment.activateFromSer
>> verLifecycle(BasicDeployment.java:352)
>> at weblogic.management.deploy.internal.DeploymentAdapter
>> $1.doActivate(De ploymentAdapter.java:52)
>> at
>>
> weblogic.management.deploy.internal.DeploymentAdapter.activate(Deploy
>> mentAdapter.java:186)
>> at weblogic.management.deploy.internal.AppTransition
>> $2.transitionApp(App Transition.java:30)
>> at
>>
> weblogic.management.deploy.internal.ConfiguredDeployments.transitionA
>> pps(ConfiguredDeployments.java:233)
>> at
>>
> weblogic.management.deploy.internal.ConfiguredDeployments.activate(Co
>> nfiguredDeployments.java:169)
>> at
>>
> weblogic.management.deploy.internal.ConfiguredDeployments.deploy(Conf
>> iguredDeployments.java:123)
>> at
>>
> weblogic.management.deploy.internal.DeploymentServerService.resume(De
>> ploymentServerService.java:173)
>> at
>>
> weblogic.management.deploy.internal.DeploymentServerService.start(Dep
>> loymentServerService.java:89)
>> at weblogic.t3.srvr.SubsystemRequest.run
>> (SubsystemRequest.java:64)
>> at
> weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
>> at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
>> com.taxware.twe.common.exception.TaxwareSystemException: General
>> Application Fai lure.Please contact System Administrator. at
>>
> com.taxware.twe.common.storage.impl.MessagingServiceImpl.startService
>> (MessagingServiceImpl.java:124)
>> at com.taxware.twe.common.storage.StartupServlet.startInit
>> (StartupServle t.java:185)
>> at com.taxware.twe.common.storage.StartupServlet.init
>> (StartupServlet.jav a:113)
>> at
> javax.servlet.GenericServlet.init(GenericServlet.java:256)
>> at weblogic.servlet.internal.StubSecurityHelper
>> $ServletInitAction.run(St ubSecurityHelper.java:276)
>> at weblogic.security.acl.internal.AuthenticatedSubject.doAs
>> (Authenticate dSubject.java:321)
>> at weblogic.security.service.SecurityManager.runAs
>> (SecurityManager.java: 121)
>> at
>>
> weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecuri
>> tyHelper.java:68)
>> at
>>
> weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubL
>> ifecycleHelper.java:58)
>> at weblogic.servlet.internal.StubLifecycleHelper.
>> (StubLifecycleHel per.java:48)
>> at weblogic.servlet.internal.ServletStubImpl.prepareServlet
>> (ServletStubI mpl.java:504)
>> at
>>
> weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppS
>> ervletContext.java:1698)
>> at
>>
> weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(
>> WebAppServletContext.java:1675)
>> at
>>
> weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAp
>> pServletContext.java:1595)
>> at weblogic.servlet.internal.WebAppServletContext.start
>> (WebAppServletCon text.java:2734)
>> at weblogic.servlet.internal.WebAppModule.startContexts
>> (WebAppModule.jav a:892)
>> at weblogic.servlet.internal.WebAppModule.start
>> (WebAppModule.java:336) at
>> weblogic.application.internal.flow.ModuleStateDriver
>> $3.next(ModuleSta teDriver.java:204) at
>> weblogic.application.utils.StateMachineDriver.nextState
>> (StateMachineD river.java:26) at
>>
> weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStat
>> eDriver.java:60)
>> at
>>
> weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedMod
>> uleDriver.java:200)
>> at
>>
> weblogic.application.internal.flow.ModuleListenerInvoker.start(Module
>> ListenerInvoker.java:117)
>> at weblogic.application.internal.flow.ModuleStateDriver
>> $3.next(ModuleSta teDriver.java:204)
>> at weblogic.application.utils.StateMachineDriver.nextState
>> (StateMachineD river.java:26)
>> at
>>
> weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStat
>> eDriver.java:60)
>> at
>>
> weblogic.application.internal.flow.StartModulesFlow.activate(StartMod
>> ulesFlow.java:26)
>> at weblogic.application.internal.BaseDeployment$2.next
>> (BaseDeployment.ja va:641)
>> at weblogic.application.utils.StateMachineDriver.nextState
>> (StateMachineD river.java:26)
>> at weblogic.application.internal.BaseDeployment.activate
>> (BaseDeployment. java:229)
>> at
>>
> weblogic.application.internal.DeploymentStateChecker.activate(Deploym
>> entStateChecker.java:154)
>> at
>>
> weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(Ap
>> pContainerInvoker.java:80)
>> at
>>
> weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicD
>> eployment.java:181)
>> at
>>
> weblogic.deploy.internal.targetserver.BasicDeployment.activateFromSer
>> verLifecycle(BasicDeployment.java:352)
>> at weblogic.management.deploy.internal.DeploymentAdapter
>> $1.doActivate(De ploymentAdapter.java:52)
>> at
>>
> weblogic.management.deploy.internal.DeploymentAdapter.activate(Deploy
>> mentAdapter.java:186)
>> at weblogic.management.deploy.internal.AppTransition
>> $2.transitionApp(App Transition.java:30)
>> at
>>
> weblogic.management.deploy.internal.ConfiguredDeployments.transitionA
>> pps(ConfiguredDeployments.java:233)
>> at
>>
> weblogic.management.deploy.internal.ConfiguredDeployments.activate(Co
>> nfiguredDeployments.java:169)
>> at
>>
> weblogic.management.deploy.internal.ConfiguredDeployments.deploy(Conf
>> iguredDeployments.java:123)
>> at
>>
> weblogic.management.deploy.internal.DeploymentServerService.resume(De
>> ploymentServerService.java:173)
>> at
>>
> weblogic.management.deploy.internal.DeploymentServerService.start(Dep
>> loymentServerService.java:89)
>> at weblogic.t3.srvr.SubsystemRequest.run
>> (SubsystemRequest.java:64)
>> at
> weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
>> at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
>> <Nov 29, 2006 5:16:41 AM EST> <BEA-000388> <JVM called
>> WLS shutdown hook. The server will force shutdown now>
>> <Nov 29, 2006 5:16:41 AM EST> <BEA-000396> <Server shut
>> down has been requested by <WLS Kernel>> <Nov 29, 2006 5:16:41 AM
>> EST> <Log Management> <BEA-170027> <The server initialized the
>> domain log broadcaster successfully. Log messages will now be b
>> roadcasted to the domain log.> <Nov 29, 2006 5:16:41 AM EST>
>> <BEA-000365> <Server sta
>> te changed to FORCE_SHUTTING_DOWN>
>>
>>
>> When i searched in the forums it has mentioned to increase the
>> timeout for this parameter 60000 but even after increasing the time
>> out i am getting the same issue.
>>
>> View the original post : http://www.jboss.com/index.html?
>> module=bb&op=viewtopic&p=3989624#3989624
>>
>> Reply to the post : http://www.jboss.com/index.html?
>> module=bb&op=posting&mode=reply&p=3989624
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
18 years
- 2
- 1
Cruisecontrol emails for JBoss Cache
by Manik Surtani
Hi guys
Can we have it such that cruise control emails (jboss-cache, jboss-
cache-testsuite, jboss-cache-testsuite-140, jbosscache-testsuite-
jdk14) as well as CVS commit mails are emailed to jbosscache-
commits(a)lists.jboss.org? They currently go to jboss-dev.
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
18 years
- 1
- 0
Fwd: [JBossCache] - Jboss Cache not working in weblogic 9.2
by Manik Surtani
I've seen this a couple of times on the user forums lately - do we
have a problem with state transfers on WebLogic?
--
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
Begin forwarded message:
> From: Kavipriya <do-not-reply(a)jboss.com>
> Date: 29 November 2006 10:18:03 GMT
> To: manik.surtani(a)jboss.com
> Subject: [JBossCache] - Jboss Cache not working in weblogic 9.2
>
> In the cluster environment. I have two servers. When i start the
> first server i dont have any problems but when i start the second
> server it is throwing the following exception in the back end.
>
> org.jboss.cache.CacheException: Initial state transfer failed:
> Channel.getState(
> ) returned false
> at org.jboss.cache.TreeCache.fetchStateOnStartup
> (TreeCache.java:2749)
> at org.jboss.cache.TreeCache.startService(TreeCache.java:1330)
> at
> com.taxware.twe.common.storage.impl.MessagingServiceImpl.startService
> (MessagingServiceImpl.java:117)
> at com.taxware.twe.common.storage.StartupServlet.startInit
> (StartupServle
> t.java:185)
> at com.taxware.twe.common.storage.StartupServlet.init
> (StartupServlet.jav
> a:113)
> at javax.servlet.GenericServlet.init(GenericServlet.java:256)
> at weblogic.servlet.internal.StubSecurityHelper
> $ServletInitAction.run(St
> ubSecurityHelper.java:276)
> at weblogic.security.acl.internal.AuthenticatedSubject.doAs
> (Authenticate
> dSubject.java:321)
> at weblogic.security.service.SecurityManager.runAs
> (SecurityManager.java:
> 121)
> at
> weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecuri
> tyHelper.java:68)
> at
> weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubL
> ifecycleHelper.java:58)
> at weblogic.servlet.internal.StubLifecycleHelper.
> (StubLifecycleHel
> per.java:48)
> at weblogic.servlet.internal.ServletStubImpl.prepareServlet
> (ServletStubI
> mpl.java:504)
> at
> weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppS
> ervletContext.java:1698)
> at
> weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(
> WebAppServletContext.java:1675)
> at
> weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAp
> pServletContext.java:1595)
> at weblogic.servlet.internal.WebAppServletContext.start
> (WebAppServletCon
> text.java:2734)
> at weblogic.servlet.internal.WebAppModule.startContexts
> (WebAppModule.jav
> a:892)
> at weblogic.servlet.internal.WebAppModule.start
> (WebAppModule.java:336)
> at weblogic.application.internal.flow.ModuleStateDriver
> $3.next(ModuleSta
> teDriver.java:204)
> at weblogic.application.utils.StateMachineDriver.nextState
> (StateMachineD
> river.java:26)
> at
> weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStat
> eDriver.java:60)
> at
> weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedMod
> uleDriver.java:200)
> at
> weblogic.application.internal.flow.ModuleListenerInvoker.start(Module
> ListenerInvoker.java:117)
> at weblogic.application.internal.flow.ModuleStateDriver
> $3.next(ModuleSta
> teDriver.java:204)
> at weblogic.application.utils.StateMachineDriver.nextState
> (StateMachineD
> river.java:26)
> at
> weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStat
> eDriver.java:60)
> at
> weblogic.application.internal.flow.StartModulesFlow.activate(StartMod
> ulesFlow.java:26)
> at weblogic.application.internal.BaseDeployment$2.next
> (BaseDeployment.ja
> va:641)
> at weblogic.application.utils.StateMachineDriver.nextState
> (StateMachineD
> river.java:26)
> at weblogic.application.internal.BaseDeployment.activate
> (BaseDeployment.
> java:229)
> at
> weblogic.application.internal.DeploymentStateChecker.activate(Deploym
> entStateChecker.java:154)
> at
> weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(Ap
> pContainerInvoker.java:80)
> at
> weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicD
> eployment.java:181)
> at
> weblogic.deploy.internal.targetserver.BasicDeployment.activateFromSer
> verLifecycle(BasicDeployment.java:352)
> at weblogic.management.deploy.internal.DeploymentAdapter
> $1.doActivate(De
> ploymentAdapter.java:52)
> at
> weblogic.management.deploy.internal.DeploymentAdapter.activate(Deploy
> mentAdapter.java:186)
> at weblogic.management.deploy.internal.AppTransition
> $2.transitionApp(App
> Transition.java:30)
> at
> weblogic.management.deploy.internal.ConfiguredDeployments.transitionA
> pps(ConfiguredDeployments.java:233)
> at
> weblogic.management.deploy.internal.ConfiguredDeployments.activate(Co
> nfiguredDeployments.java:169)
> at
> weblogic.management.deploy.internal.ConfiguredDeployments.deploy(Conf
> iguredDeployments.java:123)
> at
> weblogic.management.deploy.internal.DeploymentServerService.resume(De
> ploymentServerService.java:173)
> at
> weblogic.management.deploy.internal.DeploymentServerService.start(Dep
> loymentServerService.java:89)
> at weblogic.t3.srvr.SubsystemRequest.run
> (SubsystemRequest.java:64)
> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
> at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
> com.taxware.twe.common.exception.TaxwareSystemException: General
> Application Fai
> lure.Please contact System Administrator.
> at
> com.taxware.twe.common.storage.impl.MessagingServiceImpl.startService
> (MessagingServiceImpl.java:124)
> at com.taxware.twe.common.storage.StartupServlet.startInit
> (StartupServle
> t.java:185)
> at com.taxware.twe.common.storage.StartupServlet.init
> (StartupServlet.jav
> a:113)
> at javax.servlet.GenericServlet.init(GenericServlet.java:256)
> at weblogic.servlet.internal.StubSecurityHelper
> $ServletInitAction.run(St
> ubSecurityHelper.java:276)
> at weblogic.security.acl.internal.AuthenticatedSubject.doAs
> (Authenticate
> dSubject.java:321)
> at weblogic.security.service.SecurityManager.runAs
> (SecurityManager.java:
> 121)
> at
> weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecuri
> tyHelper.java:68)
> at
> weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubL
> ifecycleHelper.java:58)
> at weblogic.servlet.internal.StubLifecycleHelper.
> (StubLifecycleHel
> per.java:48)
> at weblogic.servlet.internal.ServletStubImpl.prepareServlet
> (ServletStubI
> mpl.java:504)
> at
> weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppS
> ervletContext.java:1698)
> at
> weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(
> WebAppServletContext.java:1675)
> at
> weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAp
> pServletContext.java:1595)
> at weblogic.servlet.internal.WebAppServletContext.start
> (WebAppServletCon
> text.java:2734)
> at weblogic.servlet.internal.WebAppModule.startContexts
> (WebAppModule.jav
> a:892)
> at weblogic.servlet.internal.WebAppModule.start
> (WebAppModule.java:336)
> at weblogic.application.internal.flow.ModuleStateDriver
> $3.next(ModuleSta
> teDriver.java:204)
> at weblogic.application.utils.StateMachineDriver.nextState
> (StateMachineD
> river.java:26)
> at
> weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStat
> eDriver.java:60)
> at
> weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedMod
> uleDriver.java:200)
> at
> weblogic.application.internal.flow.ModuleListenerInvoker.start(Module
> ListenerInvoker.java:117)
> at weblogic.application.internal.flow.ModuleStateDriver
> $3.next(ModuleSta
> teDriver.java:204)
> at weblogic.application.utils.StateMachineDriver.nextState
> (StateMachineD
> river.java:26)
> at
> weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStat
> eDriver.java:60)
> at
> weblogic.application.internal.flow.StartModulesFlow.activate(StartMod
> ulesFlow.java:26)
> at weblogic.application.internal.BaseDeployment$2.next
> (BaseDeployment.ja
> va:641)
> at weblogic.application.utils.StateMachineDriver.nextState
> (StateMachineD
> river.java:26)
> at weblogic.application.internal.BaseDeployment.activate
> (BaseDeployment.
> java:229)
> at
> weblogic.application.internal.DeploymentStateChecker.activate(Deploym
> entStateChecker.java:154)
> at
> weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(Ap
> pContainerInvoker.java:80)
> at
> weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicD
> eployment.java:181)
> at
> weblogic.deploy.internal.targetserver.BasicDeployment.activateFromSer
> verLifecycle(BasicDeployment.java:352)
> at weblogic.management.deploy.internal.DeploymentAdapter
> $1.doActivate(De
> ploymentAdapter.java:52)
> at
> weblogic.management.deploy.internal.DeploymentAdapter.activate(Deploy
> mentAdapter.java:186)
> at weblogic.management.deploy.internal.AppTransition
> $2.transitionApp(App
> Transition.java:30)
> at
> weblogic.management.deploy.internal.ConfiguredDeployments.transitionA
> pps(ConfiguredDeployments.java:233)
> at
> weblogic.management.deploy.internal.ConfiguredDeployments.activate(Co
> nfiguredDeployments.java:169)
> at
> weblogic.management.deploy.internal.ConfiguredDeployments.deploy(Conf
> iguredDeployments.java:123)
> at
> weblogic.management.deploy.internal.DeploymentServerService.resume(De
> ploymentServerService.java:173)
> at
> weblogic.management.deploy.internal.DeploymentServerService.start(Dep
> loymentServerService.java:89)
> at weblogic.t3.srvr.SubsystemRequest.run
> (SubsystemRequest.java:64)
> at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
> at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
> <Nov 29, 2006 5:16:41 AM EST> <BEA-000388> <JVM called
> WLS shutdown hook. The server will force shutdown now>
> <Nov 29, 2006 5:16:41 AM EST> <BEA-000396> <Server shut
> down has been requested by <WLS Kernel>>
> <Nov 29, 2006 5:16:41 AM EST> <Log Management> <BEA-170027> <The
> server
> initialized the domain log broadcaster successfully. Log messages
> will now be b
> roadcasted to the domain log.>
> <Nov 29, 2006 5:16:41 AM EST> <BEA-000365> <Server sta
> te changed to FORCE_SHUTTING_DOWN>
>
>
> When i searched in the forums it has mentioned to increase the
> timeout for this parameter 60000 but even after increasing the
> time out i am getting the same issue.
>
> View the original post : http://www.jboss.com/index.html?
> module=bb&op=viewtopic&p=3989624#3989624
>
> Reply to the post : http://www.jboss.com/index.html?
> module=bb&op=posting&mode=reply&p=3989624
18 years
- 1
- 0
RE: Fundamental problem with pessimistic locking
by Ben Wang
Come to think of it. On the other side of the coin, the correctness of
ROOT node locking only has impact if you are manipulating the fqn under
root, e.g., "/a", correct? So as long as we advise the user not to do
this, the previous "defect" will still be OK.
So in this regard, untill we come up with multiple root access approach,
why not just document this? I am just concerned if someone needs to lock
ROOT, performance will be pretty bad.
But of course, not to lock ROOT is not to operate on "/a", e.g. create
use multiple level fqn. So there goes my argument then.
________________________________
From: Brian Stansberry
Sent: Wednesday, November 29, 2006 7:11 AM
To: Manik Surtani; Ben Wang; Bela Ban; Vladimir Blagojevic; Galder
Zamarreno; jbosscache-dev(a)lists.jboss.org
Subject: RE: Fundamental problem with pessimistic locking
Hmm; thinking out loud....
If you're not doing lots of adds/removes to the level below root, it's
not a big cost, right?
And if you are doing lots of adds/removes at that level, it's probably
important to have the correct locking behavior.
So, seems OK to me.
________________________________
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Tuesday, November 28, 2006 4:58 PM
To: Ben Wang; Bela Ban; Brian Stansberry; Vladimir Blagojevic;
Galder Zamarreno; jbosscache-dev(a)lists.jboss.org
Subject: Re: Fundamental problem with pessimistic locking
So we still haven't discussed my biggest concern here, which is
item 5) below in the list of implications. Is this performance penalty
and potential for deadlocks small enough a price to pay for the
correctness of concurrent access on the root node? What do people
think?
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Monday, November 27, 2006 7:19 PM
To: Manik Surtani
Cc: Bela Ban; Ben Wang; Brian Stansberry; Vladimir
Blagojevic; Galder Zamarreno
Subject: Re: Fundamental problem with pessimistic
locking
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)
3) Reduced concurrency due to overall stronger locks in
b)
4) Much reduced concurrency because of the locking in
c)
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 ...
Sorry about the long and rambling email. Thoughts and
opinions?
--
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 27 Nov 2006, at 10:16, Manik Surtani wrote:
Ok, take away the crap about it being a bug in
the util.concurrent code. It's a bug in JBC, specifically on line 75 in
TreeCache.java:
protected DataNode root =
NodeFactory.getInstance().createDataNode(NodeFactory.NODE_TYPE_TREENODE,
SEPARATOR, Fqn.fromString(SEPARATOR), null, null, this);
:-) The root node is initialised when new
TreeCache() is called, well before isolation levels, etc. are set, which
causes the root node to be created with isolation level of NONE. Hence
the insane behaviour when trying to content for write locks on the root
node.
Just fixed this, running a bunch of regressions
now.
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
On 26 Nov 2006, at 19:04, Bela Ban wrote:
Forwarding to the entire group
Manik Surtani wrote:
Ok, boiled it down to a contention issue
on locking Fqn.ROOT, which prior to JBCACHE-875, was never locked -
either for reading or writing. (I do this by changing the loop in the
lock() method in PLI to first consider the root before the individual
Fqn elements). (This problem is also apparent in
o.j.c.transaction.DeadlockTest on a multi-cpu box).
2006-11-26 14:58:09,566 DEBUG [Node]
(Thread-2) acquiring WL: fqn=/, caller=GlobalTransaction:<null>:2,
lock=<unlocked>
<snip>
2006-11-26 14:58:09,572 DEBUG [Node]
(Thread-3) acquiring WL: fqn=/, caller=GlobalTransaction:<null>:3,
lock=<unlocked>
<snip>
2006-11-26 14:58:09,576 DEBUG [Node]
(Thread-2) acquired WL: fqn=/, caller=GlobalTransaction:<null>:2,
lock=write owner=GlobalTransaction:<null>:2
<snip>
2006-11-26 14:58:09,581 INFO
[TxInterceptor] (Thread-3) There was a problem handling this request
java.lang.IllegalStateException: there
is already a writer holding the lock: GlobalTransaction:<null>:2 and
caller is GlobalTransaction:<null>:3
at
org.jboss.cache.lock.LockMap.setWriterIfNotNull(LockMap.java:101)
at
org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:187
)
at
org.jboss.cache.Node.acquireWriteLock(Node.java:557)
at
org.jboss.cache.Node.acquire(Node.java:517)
< snip - lots>
2006-11-26 14:58:09,850 DEBUG [Node]
(Thread-2) created child: fqn=/, child_name=NODE
I can't understand why concurrent WL
acquisition in IdentityLock.acquireWriteLock() behaves correctly for all
nodes except the root node. As you can see in the log snippet above,
both Thread-2 and Thread-3 call IdentityLock.acquireWriteLock (line 178)
and get a 'true', and one of the threads cause an exception on line 187.
--
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 26 Nov 2006, at 13:54, Manik Surtani
wrote:
I didn't want to acquire the WL
immediately since it involved an additional test to check if the next
node in the fqn needed creation. But I went with that algorithm in the
end since the locks had problems with concurrent readers attempting to
upgrade to writers.
So most of the regressions pass, as well
as the new tests introduced, and I am very close to something working,
EXCEPT one very strange problem with the IdentityLock and
ConcurrentCreationDeadlockTest.testLocalCacheLoader2Modifications() -
get the latest on the 1.3.0 branch for this to make any sense. The
problem is between lines 178 and 187 of IdentityLock, in the
acquireWriteLock() method.
Attempting to get a hold of a write lock
returns true, but setting the writer throws an exception since another
writer exists. Odd that this happens since the calling thread should
have the semaphore by then, also odd that this only seems to happen in
this one test which is meant to test concurrency in the
CacheLoaderInterceptor.
I'm still investigating, but if you have
any ideas about how and why this may happen, I'd love to hear it ... :-)
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
On 24 Nov 2006, at 15:25, Bela Ban
wrote:
Manik Surtani wrote:
On 24 Nov 2006, at 14:44, Bela Ban
wrote:
The first one you mentioned can lead to
race conditions, depending on the order of whether the upgrade on b or
the creation/WL on c happens first. What I've implemented is more like:
1: Acquire RL on a
2: Acquire RL on b
3: Identify that we need to create c.
4: Upgrade RL on b to WL
5: *now* create c, and acquire WL on it.
So there is a possibility that step 4
may block until other readers on b release their locks, but no one else
could grab the WL since the current TX will have a RL.
I see. Why don't you acquire a WL on b
(step 2) *immediately* rather than going through the upgrade if you know
you have to acquire a WL later anyway ? You might still deadlock:
2: acquire RL on b
(in the meantime): some other TX
acquires a RL on b, possibly upgrades to WL
3: you want to acquire a WL on b and
block on the other TX's RL or WL
--
Bela Ban
Lead JGroups / JBoss Clustering team
JBoss - a division of Red Hat
--
Bela Ban
Lead JGroups / JBoss Clustering team
JBoss - a division of Red Hat
18 years
- 1
- 0