Make sure the client handshake flag is set when TLS handshake is made as
part of WebSocket connection/upgrade (notionally HTTPS) rather than as
part of the NATS protocol TLS initiation chain. AuthCallout tests the
flag when building the data for the AuthCallout service request.
Added AuthCallout unit test for NATS WS client auth that requires the
TLS data.
Repeated calls to `scheduleSetSourceConsumerRetry` could end up creating
multiple timers for the same source, which would eventually schedule
even more timers, which would result in runaway CPU usage. This PR
instead bounds to one timer per source per stream.
Signed-off-by: Neil Twigg <neil@nats.io>
TestMQTTQoS2RetriesPublish to 100ms, and in TestMQTTQoS2RetriesPubRel to
50ms.
A lesser value caused another PUBLISH to be fired while the test was
still processing the final QoS2 flow. Reduced the number of retries we
wait for to make the test a little quicker.
The reason would be that we were not accounting for gaps as mb.first.seq can move. The behavior should always return a valid index and mb if seq is inclusive of range from first to last.
The panic could orphan held locks for filestore, consumer and possibly stream.
Signed-off-by: Derek Collison <derek@nats.io>
The default timeout for JetStream API calls is 10s, so in the case where
we determine that we are the leader, but the stream info endpoint has
not registered with the server we are connected to, the stream info call
could fail and we would exhaust the whole checkFor since we would stay
in one call for 10s.
Fix is to override and make multiple attempts possible for the checkFor
loops.
Signed-off-by: Derek Collison <derek@nats.io>
The default timeout for JetStream API calls is 10s, so in the case where we determine that we are the leader, but the stream info endpoint has not registered with the server we are connected to, the stream info call could fail and we would exhaust the whole checkFor since we would stay in one call for 10s. Fix is to override and make multiple attempts possible.
Signed-off-by: Derek Collison <derek@nats.io>
TestMQTTQoS2RetriesPublish to 100ms, and in TestMQTTQoS2RetriesPubRel to 50ms.
A lesser value caused another PUBLISH to be fired while the test was still processing the final QoS2 flow. Reduced the number of retries we wait for to make the test a little quicker.
Tracing the connect (ack?) read times in `TestMQTTSubPropagation` showed
that they come in the 2-3s range during normal execution, and it appears
that they occasionally exceed the 4s timeout.
I am not sure exactly why MQTT CONNECT takes such a long time, but as
the name of the test suggests, perhaps it has to do with session
propagation in a cluster.
`TestMQTTQoS2InflightMsgsDeliveredAfterUnsubscribe` was flaky on
TravisCI.
At this point it was there to illustrate a design issue with MQTT 3.1.1
QoS support, and much of it is disabled since it'd be failing anyway.
Disabling the test until it can be _fully_ applicable/enabled.
