Acceptance Test fails

[MichaelEwe]

The acceptance tests fails
I used:

• zeromq v3.2.1-RC2, from 2012/10/15 compiled from source
• clrmq from git repository (as of Nov 13)

the error occurs both under WIN-XP (32bit) and Win-7 (32bit). The reported error is:

225 Tests : 2 Failures, 0 Errors, 0 Not Run

Errors and Failures:

1. ShouldSetTheClosedSocketAddress (ZeroMQ.AcceptanceTests.ZmqMonitorTests.MonitorTests+WhenMonitori
   ngClosedEvent.ShouldSetTheClosedSocketAddress)
   String lengths are both 18. Strings differ at index 0.
   Expected: "tcp://0.0.0.0:9000"
   But was: "¨Â↑♥//0.0.0.0:9000"
   -----------^

   bei ZeroMQ.AcceptanceTests.ZmqMonitorTests.MonitorTests.WhenMonitoringClosedEvent.ShouldSetTheClo
   sedSocketAddress() in C:\Michael\Downloads\clrzmq-master\src\ZeroMQ.AcceptanceTests\ZmqMonitorTests
   MonitorEvents.cs:Zeile 174.

2. ShouldSetTheConnectedSocketAddress (ZeroMQ.AcceptanceTests.ZmqMonitorTests.MonitorTests+WhenMonit
   oringConnectedEvent.ShouldSetTheConnectedSocketAddress)
   Expected string length 20 but was 0. Strings differ at index 0.
   Expected: "tcp://127.0.0.1:9000"
   But was: <string.Empty>
   -----------^

   bei ZeroMQ.AcceptanceTests.ZmqMonitorTests.MonitorTests.WhenMonitoringConnectedEvent.ShouldSetThe
   ConnectedSocketAddress() in C:\Michael\Downloads\clrzmq-master\src\ZeroMQ.AcceptanceTests\ZmqMonitor
   Tests\MonitorEvents.cs:Zeile 134.

[jgoz]

Thanks for reporting this. This is a known issue (at least, to me) with monitoring. The problem is in ZMQ: instead of sending the contents of the string when the monitor event is raised, it sends the memory address of the string. This is done for performance reasons, presumably. By the time the event reaches managed code, the memory at the specified address may have already been freed, resulting in wrong or empty strings.

I think the solution will be for me to log an issue with libzmq and add the Ignore attribute to these specific tests in the meantime.

[MichaelEwe]

Many thanks for the information!

As far as I can see, your analysis means, that these events wont work reliably. Maybe it would be better to drop them? Anyway: splendid work!

[jgoz]

You're probably right that the data returned from those events are not reliable. But the events themselves do get triggered reliably, so they may still be useful to some people. I've already put warnings in the API docs for the events with unreliable data and since monitoring is not intended for application logic (just performance metrics, etc.), I'm going to leave these events in place. Future work on ZMQ may improve the situation.