You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2008/06/17 22:16:47 UTC
DO NOT REPLY [Bug 45222] New: concurrent startup of ReplicatedMap
leads to inconsistent state.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45222
Summary: concurrent startup of ReplicatedMap leads to
inconsistent state.
Product: Tomcat 6
Version: 6.0.16
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Cluster
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: robert.newson@gmail.com
Starting four machines with a ReplicatedMap where each machine immediately puts
entries into the map frequently leads to inconsistent state. Specifically, some
nodes are missing some entries. Most are present and correct. Given the
internal work done around state transfer and the general intent of the class,
I'm assuming this is a serious bug.
I've seen this with straight;
c = new GroupChannel();
m = new ReplicatedMap(null, c, 5000, null);
m.put(key, value);
My actual rig uses TcpFailureDetector and NonBlockingCoordinator as I need
jgroups-like views (without the buggy jgroups stack!).
I can cook my own Map implementation that deals with this by periodically
resending locally owned key-value pairs, but I figured I should post the bug.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45222] concurrent startup of ReplicatedMap leads
to inconsistent state.
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45222
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
--- Comment #2 from Mark Thomas <ma...@apache.org> 2008-12-30 15:59:31 PST ---
I've done some testing of this and with your test code I see the same problem
you see. However, if the channel is started before the map is created then I
can't repeat the problem you were seeing.
There is some communication between members on map creation so it seems
reasonable to me that the channel should be started first.
It is possible that my test case isn't quite perfect (I was using 4 VMs and the
system clock to sync the starts and the clocks on the VMs were a few 10s of ms
out) so if you still see this issue with the modified test code please feel
free to re-open and I'll take a closer look.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 45222] concurrent startup of ReplicatedMap leads
to inconsistent state.
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45222
--- Comment #1 from Robert Newson <ro...@gmail.com> 2008-06-17 15:19:34 PST ---
Here's the simplest code to reproduce it. Just start this on four machines at
the same time (I used clusterssh). Most of the time each box will print a
different value from 1-4.
As a meta-question, is ReplicatedMap a supported Tribes feature or a demo? I've
been stung on this kind of thing with JGroups before (their .blocks are almost
all demo code, apparently).
public static void main(String[] args) throws Exception {
final GroupChannel channel = new GroupChannel();
final ReplicatedMap map = new ReplicatedMap(null, channel, 0,
"map",
null);
channel.start(Channel.DEFAULT);
map.put(InetAddress.getLocalHost(), "1");
while (true) {
System.out.printf("member_count: %,d, map_size: %,d\n",
channel
.getMembers().length, map.size());
SECONDS.sleep(5);
}
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org