Junk data misinterpreted as valid header

[rogersimmons]

The IncompleteMessageTest tests the behaviour of Queue when a write is started but not completed. A second write is then attempted, which - correctly - forces the lock and succeeds.

The issue is that data written by the incomplete attempt remains in the queue. If the second write is shorter then this (junk) data will remain after the end of the valid write. This junk data can then be misread as a valid header, which leads to undefined behaviour.

eg, after the writes in the above test, the queue looks like:

00010110  06 00 00 00 e5 68 65 6c  6c 6f 00 00 06 00 00 00  |.....hello......|
00010120  e5 77 6f 72 6c 64 00 00  00 00 20 6c 6f 6e 67 65  |.world.... longe|    <=== error here
00010130  72 20 77 72 69 74 65 00  00 00 00 00 00 00 00 00  |r write.........|
00010140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

The last valid entry is "world". The "...longer write" is junk data which is not considered part of the queue and will be overwritten by further writes.

However, AbstractWire.readDataHeader sees the "00 00 20 6c" bytes, which should be "00 00 00 00" - end of queue - but the 20 6c dangling from the failed write are picked up as part of the header value.

Fix is to ensure the next 4 bytes (after padding) are cleared to 0 when a write context is closed.

[rogersimmons]

OpenHFT/Chronicle-Wire@0fe610b

[JerryShea]

As per @nicktindall comment in OpenHFT/Chronicle-Wire#481, we should definitely enhance this test to illustrate this behaviour and the fix