Lite's built in self tests have been failing all along. A recent re-try reveals some details on how the tests fail.

Test code

The built in self tests can run against A-MQ7 fairly simply. The problem with that is that there is no diagnostic trace of any value and the network traces are very complex. It's hard to tell where in the test things go wrong. The test code also runs in a subprocess of MsTest so that breakpoints are not practical.

I took the selftest code and promoted it to a stand-alone executable. Then I added a bunch of detailed trace statements that are interleaved with the network SEND and RECV traces to create a helpful narrative of what the program is seeing and what is the failure mode.

The code is in a amqpnetlite git clone at

• repo https://github.com/ChugR/amqpnetlite
• branch private-crolke-txn-test-program at commit f5140c6
• project TransactionTestProgram

Running successfully against Lite built-in broker

Lite ships with a test broker and the transaction tests pass when run against that.

Attached files hold console logs and wireshark traces for the passing tests:

• txn-test-log-good-testbroker.txt - console log of success
• txn-test-log-good-testbroker.pcapng - pcap trace of successful test run

Failure running against ER14 broker

Running the test(s) against ER14 fails.

Attached files hold console logs and wireshark traces for the failing tests:

• txn-test-log-fail-ER14.txt - console log of fail
• txn-test-log-fail-ER14.pcapng - pcap trace of failed test run

Preliminary Analysis

The test tries to accept some messages under a transaction context that is not properly closed. The expectation is that the messages are simply placed back onto a list of acquired-but-neither-accepted-nor-rejected items. Instead the broker transfers them to the client again. See txn-test-log-fail-ER14.pcapng file frames 134 to 142.

This test is complicated. Maybe a broker guru can help figure out if the issue is indeed the broker or if the client test is misunderstanding transactional behavior.