[
http://jira.jboss.com/jira/browse/JGRP-369?page=all ]
Oyvind Eikeland updated JGRP-369:
---------------------------------
Attachment: logs.zip
Attaching logs, as requested.
draw1.log - Draw client 1 running, until leave is clicked
draw1_secondrun.log* - Draw client 1 after restart
draw2.log* - Draw client 2
draw3.log* - Draw client 3
As you can see, a lot of these messages come through. The suspected member is not removed
from the view:
226985 [DEBUG] TP.down(): - sending msg to 192.168.2.25:1379 (src=192.168.2.25:1392),
headers are {VERIFY_SUSPECT=[VERIFY_SUSPECT: ARE_YOU_DEAD],
UDP=[channel_name=DrawGroupDemo]}
ViewAccepted is not received as expected.
-----------------------------------------
Key: JGRP-369
URL:
http://jira.jboss.com/jira/browse/JGRP-369
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows XP.
java version "1.6.0-rc"
Java(TM) SE Runtime Environment (build 1.6.0-rc-b104)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b104, mixed mode, sharing)
Version: 2.4.0
CVS: $Id: Version.java,v 1.42 2006/10/31 12:45:32 belaban Exp $
History: (see doc/history.txt for details)
Reporter: Oyvind Eikeland
Assigned To: Bela Ban
Fix For: 2.5
Attachments: logs.zip
Hi,
We're evaluating JGroups and find its functionality very useful so far. We have built
an application using State transfer using
JChannel.getState() and message sending using PushPullAdapter.send(). We depend on
viewAccepted messages to be securely sent and received.
I've discovered behaviour that seems like a bug - please advise if we can configure
the protocol stack differently to avoid this issue.
I've reproduced the behaviour using org.jgroups.demos.Draw application. It happens
almost every time. You should be able to do the same.
1. start 3 clients in different dos shells. (java -classpath %CP%
org.jgroups.demos.Draw)
2. stop the coordinator client using the "Leave" button in the GUI. Do not kill
the VM. A viewAccepted message is sent to the other two apps. A new coordinator is elected
by Jgroups.
3. start the first client again. A viewAccepted message is received by all clients
4. kill the coordinator client (kill the VM). I guess this is the same behaviour as if
the network was partitioned. Now, only suspect messages are coming through - indefinetely
(Draw does not print those messages). A view accepted is not received.
If you skip step 2 and 3 above, and only do 1 and 4, a viewAccepted message is sent and
it all works.
I edited ExtendedReceiverAdapter to print this message for convenience:
public void suspect(Address suspected_mbr) {
System.out.println("Received suspect: " + suspected_mbr.toString());
}
Question:
- is this a bug, or is it something wrong with the protocol setup, that we can change to
make this work?
C:\data\mars\3rdparty\JGroups-2.4.0.src>java -classpath %CP% org.jgroups.demos.D
raw
log4j:WARN No appenders could be found for logger (org.jgroups.JChannel).
log4j:WARN Please initialize the log4j system properly.
-------------------------------------------------------
GMS: address is 192.168.2.128:2143
-------------------------------------------------------
** View=[192.168.2.128:2136|4] [192.168.2.128:2136, 192.168.2.128:2139, 192.168.
2.128:2143]
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
Received suspect: 192.168.2.128:2136
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira