- Fix for updating delivery subject and adjusting next delivery sequences.
- When acking explicitly but out of order, need to make sure we set floor correctly.
- Only update ack floors on an ack if the message is present.
- Fix for needAck for explicitAck out of order consumers detecting if message has been acked.
- Fix for race not locking stream when checking interest during stop.
- Fix for filestore determing if a message block still has a message. Added check to first sequence as well as cache.
- Some additions to the original test.
Signed-off-by: Derek Collison <derek@nats.io>
The test shows the issue.
It seems that Consumer.needAck() for AckExplicit should consider
that an Ack is needed if sseq > o.asflr and there is no pending
ack at all. However making this change would break the test
TestJetStreamInterestRetentionStream.
Also, running the new test with `-count 100` and by adding an
artificial delay in stream.ackMsg() (just before calling
mset.store.RemoveMsg(seq)) causes sometimes delete requests
for the same sequence to be processed twice, which causes
the new test to fail (even with an attempted fix as discussed
above). I think that the attempt to remove the same sequence twice
is messing up the state.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
This test has been found to cause TestAccountNATSResolverFetch to
fail on macOS. We did not find the exact reason yet, but it seem
that with `-race`, the queue auto-unsub test (that creates 2,000
queue subs and sends 1,000 messages) cause mem to grow to 256MB
(which we know -race is memory hungry) and that may be causing
interactions with the account resolver test.
For now, moving it to norace_test.go, which consumes much less
memory (25MB) and anyway is a better place since it would stress
better the "races" of having a queue sub being unsubscribed while
messages were inflight to this queue sub.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Full nats based resolver sync within a cluster.
This functionality addresses syncing between cluster.
Fixing deadlock when more than one server responds to lookup.
Fixing crash when shutdown and pack happen at the same time.
The panic was caused by the closing of an already closed Go channel.
The Delete() relied on the consumer's mset being nil to consider
the consumer already closed. However, the consumer's mset is set
to nil after invoking sendDeleteAdvisoryLocked() which internally
invokes sendAdvisory() which releases/reacquires the consumer lock.
This left an open door for a race to occur and Delete() to be
invoked twice on the same consumer.
Moving setting the consumer's mset to nil too early would prevent
the sendAdvisory() to actually do its job. We could pass the mset
to sendAvisory(), but a simpler approach is to simply use a "closed"
boolean on the Consumer object that is set to true at the beginning
of the Delete() function.
Resolves#1621
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
It seems that when updating the delivery subject, we use as the
first sequence the ack floor, but if no message was ever ack'ed
then it causes the first message to be redelivered twice.
Resolves#1619
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Noticed TestSystemAccountConnectionUpdatesStopAfterNoLocal failing
du to the timer still being around.
To avoid one event interfering with antoher, holding the account lock
during send seems the most appropriate solution.
sendInternalMsg essentially records the send queue and unlocks the server.
This change just merges that with the code in sendAccConnsUpdate.
Signed-off-by: Matthias Hanel <mh@synadia.com>
The connection count sent and the connection count used to determine if
the timer should be disabled could differ.
Also fixed issues in unit test triggering this behavior.
It did not check if remote connections where set to 0 prior to doing
more tests.
Fixes#1613
Signed-off-by: Matthias Hanel <mh@synadia.com>
Returned imports/exports are formated like jwt exports imports, even if
they originating account is from config.
Fixes#1604
Signed-off-by: Matthias Hanel <mh@synadia.com>
If the soliciting side detects the disconnect and attempts to
reconnect but the accepting side did not yet close the connection,
a "loop detected" error would be reported and the soliciting server
would not try to reconnect for 30 seconds.
Made a change so that the accepting server checks for existing
leafnode connection for the same server and same account, and if
it is found, close the "old" connection so it is replaced by
the "new" one.
Resolves#1606
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Old $SYS.ACCOUNT.%s.CLAIMS.UPDATE is keept for backwards compatibility.
The old name is in the same name space as events.
To be able to abuse this, an attacker needs to be in possession of the
operator key as well.
Signed-off-by: Matthias Hanel <mh@synadia.com>
This causes nil messages mid content stream and is confusing,
the test for this is amended to test the content received for
validity - where previously the test assumed any content is
good content but in fact it only received half the content.
Removing this behaviour until we can design this properly
Signed-off-by: R.I.Pienaar <rip@devco.net>
This fits better with similar events
New subject is $SYS.ACCOUNT.%s.SERVER.CONNS
Old subject remains for backwards compatibiliby
Signed-off-by: Matthias Hanel <mh@synadia.com>
Users and NKey users will now have the option to specify a list
of allowed connection types.
This will allow for instance a certain user to be allowed to
connect as a standard NATS client, but not as Websocket, or
vice-versa.
This also fixes the websocket auth override. Indeed, with
the original behavior, the websocket users would have been bound
to $G, which would not work when there are accounts defined, since
when that is the case, no app can connect/bind to $G account.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
