nats-server
nats-server copied to clipboard
nats-io
[ADDED] Publish header "Nats-Expected-Last-Subject-Sequence-Subject"
This change adds a new header "Nats-Expected-Last-Subject-Sequence-Subject" when when paired with "Nats-Expected-Last-Subject-Sequence" allows publishers to customize the subject used when the server enforces "Nats-Expected-Last-Subject-Sequence". Publishers can specify a alternative subject to be used that includes wildcards.
Resolves #5280
Signed-off-by: Caleb Champlin [email protected]
Use case aside, the one concern I have is that LoadLastMsg is not nearly as optimized with a pattern as it is with a concrete subject. This is already known as a less optimized access pattern and it will be another use case to drive that improvement forward.
The question is whether this lands and the latency is not to folks expectations. @cchamplin Have you created a realistic app/test case against this to assess if the writes/second are sufficient for your needs?
I did some raw benchmarking against the filestore API to assess, but will want to try it out in a more practical test case.
@bruth We have not created the type of test case you described. We aren't quite mature enough yet to know if this will negatively impact our performance in a way that matters, we suspect not, we don't have that many subjects that would be matched by our sequence subject pattern. Ultimately though we'd be willing to take a minor performance hit on publishing to unlock this functionality, especially if it's something that could be optimized in the future.
@neilalexander @ripienaar I advocate for this coming into 2.11. There is no new risk. For those who use it, the performance profile would be equivalent to any other code path that hits LoadLastMsg with a wildcard which is generally known to need improvement in the extreme cases.
All that said, would like to hear your thoughts.
