Bugfix for line Disruptor/1P3C, indicated by the line "// TODO some random failure here to fix (the sequence number received by the consumer seems ok all the time but the end result is not)."

*** Summary

The 1P3C (1 producer / 3 consumer) test has a comment "// TODO some random 
failure here to fix (the sequence number received by the consumer seems ok all 
the time but the end result is not).".

I have reproduced the problem, and found a fix that proves where the problem 
lies.

The good news is that the problem will never occur in normal operation, and 
only occurs when "_ringBuffer.Halt();" is called before the consumers have had 
time to clear out the ring buffer. The temporary fix is to add a 
"System.Threading.Thread.Sleep(500);" before "_ringBuffer.Halt();" is called. 
Since "_ringBuffer.Halt();" is unlikely to be called unless the program is 
exiting anyway, this problem is unlikely to affect things in a negative way 
during normal operation.

*** What steps will reproduce the problem?

1. Open "MultiCast1P3CDisruptorPerfTest.cs".
2. Identify the line "// TODO some random failure here to fix (the sequence 
number received by the consumer seems ok all the time but the end result is 
not)."
3. Uncomment the three assert statements below said line, especially 
"Assert.AreEqual(ExpectedResults[1], _handler2.Value, "Sub");".
4. Change the number of iterations to 1,000,000, by altering a line in the same 
file to: "public MultiCast1P3CDisruptorPerfTest() : base(1000000)". This step 
is optional, and speeds the test up (the failure only happens at the end of 
each run when the ring buffer is being torn down).
5. Run the project with the command line parameters "2 1 1000", which indicates 
1P3C test, disruptor, 1000 runs."
6. At some point in the first 5 to 30 runs, the program will fail with an 
assert statement.
7. Now, add the line "System.Threading.Thread.Sleep(500);" before 
_ringBuffer.Halt();
8. Run the project again with the command line parameters "2 1 1000".
9. It will complete 1000 runs without tripping on the assert statement.

Note that this is not really a bugfix - its a sloppy bandaid for the underlying 
problem, which is that "_ringBuffer.Halt();" tears the ringbuffer down before 
the consumers have had a chance to consume everything that is available.

However, I've proven the cause of the problem:
- The problem will never occur during normal operation.
- The problem It will only occur on program exit, when the ring buffer is 
prematurely torn down with "_ringBuffer.Halt();", before the consumers have had 
time to consume everything they are entitled to.

*** What version of the product are you using? On what operating system?

Latest Disruptor .NET release as of 2011-08-11, v1.0.0. Windows 7 x64, on a 
high end Intel i7.

*** Please provide any additional information below.

If you run the program in "Debug" mode, the 1P3C version will generate garbage 
collection, due to some debugging statements the program itself. To eliminate 
the garbage collection process, run it in release mode which disables the 
statements after the "#if DEBUG" statements.

Original issue reported on code.google.com by shane.to...@gmail.com on 11 Aug 2011 at 8:27

sdesilets / disruptor-net

Bugfix for line Disruptor/1P3C, indicated by the line "// TODO some random failure here to fix (the sequence number received by the consumer seems ok all the time but the end result is not)." #6