Run GetTLSConnectionState on a non-tls connection (in a dedicated test)
and a tls connection.
Because initializing the TLS connection in the tests is non-trivial,
I hijacked the TestTLSCloseClientConnection test.
When a server is told to connect to a server (with auto-discovery),
it tries to connect once. There have been a report where that
connection fails, but would probably succeed if tried again (#408).
This new parameter allows to configure the number of times a failed
implicit connect should be tried.
Resolves#408
The RunServer() function (and the various variants)
call Server.Start() in a go-routine, but do not return until
it has verified that the server is ready to accept connections.
To do so, it use GetListenEndpoint() to get a suitable connect
address (replacing "0.0.0.0" or "::" with localhost - important
on Windows). It then creates a raw TCP connection to ensure the
server is started, repeating the process in case of failure up
to 10 seconds.
This PR replaces this with a function that checks that client
listener, and route listener if configured, are set. This removes
the need to get a connect address and create test tcp connections.
The reason for this change is that NATS Streaming when starting
the NATS Server (unless configured to connect to a remote one)
calls RunServerWithAuth(), which when getting "localhost" from
GetListenEndpoint(), would fail trying to resolve it. This happened
for the NATS Streaming Docker image built with Go 1.7+.
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).
Previous implementations of the server checked the pending data size
being currently buffered for a client to detect slow consumers,
though this does not apply to latest version of the server so removing
it as a config option to avoid confusion as it is not implemented.
Windows has limited support for signals, and does not define syscall.SIGUSR1. Log rotation will be handled differently in windows.
* Add signal.go for all non-windows builds
* Add signal_windows.go for windows builds.
Today, windows looks to be the only platform that does not have syscall.SIGUSR1 defined.
Running `go vet ./...` with `go 1.7.3` would report the following:
```
server/route.go:342: assignment copies lock value to tlsConfig: crypto/tls.Config contains sync.Once contains sync.Mutex
server/server.go:479: assignment copies lock value to config: crypto/tls.Config contains sync.Once contains sync.Mutex
```
Add a “clone” function while waiting for this to be addressed
by the language itself (https://go-review.googlesource.com/#/c/28075/)
In NATS Streaming, we have a test - started early on - that was testing
logging and called SetLogger(l, true, true), then reset by calling
SetLogger(l, false, false) to reset the values. That obviously had not
the expected effect.
During profiling, I noticed that there were tons of allocated
objects due to NATS server debug/trace statements caused by that.
Fixes#304
Changes the non-ASCII curly quotes in the HTML to use the regular ASCII double quotes. Also adds a test to check for the existence of non-ASCII characters in that same HTML.
By default, a server is now sending to its clients the client URLs
of all servers in the cluster. This allows clients to be able
to reconnect to any server in the cluster even if those clients
were not configured with the list of servers in the cluster.
However, there may be cases where it would make sense to disable
this feature. This now can be done with this option/command line
parameter.
Resolves#322
Trying to use IPv6 address for the cluster host would fail.
Also, there were some unclosed channels in case of accept loop
setup failures.
Resolves#323
If the server was started with a cluster section in a configuration
file and one would want to override the routes (using `-routes`) the
server would complain that you need to use `-cluster`. Adding
an override of cluster would not work, server would still complain.
Trying to override simply the cluster listen info (without override
of routes) would also not work.
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.
