Send returns no error after broker drops connection

[andrewzeneski]

The first attempt to send after a broker drops the connection returns no [expected] error. Subsequent attempts to send will return an expected error.

[gmallard]

Why is this surprising if the time deltas are fairly small?

[gmallard]

It is surprising if the time deltas are large. So something seems amiss. No idea at present as to cause. If you have any insight, I would love t hear it.

[gmallard]

@andrewzeneski Please correct me if the following is incorrect.

Observed Scenario

• Manual: Start broker
• Manual: Start stompngo publisher
• Publisher: Send message 1
• Publisher: Start Sleep for 2 minutes
• Manual: Kill broker
• Publisher: Send message 2, no error received
• Publisher: Start Sleep for 2 minutes
• Publisher: Send message 3, receive error (broken pipe)

Expected Scenario

• Manual: Start broker
• Manual: Start stompngo publisher
• Publisher: Send message 1
• Publisher: Start Sleep for 2 minutes
• Manual: Kill broker
• Publisher: Send message 2, receive error (broken pipe)

[andrewzeneski]

@gmallard: That is correct. In my testing the "sleep" time was more in
seconds than minutes though. I don't think it should matter how long the
broker is down, if the connection is dropped an error should be returned so
the application has a chance to handle the fact the message wasn't sent as
it sees fit.

[gmallard]

Thanks.

Some notes for posterity.

This behavior is somewhat broker dependent.

I observe the unexpected behavior with:

• ActiveMQ
• RabbitMQ
• stompserver_ng

Strangely, I observe the expected behavior with:

• Apollo

I believe I can bypass the unexpected behavior with a little more due diligence (and overhead) in stompngo's writer goroutine. More on this later.

I continue to think that timings can make a difference here. If client is sending every 100 nano-seconds, and a broker crashes, it seems likely that it will take several 'send cycles' for the client TCP system to even note that the connection is 'gone'.

Also note that different scenarios, e.g. a cut or unplugged wire will cause totally different behavior.

[gmallard]

@andrewzeneski Plese try a system built with the HEAD of current 'dev' branch: e43869f

[gmallard]

Closed:

e43869f

[gmallard]

If you are still using the stompngo package please try the current v.1.0.2 tag.

Tag information:

b1f1d96 refs/tags/v1.0.2

Document that version number in any issue reports.

Thanks for the support.

Guy