[
https://jira.jboss.org/jira/browse/JGRP-837?page=com.atlassian.jira.plugi...
]
Richard Achmatowicz commented on JGRP-837:
------------------------------------------
Just for the record, I decided to start implementing this now as I was looking through
NAKACK and I suspect there is a problem with REBROADCAST which I wanted to confirm.
My suspicion is that, because the code implementing the REBROADCAST callaback only tries a
fixed number of times to get all messages in sync before it returns, a peer whose XMIT_RSP
messages were persistently dropped would not have its FIFO state updated correctly before
REBROADCAST returns. This breaks the VS guarantee maintained by FLUSH, if my suspicions
are correct.
So I needed to write a test case which could:
(i) take three peers and get each of them into a specific FIFO state (i.e. specific state
of stabilized, received, and delivered messages)
(ii) initiate a REBROADCAST callback on one peer
(iii) cause another peer who needs to respond to XMIT_RSP messages to drop all of them
persistently.
I believe that the functionality added to Simulator can be used to set up conditions (i)
and (iii).
Add failure simulation capabilities to Simulator
-------------------------------------------------
Key: JGRP-837
URL:
https://jira.jboss.org/jira/browse/JGRP-837
Project: JGroups
Issue Type: Feature Request
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Priority: Minor
The Simulator can be used to test protocol layers in isolation. Multiple Simulator
instances can be configured so that they model a multicast group.
In its present state, messages are transported from one Simulator instance to another by
the send_thread, which moves messages from send_queue to recv_queue in a reliable fashion.
Futhermore, all Simulators perform at the same speed. I'd like to use the Simulator
to additionally simulate failures, in order to check the robustness of the protocols. In
particular, i'd like to model:
* dropped, reordered, corrupted messages
* failed processors ('crash' failure)
* network partitions
* slow processes
This JIRA issue will track progress on this and allow for discussion.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira