Bugs item #677495, was opened at 2003-01-30 16:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=677495&group_id=22866

Category: Clustering
Group: v3.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mikko Koponen (mtkopone)
Assigned to: Sacha Labourey (slaboure)
Summary: JGCacheInvalidationBridge stumbling over itself.

Initial Comment:
Greetings all.

We stumbled upon a bug in the 
JGCacheInvalidationBridge when testing cluster failover. 
The replicantsChanged() method attempts removal of 
dead cluster members through the DistributedState 
interface, while holding on to an iterator to the map 
being affected. The removal causes a 
ConcurrentModificationException from ensuing calls to 
the iterator. 

Stack trace:

12:51:40,801 ERROR 
[SaffronTESTBackPartition:ReplicantManager] 
membershipChanged 
failedjava.util.ConcurrentModificationException
        at java.util.HashMap$HashIterator.nextEntry
(HashMap.java:762)
        at java.util.HashMap$KeyIterator.next
(HashMap.java:798)
        at 
org.jboss.cache.invalidation.bridges.JGCacheInvalidation
Bridge.replicantsChanged
(JGCacheInvalidationBridge.java:123)
        at 
org.jboss.ha.framework.server.DistributedReplicantMana
gerImpl.notifyKeyListeners
(DistributedReplicantManagerImpl.java:662)
        at 
org.jboss.ha.framework.server.DistributedReplicantMana
gerImpl.purgeDeadMembers
(DistributedReplicantManagerImpl.java:774)
        at 
org.jboss.ha.framework.server.DistributedReplicantMana
gerImpl.membershipChanged
(DistributedReplicantManagerImpl.java:296)
        at 
org.jboss.ha.framework.server.HAPartitionImpl.viewAcce
pted(HAPartitionImpl.java:371)
        at 
org.javagroups.blocks.MessageDispatcher$ProtocolAda
pter.passUp(MessageDispatcher.java:488)
        at org.javagroups.blocks.RequestCorrelator.receive
(RequestCorrelator.java:294)
        at 
org.javagroups.blocks.MessageDispatcher$ProtocolAda
pter.up(MessageDispatcher.java:513)
        at org.javagroups.JChannel.up(JChannel.java:936)
        at org.javagroups.stack.ProtocolStack.up
(ProtocolStack.java:301)
        at 
org.javagroups.stack.ProtocolStack.receiveUpEvent
(ProtocolStack.java:317)
        at org.javagroups.stack.Protocol.passUp
(Protocol.java:399)
        at 
org.javagroups.protocols.pbcast.STATE_TRANSFER.up
(STATE_TRANSFER.java:133)
        at org.javagroups.stack.UpHandler.run
(Protocol.java:50)

--
Mikko Koponen
Krocus Communications, Finland


----------------------------------------------------------------------

>Comment By: Sacha Labourey (slaboure)
Date: 2003-02-07 17:18

Message:
Logged In: YES 
user_id=95900

Thank you for the reports. You correctly found the two bugs 
but only solved one ;)

We don't use HAPartition.HAMembershipListener because it 
doesn't allow for heterogeneous deployments i.e. only two 
nodes of a 4 nodes cluster running the cache invalidation 
bridge.

Fixed in both Branch_3_2 and HEAD

----------------------------------------------------------------------

Comment By: Mikko Koponen (mtkopone)
Date: 2003-02-03 19:26

Message:
Logged In: YES 
user_id=586533


After some more meddling with failover, we now have some 
new concerns ;)
I haven't gone _very_ far into the code, so some of this might 
be speculation. 

The replicantsChanged method of JGCacheInvalidationBridge 
gets called with the values of the serialized objects set in the 
DRM. These values are passed as the newReplicants list. 

The bridge apparently expects to find something quite 
different than a bunch of empty strings in this list, and 
therefore proceeds to remove everything related to the 
invalidation cache from the DistributedState.  

Also, the DRM is apparently only used to find out about dead 
cluster members. This same sort of functionality is available 
in the HAPartition.HAMembershipListener interface.

I wrote a patch to use the HAMembershipListener instead of 
the DRM for these events. It has been tested by pulling the 
plug from different cluster members a couple of times, and 
checking the content in the DS. Seems to work fine. 

--
Mikko Koponen
Krocus Communications, Finland

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=677495&group_id=22866


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to