Otherwise we get platform-specific failures and even generic client exceptions.
This case is potentially valid but is likely to be really rare (if you use TLS,
you probably also authenticate, using credentials or the certificate).
In the original patch this scenario was expected to fail. We now go back
to square 1.
the test was highly timing sensitive; it published 1000 messages and
expected one of those publishes to fail due to the socket getting
closed by the server when encountering the first publish. So if the
client was quick enough / the server slow enough, all the publishes
would go through before the server processed the first one and closed
the socket. Cue test failure.
The new test sends an mqtt 'ping' and waits for a response. Not only
is this non-racy and doesn't require any magic timouts, it also is a
better exercise of the server logic: A 'publish' on a connection which
hasn't seen a 'connect' will fail anyway, even w/o the server code in
place that detects the missing 'connect', since processing a 'publish'
requires an amqp client connection, which in turn is only established
on 'connect'. By contrast, a 'ping' does not require an amqp client
connection. Hence removing the "make sure we have seen a 'connect'"
logic now results in a 'ping' response being sent, which makes the
test fail, as expected.
Michael Klishin
Matthias Radestock
Simon MacMullen
Emile Joubert