Only works for gateways and routes. When true the subject alt DNS name
must match one url in the corresponding configuration
Signed-off-by: Matthias Hanel <mh@synadia.com>
Allow an API endpoint and public API to lookup a stream by subject. The subject needs to be an exact match or a subset. If the subject is considered a filtered subject for the stream that will also be returned.
Signed-off-by: Derek Collison <derek@nats.io>
We would release locks and call into upper layers when removing a message. The upper layers may call back into the lower layers to get more information, such as the subject.
This fix has the storage updates optionally supply the subject for filtered consumers and fixes the bug of double deletes.
Signed-off-by: Derek Collison <derek@nats.io>
In preparation for clustering we need to have the consumer filestore update state with deltas vs original design.
Signed-off-by: Derek Collison <derek@nats.io>
When we moved to a write through cache architecture we also moved the cache write to offset based instead of APPEND.
We were inadvertently clearing our offset from our cache when we would clear which meant if the next operation was another write we would have the wrong offset and overwrite previous messages.
Signed-off-by: Derek Collison <derek@nats.io>
The original design had a shared filestore write buffer and individual message blocks had a read cache.
This presented some performance and stability issues when lots of reads and deletes were happening to a
message block that was also being written to actively.
This change eliminates the shared write buffer and uses the message block's cache as a write through as
well as read cache and handles partials correctly.
Signed-off-by: Derek Collison <derek@nats.io>
This will track the stream pending state for each consumer.
This code does account for filtered consumers.
Signed-off-by: Derek Collison <derek@nats.io>
Addresses stack overflow issue wally was seeing with configs
that mix and match streams and services between each other.
Signed-off-by: Derek Collison <derek@nats.io>
When creating shadow subscriptions for import streams, we were
not invoking code for gateway subscription accounting, which means
that when the account (for leafnodes) was switched to interest
only, those shadow subscriptions were not sent.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
- 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>
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>
