Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ADDED] Publish header "Nats-Expected-Last-Subject-Sequence-Subject" #5281

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

cchamplin
Copy link

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 caleb.champlin@gmail.com


// Constrain the sequence restriction to a specific subject
// e.g. "kv.1.*" for kv.1.foo, kv.1.bar, kv.1.baz; kv.2.* for kv.2.foo, kv.2.baz; kv.3.* for kv.3.bar
filterSubject := fmt.Sprintf("%s.*", subj[:strings.LastIndex(subj, ".")])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test would be a bit more clear if you lifted the matching subject as a parameter. This would also enable expansion for more nested subjects if/when is relevant.

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 nats-io#5280

Signed-off-by: Caleb Champlin <caleb.champlin@gmail.com>
@cchamplin cchamplin force-pushed the cchamplin/NATS-SERVER-5280/expected-last-subject-sequence-subject branch from f5d181d to e9b1b36 Compare April 10, 2024 16:50
@bruth
Copy link
Member

bruth commented Apr 11, 2024

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.

@cchamplin
Copy link
Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow publishers to specify a different subject for "Nats-Expected-Last-Subject-Sequence"
2 participants