I had encountered an unexpected behavior. NATS connection provided via StanOptions.NatsConn is closed by STAN Connection constructor if the NATSTimeoutException is thrown during ConnectRequest. It can be easily reproduced by using wrong (non-matching) cluster ID. It may also happen when NATS server is already started but NATS.Streaming server is still starting and misses the connection request.
There are only 3 occurrences of calls to close the underlying NATS conneciton.
Two of them are behind if (ncOwned) condition. Only this one doesn't check if the connection is owned or not.
Here is the code causing the issue:
Msg cr;
try
{
cr = nc.Request(discoverSubject,
ProtocolSerializer.marshal(req),
opts.ConnectTimeout);
}
catch (NATSTimeoutException)
{
protoUnsubscribe();
nc?.Close();
nc?.Dispose();
throw new StanConnectRequestTimeoutException(
string.Format("No response from a streaming server with a cluster ID of '{0}'", stanClusterID));
}
I had encountered an unexpected behavior. NATS connection provided via
StanOptions.NatsConn
is closed by STANConnection
constructor if theNATSTimeoutException
is thrown duringConnectRequest
. It can be easily reproduced by using wrong (non-matching) cluster ID. It may also happen when NATS server is already started but NATS.Streaming server is still starting and misses the connection request.There are only 3 occurrences of calls to close the underlying NATS conneciton. Two of them are behind
if (ncOwned)
condition. Only this one doesn't check if the connection is owned or not.Here is the code causing the issue:
I will submit PR fixing this.