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.
Make sure we do the right thing when no args are presented for an MSG, e.g. MSG <spc>.
Also do not parse at all of this is a client, only valid for routes.
Govet doesn't like functions that look like format handlers not ending in `f`,
such as Debug() vs Debugf(). This is changing some of the new log handling to
use 'f' function names to appease govet.
Updated the implicit handling of including the client as an arg without being
used in a format string. Now the client object simply has a Errorf function
for logging errors and it adds itself onto the format string.
race condition:
- a client is closed at the same time as an incoming SUB message occurs.
- the subscription is added to the srv.sl even though the socket is
closed.
- the connection cleanup has already run, so the bad state is never
corrected
- now messages may be forwarded to a client without a connection
- messages will not be forwarded to a router that needs it now, because
processMsg assumes the router already received it
