Creating a stream will become idempotent, so assuming that we
should try to transfer the old session streams only on success
will no longer work.
Added a test that checks that "stream" list is queried only once
which means transfer was attempted only once after the second
cluster restart and new connection.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
The server will now reject the creation of a push consumer with
flow control if no heartbeat is set.
Resolves#2520
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
When a session record exists and is currently not connected, if
the user reconnects with the same client ID but with now the
clean flag set, we are required to clear the state. In earlier
implementation (where we were using a stream per session), we
were not deleting the stream to be created right away. Since now
we just have a message per session, it is ok to delete that
message when clearing the existing session that is going to be
replaced.
Also made apiDispatch execute in place for any connection that
is not ROUTER or GATEWAY.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Authentication token has never been supported for cluster and
gateway (and leafnode). There is not even a Token option in
ClusterOpts or GatewayOpts.
However, the parsing of the configuration was not rejecting this
misconfiguration, making users believe that token was used for
authentication.
Documentation will also be fixed since it is reported there that
token is supported, which again, has never been the case.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
ClientID has been added to various monitoring objects. Also, added
the ability to filter connections on `client_id`.
On auth violation, the proper code was not invoked, which meant
that no disconnect event (with auth reason) would be published.
Resolves#2270
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
When we triggered a filestore msg block compact we were not properly dealing with interior deletes.
Subsequent lookups past the skipped messages would cause an error and stop delivering messages.
Signed-off-by: Derek Collison <derek@nats.io>
With the availability of a "max message per subject" for a given
stream, it is possible to replace individual streams that were
created per session with a single stream that gets all sessions
as a single message per subject, which subject is composed of
the session client ID hash.
The first time the new stream is created for a given account,
all existing MQTT session streams will be transferred to the
new mux'ed MQTT session stream.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Also if we do not have room trap add peer and process there.
Fixed a bug that would treat ephemerals same as durables during remapping after peer removal.
Signed-off-by: Derek Collison <derek@nats.io>
Under load and pressure from concurrent publishing and consuming with multiple consumers the filestore would
return a partial or no cache error to the upper layers. For consumers this could result in us skipping a stream sequence when we should not.
This change stabilizes the filestore and removes the flush state for msg blocks. I also found some bugs that did not track last sequence properly
after snapshots / restore.
Signed-off-by: Derek Collison <derek@nats.io>
Updated some tests based on this change but also missing defer
connection close or server shutdown.
Fixed how the OCSP run go routine would shutdown, which would
never complete because grWG was not decremented by this go routine
prior to invoking s.Shutdown()
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
The RootCAs was not properly set, which could prevent the server
to create a TLS connection to the account resolver with an error
such as:
```
x509: certificate signed by unknown authority
```
Resolves#1207
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
When expiring requests, the server would send 408 if interest was
still present, which can happen for pull subscribe implementations
that maintain interest for the duration of the pull subscription.
Let's keep the 408 for when a request is "force expired", that
is, a request was removed from the queue because it queue was
full but interest is still found.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
