When a TLS timeout occurs, it was possible that code trying to
send data would get a timeout error and report it as a Slow Consumer
with the write deadline exceeded error.
Checking that if the connection is TLS and handshake not complete,
it is likely a TLS timeout error instead.
Resolves#835
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
When TLS and authorization is enabled, the authorization timeout can
fire during the TLS handshake, causing the server to write the
authorization timeout error string into the client socket, injecting
what becomes bad data into the TLS handshake. This creates misleading
errors on the client such as tls: oversized record received with length
21024.
This moves the authorization timeout scheduling to after the TLS
handshake to avoid the race. This should be safe since TLS has its own
handshake timeout. Added a unit test that fails with the old behavior
and passes with the new. LMK if you can think of a better way to test
this.
Fixes#432
Staticcheck has probably been updated and is finding new errors.
They have been fixed.
Also, moved the run of staticcheck before running the test suite,
so if it fails, it fails sooner ;-).
We would get failures on Travis, I would think because of small TLS timeout. Increase (or set) the TLS timeout to 2 seconds in most configuration files. Update tests that relied on the original value.
Without the server fix, tls_test.go would likely report an error. The server would show a parser error with protocol snippet containing "random" bytes, likely encrypted data.
