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] Paging subjects in stream info #1517
Conversation
Signed-off-by: Piotr Piotrowski <piotr@synadia.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some comments regarding efficiency and API.
jetstream/stream.go
Outdated
offset = len(subjectMap) | ||
} | ||
if total == 0 || total <= offset { | ||
resp.StreamInfo.State.Subjects = subjectMap |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should store all the subjects in the cached info, as this might really grow with time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, I agree, that might be too much, I'll leave the cached info without the subjects
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
possibly if they asked for it, you can save it on the cache, but if the next info doesn't require that, simply replace
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed caching subjects map
jetstream/stream.go
Outdated
|
||
return resp.StreamInfo, nil | ||
return s.info, nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we consider iterator API for receiving those subjects to avoid allocating a big map?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would change the API - and require someone to page it manually - the big map is going to be large, but that in the end is what they asked for if they did a ">" - remember that request is always specifying a subject filter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tend to agree, I'm not sure how much do we really need an additional API for that, considering that you do specify the filter. I would probably leave it as it is.
Signed-off-by: Piotr Piotrowski <piotr@synadia.com>
Signed-off-by: Piotr Piotrowski <piotr@synadia.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
This functionality has been available in legacy API but not in the new one. It addresses nats-io/nats-architecture-and-design#153
Signed-off-by: Piotr Piotrowski piotr@synadia.com