feat: Add ReassignmentHandler which is notified on client reassignment#886
Conversation
| * | ||
| * <p>Because of the above, as long as reassignment handling is processed quickly, it can be used to | ||
| * abort outstanding operations on partitions which are being assigned away from this client, or to | ||
| * pre-warm state which will be used by the subscriber handler. |
There was a problem hiding this comment.
Nit: Should we clarify what "subscriber handler" specifically refers to? I was assuming it meant the message receiver function.
|
|
||
| /** | ||
| * A ReassignmentHandler is called any time a new partition assignment is received from the server. | ||
| * It will be called with both the previous and new assignments as decided by the backend. |
There was a problem hiding this comment.
Perhaps also mention that the handler is called after the removed partitions have already been stopped, so subsequent acks/nacks for outstanding messages may be ignored (not 100% sure, but since service shutdown is now async, can we state that they are guaranteed to be ignored?).
Nack was mentioned below, but due to your recent PR, I think it also applies to acks.
There was a problem hiding this comment.
This CL specifically adds fencing for nacks and tests for this behavior. The test case added to SinglePartitionSubscriberTest.java confirms that calling stopAsync is sufficient to fence nacks from having any effect. This is a guarantee that nacks are allowed after shutdown- acks may or may not be processed. The wording specifies "will be" which is equivalent to a guarantee.
There was a problem hiding this comment.
Ah this was asking about future message delivery, will fix before submitting.
There was a problem hiding this comment.
Fixed, we now wait for subscriber shutdown before acknowledging reassignment.
There was a problem hiding this comment.
This now applies to acks as well, added to the comment mentioning them.
This enables clients to respond to a reassignment by cancelling outstanding actions and nacking all messages.
038349a to
be1c041
Compare
🤖 I have created a release \*beep\* \*boop\* --- ## [1.2.0](https://www.github.com/googleapis/java-pubsublite/compare/v1.1.0...v1.2.0) (2021-09-16) ### Features * Add ReassignmentHandler which is notified on client reassignment ([#886](https://www.github.com/googleapis/java-pubsublite/issues/886)) ([5bfef8d](https://www.github.com/googleapis/java-pubsublite/commit/5bfef8d1cc0597f31422b8567de24df09f1936b3)), closes [#869](https://www.github.com/googleapis/java-pubsublite/issues/869) * Batch commit requests ([#883](https://www.github.com/googleapis/java-pubsublite/issues/883)) ([5abd97d](https://www.github.com/googleapis/java-pubsublite/commit/5abd97d20f9e121ff91b5d0a33333585fc5c3790)) ### Dependencies * update dependency com.google.cloud:pubsublite-beam-io to v0.20.0 ([#885](https://www.github.com/googleapis/java-pubsublite/issues/885)) ([66d23e3](https://www.github.com/googleapis/java-pubsublite/commit/66d23e3e2fe7b0926963e231341917f6fd0c311e)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
This enables clients to respond to a reassignment by cancelling outstanding actions and nacking all messages.
Fixes #869