If a JS API request is received from a non client connection, it
was processed in its own go routine. To reduce the number of
such go routine, we were limiting the number of outstanding routines
to 4096. However, in some situations, it was possible to issue
many requests at the same time that would then cause those requests
to be dropped.
(an example was an MQTT benchmark tool that would create 5000
sessions, each with one QoS1 R1 consumer (with the use of consumer_replicas=1).
On abrupt exit of the tool, the consumers and their sessions needed
to be deleted. Since would cause fast incoming delete consumer requests
which would cause the original code to drop some of them)
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Tests that run on Travis have been split into jobs that run in their own VM in parallel. This reduces the overall running time but also is allowing recycling of a job when we get a flapper as opposed to have to recycle the whole test suite.
JetStream Tests
For JetStream tests, we need to observe a naming convention so that no tests are omitted when running on Travis.
The script runTestsOnTravis.sh will run a given job based on the definition found in ".travis.yml".
As for the naming convention:
All JetStream tests name should start with TestJetStream
Cluster tests should go into jetstream_cluster_test.go and start with TestJetStreamCluster
Super-cluster tests should go into jetstream_super_cluster_test.go and start with TestJetStreamSuperCluster
Not following this convention means that some tests may not be executed on Travis.
4bf81420e2