This is the result of flapping tests in go-nats that were caused
by a defect (see PR https://github.com/nats-io/go-nats/pull/348).
However, during debugging, I realize that there were also things
that were not quite right in the server side. This change should
make it the notification of cluster topology changes to clients
more robust.
When a server accepts a route, it will keep track of that server
`connectURLs` array. However, if the server was creating a route
to that other server at the same time, it will promote the route
as a solicited one. The content of that array was not transfered,
which means that on a disconnect, it was possible that the cluster
topology change was not properly sent to clients.
Until now, a server would only notify clients of servers that join
the cluster. More than that, a server would send ot its clients only
information if new servers were added.
This PR changes this by sending to clients that support async INFO
the list of URLs for all servers in the cluster any time that there
is a change (joining or leaving the cluster).
As of now, clients will not be affected by the change (and will not
take benefit of this: removing servers from their server pool). This
will be addressed in each supported client once this is merged.
- Renamed GitHash to gitCommit as per discussions with Ivan
- Set gitHash to 'not set' if not set (as in the case of a local build)
# Conflicts:
# server/server.go
[FIX] Docker images were injecting the compile time variable `github.com/nats-io/gnatsd/version.GITCOMMIT`, however this is not referenced nor exposed anywhere.
[FIX] Docker images were injecting the compile time variable `github.com/nats-io/gnatsd/version.GITCOMMIT`, however this is not referenced nor exposed anywhere.
When the option Cluster.NoAdvertise is false, a server will send
an INFO protocol message to its client when a server has joined
the cluster.
Previously, the protocol would be sent only if the
joining server's "client URLs" (the addresses where clients connect
to) were new. It will now be sent regardless if the server joins
(for the first time) or rejoins the cluster.
Clients are still by default invoking the DiscoveredServersCB callback
only if they themselves detect that new URLs were added. A separate
PR may be filled to client libraries repo to be able to invoke
the callback anytime an async INFO protocol is received.
Based on @madgrenadier PR #597.
If server requires TLS and clients are connecting, and a Connz
request is made while clients are still in TLS Handshake, the
call to tls.Conn.ConnectionState() would block for the duration
of the handshake. This would cause the overall http request to
take too long.
We will now not try to gather TLSVersion and TLSCipher from a
client that is still in TLS handshake.
Resolves#600
The http servers for those two were recently modified to set
a ReadTimeout and WriteTimeout. The WriteTimeout specifically
caused issues for Profiling since it is common to ask sampling
of several seconds. Pprof code would reject the request if it
detected that http server's WriteTimeout was more than sampling
in request.
For monitoring, any situation that would cause the monitoring code
to take more than 2 seconds to gather information (could be due
to locking, amount of objects to return, time required for sorting,
etc..) would also cause cURL to return empty response or WebBrowser
to fail to display the page.
Resolves#600
Using a goto based loop makes it become a leaf function which can be
inlined, making us get a slight performance increase in the fast path.
See: https://github.com/golang/go/issues/14768
This is just for tests since from main.go, the FlagSet is set
with ExitOnError so Parse() would call os.Exit(2).
Regardless, I wanted to add error checking and a test for that.
Related to #578
The removal of SetClientAuthMethod removed any possibility of providing
a custom auth backend.
This patch add it back as a Option attribute, so we can wait comfortably for #434,
which aims to provide more extensible external Auth.
There were some cases where override would not work. Any command
line parameter that would be set to the type default value (false
for boolean, "" for string, etc) would not be taken into account.
I moved all the flags parsing and options configuration into
a new function, which may help reduce code duplication in
NATS Streaming.
The other advantage of moving this in a function is that it
can now be unit tested.
I am also removing call to `RemoveSelfReference()` which attempted
to remove a route to self, which has been already solved at runtime
with detecting and ignoring a route to self.
This function would be invoked only when routes were defined in
the configuration file, not in the command line parameter.
Removing this call also solves an user issue (#577)
Resolves#574Resolves#577
This is similar to #561 where `*` and `>` characters appear in tokens
as literals, not wilcards.
Both Insert() and Remove() were checking that the first character
was `*` or `>` and consider it a wildcard node. This is wrong. Any
token that is more than 1 character long must be treated as a literal.
Only for token of size one should we check if the character is `*`
or `>`.
Added a test case for Insert and Remove with subject like `foo.*-`
or `foo.>-`.
