Historically we kept indexing information, either by sequence or by
subject, as a per msg block operation. These were the "*.idx" and
"*.fss" indexing files. When streams became very large this could have
an impact on recovery time. Also, for encryption the fast path for
determining if the indexing was current would require loading and
decrypting the complete block.
This design moves to a more traditional WAL and snapshot approach. The
snapshots for the complete stream, including summary information, global
per subject information maps (PSIM) and per msg block details including
summary and dmap, are processed asynchronously. The snapshot includes
the msg block and has for the last record hash that was considered in
the snapshot. On recovery the snapshot is read and processed and any
additional records past the point of the snapshot itself are processed.
To this end, any non-system removal of a message has to be expressed as
a delete tombstone that is always added the the fs.lmb file. These are
processed on recovery and our indexing layer knows to skip them.
Changing to this method drastically improves startup and recovery times,
and has simplified the code. Some normal performance benefits have been
seen as well.
Signed-off-by: Derek Collison <derek@nats.io>
Historically we kept indexing information, either by sequence or by subject, as a per msg block operation. These were the "*.idx" and "*.fss" indexing files. When streams became very large this could have an impact on recovery time. Also, for encryption the fast path for determining if the indexing was current would require loading and decrypting the complete block.
This design moves to a more traditional WAL and snapshot approach. The snapshots for the complete stream, including sumary information, global per subject information maps (PSIM) and per msg block details including summary and dmap, are processed asynchronously. The snapshot includes the msh block and has for the last record considered in the snapshot. On recovery the snapshot is read and processed and any additional records past the point of the snapshot itself are processed. To this end, any removal of a message has to be expressed as a delete tombstone that is always added the the fs.lmb file. These are processed on recovery and our indexing layer knows to skip them.
Changing to this method drastically improves startup and recovery times, and has simplified the code. Some normal performance benefits have been seen as well.
Signed-off-by: Derek Collison <derek@nats.io>
We were not recalculating first correctly since we were not considering
seq < mb.first.seq.
Signed-off-by: Derek Collison <derek@nats.io>
Resolves#4445
As per specification MQTT-3.3.1-8, we are now setting the RETAIN flag
when delivering to new subscriptions and clear the flag in all other
conditions.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
As per specification MQTT-3.3.1-8, we are now setting the RETAIN
flag when delivering to new subscriptions and clear the flag in
all other conditions.
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
(Partially?) addresses
https://github.com/nats-io/nats-server/pull/4349#discussion_r1306576048
@kozlovic @neilalexander I did not remove the use of `domainTk` in the
session subject since it seems to have significance to it; removing it
failed `TestMQTTSessionsDifferentDomains` and I did not understand the
specifics of the issue enough. Please let me know your thoughts.
In +Go 1.20, the `x509.HostnameError` changed to be wrapped in a
[tls.CertificateVerificationError](https://pkg.go.dev/crypto/tls#CertificateVerificationError)
so sometimes the name would not be reset causing tests to be extra
flaky.
In +Go 1.20, the x509.HostnameError changed to be wrapped in a
tls.CertificateVerificationError so sometimes the name would not
be reset causing tests to be extra flaky.
Signed-off-by: Waldemar Quevedo <wally@nats.io>
- [x] Link to issue, e.g. `Resolves #NNN`
- [ ] Documentation added (if applicable)
- [x] Tests added
- [ ] Branch rebased on top of current main (`git pull --rebase origin
main`)
- [ ] Changes squashed to a single commit (described
[here](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
- [ ] Build is green in Travis CI
- [x] You have certified that the contribution is your original work and
that you license the work to the project under the [Apache 2
license](https://github.com/nats-io/nats-server/blob/main/LICENSE)
Resolves#4422
### Changes proposed in this pull request:
- Added `Access-Control-Allow-Origin` header to allow CORS requests for
the monitoring server
- Added a check in the tests for the header when the `Content-Type` is
`application/json`
While shutting down a server an error during purge from a memory stream
would cause a deadlock sometimes, this would sometimes show up in the
`TestJetStreamClusterMemLeaderRestart` while tearing down the cluster.
This was introduced in
4d8d01949b
so only relates to v2.10.
While shutting down a server an error during purge from a memory stream
would cause a deadlock sometimes, this would sometimes show up in the
TestJetStreamClusterMemLeaderRestart while tearing down the cluster.
Signed-off-by: Waldemar Quevedo <wally@nats.io>
When a consumer reached a max delivered condition, we did not properly
synchronize the state such that on a restore or leader switch the ack
pending could jump and be higher than max ack pending and block the
consumer.
This propagates a delivered update and we updated the store state engine
to do the right thing when the condition is reached.
Signed-off-by: Derek Collison <derek@nats.io>
This propagates a delivered update and we updated the store state engine to do the right thing when the condition is reached.
Signed-off-by: Derek Collison <derek@nats.io>
