You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Stream info requests can now result in paginated responses. The pagination is will trigger if the request includes a subjects_filter, which would include more than 100,000 subject entries in the response. As with other paginated responses, the server will set total, offset, and limit in the response where:
total is the length of the dataset
offset is the index of the current row where the server started sending data for the request
limit is the server set limit on the length of the data set that it will return in a single response.
Note that, unlike other responses, this is still a StreamInfo response, the paged data is the StreamInfo.state.subjects.
To handle the paging, the client can compare the total and limit fields and keep track of all the totals seen. It could also count the number of entries in the subjects map for each request until it accounts for at least the total number of entries. Note that total could change (increase or decrease) if subjects are added or deleted, so the client should update the value returned by the server with each page request.
Also, note that each request is a complete StreamInfo request, only the subject information is paged. The client should return the body of the StreamInfo read from the last paged response after aggregating all the subjects entries in this last response to include all values read by the previous pagination requests.
Client authors please update with your progress. If you open issues in your own repositories as a result of this request, please link them to this one by pasting the issue URL in a comment or main issue description.
The text was updated successfully, but these errors were encountered:
When the option jsOptions.Stream.Info.SubjectsFilter is specified,
the js_GetStreamInfo() would collect the subjects for the stream
and return them in si->State.Subjects. However, the server had
a 100,000 limit. Since server v2.9.0, pagination is supported
therefore this call is going to under the cover get the info
until all pages have been collected.
Related to nats-io/nats-architecture-and-design#153
Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Overview
Stream info requests can now result in paginated responses. The pagination is will trigger if the request includes a
subjects_filter
, which would include more than 100,000 subject entries in the response. As with other paginated responses, the server will settotal
,offset
, andlimit
in the response where:total
is the length of the datasetoffset
is the index of the current row where the server started sending data for the requestlimit
is the server set limit on the length of the data set that it will return in a single response.Note that, unlike other responses, this is still a
StreamInfo
response, the paged data is theStreamInfo.state.subjects
.To handle the paging, the client can compare the
total
andlimit
fields and keep track of all the totals seen. It could also count the number of entries in thesubjects
map for each request until it accounts for at least thetotal
number of entries. Note thattotal
could change (increase or decrease) if subjects are added or deleted, so the client should update the value returned by the server with each page request.Also, note that each request is a complete
StreamInfo
request, only the subject information is paged. The client should return the body of theStreamInfo
read from the last paged response after aggregating all thesubjects
entries in this last response to include all values read by the previous pagination requests.Clients and Tools
Other Tasks
Implemented
Client authors please update with your progress. If you open issues in your own repositories as a result of this request, please link them to this one by pasting the issue URL in a comment or main issue description.
The text was updated successfully, but these errors were encountered: