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
Nakadi (at least on the staging system at Zalando) now has some rate limiting (via a gateway).
This has the effect that all kinds of calls can get 429 responses with a Retry-After header.
When they happen during a cursor commit, Nakadi-Java just throws them out of the StreamOffsetObserver.onNext() method (see #357).
If those exceptions are caught (as our application is doing right now, apparently), this is just continued with the next messages, resulting in ~25k log lines over 45 seconds, until the rate limit window is over.
Expected behavior
For a 429 response, the Retry-After header is evaluated. After that many seconds, the request is tried again.
The text was updated successfully, but these errors were encountered:
Current behavior
Nakadi (at least on the staging system at Zalando) now has some rate limiting (via a gateway).
This has the effect that all kinds of calls can get 429 responses with a
Retry-After
header.When they happen during a cursor commit, Nakadi-Java just throws them out of the StreamOffsetObserver.onNext() method (see #357).
If those exceptions are caught (as our application is doing right now, apparently), this is just continued with the next messages, resulting in ~25k log lines over 45 seconds, until the rate limit window is over.
Expected behavior
For a 429 response, the
Retry-After
header is evaluated. After that many seconds, the request is tried again.The text was updated successfully, but these errors were encountered: