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.
- fix bug that did not update last activity on message delivery
- added sort capabilities for last activity
- avoid extra Reverse by simply changing Less func
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.
* There was a race during unsubscribe()
* 'go test -race' reports a race in TestSetLogger test. This one could be ignored since we normally invoke SetLogger only on server startup. That being said, Travis failed when I tried to submit a PR for the fix of the unsubscribe race. So proposing to fix the logger too.
If processRoute executes before createRoute finishes registering the route, and before a subscriber has connected (or reconnected), and the subscriber connects (or reconnects) before the route is registered, then this subscription will stay local and not be forwarded to the route.
This is issue #136. With routes, it is possible that a subscriber connects (or reconnects) and is about to broadcast the SUB protocol to the routed server, and at the same time, the server sends the list of the local subscriptions. This would result in a SUB processed twice, adding the same sub in the sublist twice. If the server sending the subscription list is restarted, this will leave "detached" subscriptions in the sublist which would trigger the "Bad or Missing ROUTER info" for every message published on that subject.
