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