Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
0.1.0
-
None
-
None
Description
In researching the bug reported in DISPATCH-939 (router closes connection with error) a problem in the test has emerged.
The Cpp shim uses on_tracker_accept and then closes the connection when when the number of confirmed messages equals the number of total messages. In theory, then, the test should never close the connection before the router has confirmed and accepted all the messages. From the trace in DISPATCH-939 the connection is closed about 2 mS after the fourth Sender message has gone over the wire to Dispatch. Not enough dispositions have been received to cover the number of messages sent so why has the connection been closed?
Adding some print debugging reveals the issue. In the test as it is today the totalMessages is 2. However, in the send loop the actual number of messages sent is 2 times the number of elements in the incoming list of test values. In today's case the values list has four elements so a total of 8 messages should go over the wire.
A hack '* 4' is added to the on_tracker_accept to make the test work:
if (_msgsConfirmed >= _totalMsgs * 4) {
print debugging session shows:
InteropTestError: Send shim 'ProtonCpp':
on_container_start: _totalMsgs: 2
on_sendable: msgsSent: 1
on_sendable: msgsSent: 2
on_sendable: msgsSent: 3
on_sendable: msgsSent: 4
on_sendable: msgsSent: 5
on_sendable: msgsSent: 6
on_sendable: msgsSent: 7
on_sendable: msgsSent: 8
on_tracker_accept: msgsConfirmed: 1
on_tracker_accept: msgsConfirmed: 2
on_tracker_accept: msgsConfirmed: 3
on_tracker_accept: msgsConfirmed: 4
on_tracker_accept: msgsConfirmed: 5
on_tracker_accept: msgsConfirmed: 6
on_tracker_accept: msgsConfirmed: 7
on_tracker_accept: msgsConfirmed: 8
The test needs to get the test elementsList factor back into the tracker to decide correctly when to close the connection.
This test has still been valuable pointing out an issue in Dispatch that needs some attention.