gnatsd currently uses a global logger. This can cause some problems
(especially around the config-reload work), but global variables are
also just an anti-pattern in general. The current behavior is
particularly surprising because the global logger is configured through
calls to the Server.
This addresses issue #500 by removing the global logger and making it a
field on Server.
- Removed unnecessary cast check to (*net.TCPConn). When the timer
fires, the connection is already established. Replaced with check
that connection has not been closed.
- Add PING test that checks that pings are sent to TLS connections.
- Changed Go version to 1.7.5 in travis.
- Removed test package from code coverage.
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.
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?
This will protect the server from non NATS clients (telnet, etc),
or misbehaving clients that would create the tcp connection but
block before sending the CONNECT.
The drawback is that the client may or may not receive the error
message (in my tests, it was getting only between 10%-20% of times).
Clients that will be at the ClientProtoInfo protocol level (or above)
will now receive an asynchronous INFO protocol when the server
they connect to adds a *new* route. This means that when the cluster
adds a new server, all clients in the cluster should now be notified
of this new addition.
This PR addresses the issue by testing the result of the
`Timer.Stop()` method, which if `false` indicates that the callback
may be in progress. When that happens, the `processConnect` method
will wait for the callback to finish and simply return. The auth
timeout error will therefore be received by the client during the
synchronous connect process, which will allow it to try again.
Resolves#289
This commit has 3 changes:
- Remove duplicate logic for creating cache results map.
- Move code out of an if that will always be true and remove the if.
- Use == 0 instead of <= 0 for comparing the return value of len(X) as the value can never be < 0.
Ensure that all socket writes are protected with deadlines.
For connection Close(), also use deadlines since in case of TLS,
the Close() will send an alert (do a write) if the handshake was
completed. If the peer is not reading, this would cause the Close()
to hang.
When processing a connect request, there was a risk of race condition
when the server was being shutdown. Capture fields that are checked
under lock and lock when setting the route's remote ID.
Resolves#255
Refactor the way client is initialized. We need to ensure that
clients are not added to the clients map and readLoop started if
the server is in the process of being shutdown otherwise there
is a chance that the server already gathered the list of connections
to close and this one would not be included, leaving a readLoop
running.
Same occurs for routes, with the complexity that the readLoop is
started well before the route connection is added to the server
routes' list. We need a temporary map that contains those connections
to be able to close them on server Shutdown.
Fixed some flapping tests.
We need to make sure that when Shutdown() returns, routes go routines
that try to connect or reconnect have returned. Otherwise, this may
affect tests running one after the other (a server from one test
may connect to a server in the next test).
- The number of outstanding PINGs is now reset whenever the server
receives a PONG from the client.
- Updated parser test to check c.pout.
- Added a test to check for unprompted PONGs.
Resolves issue: https://github.com/nats-io/gnatsd/issues/168
Both seed and chained cases are now handled properly when servers
connect quickly and concurrently to one another.
When accepting a route, the server will forward the new route INFO
protocol to its known routes. In turn those routes will connect
to the new server (if not already connected).
A retry for implicit route was introduced to mitigate the issue
with two servers connecting to each other and electing the opposite
connection as the winner, resulting in both connections being dropped.
The server with smaller ID will try once to reconnect.
Some tests were fixed to handle possible extra INFO protocol.
New tests added.
Fix issue: https://github.com/nats-io/gnatsd/issues/206
Attempt to address issue #175.
Instead of trying to detect if route URL will point to route listen address, detects that the route remoteID is server's ID.
If so, closes the connection and stop trying.
