This happens sometimes, and the latest occurence was today:
https://github.com/nats-io/java-nats/issues/96
When it happens, there is no error but subscribers would not receive
anything, etc...
This PR uses the fact that clients set the field Lang in the CONNECT
protocol that ROUTEs do not. I have checked that all Apcera supported
clients do set Lang in the CONNECT protocol.
If we plan to add Lang for routes, we need to find another field or
use a new one, in which case that would work only for new clients
(that would need to be updated).
With this change, when the server accepts a connection on the route
port and detects that this protocol field is present, it now closes
the client connection.
The nice thing is that newer clients, when incorrectly connecting
to the route port, get from the route's INFO the list of client URLs,
which means that on the initial connect error, they are able to
subsequently connect to the proper client port, so it is transparent
to the user (which may or may not be a good thing). However, it is not
guaranteed because if the client is not setting NoRandomize to true,
the client URL is added but the array shuffled, so it is possible that
the client library does not find the correct port in the connect loop.
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 use a hardcoded value of 2 seconds for Write deadline when
writing data to client's socket.
This PR makes that value configurable.
Question is should we push the setting down to the client's object
to avoid indirection such as client.srv.opts.WriteDeadline?
Doing code coverage/cross compile for a single Go release. As of now,
if we were to introduce Go 1.8 in the matrix, we would do code
coverage (which may be ok) and create release (which would not be
ok) for 2 Go releases since were were using >= comparison.
This change ensures that we do for only 1.7.x for now.
Run GetTLSConnectionState on a non-tls connection (in a dedicated test)
and a tls connection.
Because initializing the TLS connection in the tests is non-trivial,
I hijacked the TestTLSCloseClientConnection test.
When a server is told to connect to a server (with auto-discovery),
it tries to connect once. There have been a report where that
connection fails, but would probably succeed if tried again (#408).
This new parameter allows to configure the number of times a failed
implicit connect should be tried.
Resolves#408
The RunServer() function (and the various variants)
call Server.Start() in a go-routine, but do not return until
it has verified that the server is ready to accept connections.
To do so, it use GetListenEndpoint() to get a suitable connect
address (replacing "0.0.0.0" or "::" with localhost - important
on Windows). It then creates a raw TCP connection to ensure the
server is started, repeating the process in case of failure up
to 10 seconds.
This PR replaces this with a function that checks that client
listener, and route listener if configured, are set. This removes
the need to get a connect address and create test tcp connections.
The reason for this change is that NATS Streaming when starting
the NATS Server (unless configured to connect to a remote one)
calls RunServerWithAuth(), which when getting "localhost" from
GetListenEndpoint(), would fail trying to resolve it. This happened
for the NATS Streaming Docker image built with Go 1.7+.
