1. Accounts will show up in connection info if auth=1.
2. You can filter by user (?auth=1&user=ivan) or account (?auth=1&acc=eng)
Signed-off-by: Derek Collison <derek@nats.io>
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.
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
In case one creates a server instance with New() and then starts
the http server manually (s.StartHTTPMonitoring()), calling
s.Shutdown() would not stop the http server because Shutdown()
would return without doing anything if `running` was not true.
This boolean was set to true only in `s.Start()`.
Also added StartMonitoring() to perform the options check and
selectively start http or https server to replace individual calls.
This is useful for NATS Streaming server that will now be able
to call s.StartMonitoring() without having to duplicate code
about options checks and http server code.
This is related to PR #481
The tool is started with the "-ignore" flag to ignore warning SA2002
which corresponds to invoking t.Fatalf (and the like) in a go routine.
Calling t.Fatalf in a go routine may produce a race condition.
The rationale for ignoring this warning is that if a test executes
the t.Fatalf() line it is that we have a problem either with test
or code that should be fixed.
