THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| PlantUML Render Macro | ||
|---|---|---|
| ||
@startuml [*] --> NOT_IN_GROUP Stable : this is a string Stable : this is another string Stable UNJOINED UNJOINED ---> UNJOINED : Heartbeat on retries FATAL StableSTABLE ---> Assigningstate Revoking { R1: entry point into revoking partitions R2: if we have a callback,\nwe need to invoke it R3: after we've made local changes,\nawait heartbeat [*] --> R1 R1 -> R2 R2 -> R3 R1 -> R3 R3 ---> Stable R3 ---> Assigning } state Assigning { A1: entry point into assigning partitions A2: if we have a callback,\nwe need to invoke it A3: after we've made local changes,\nawait heartbeat [*] --> A1 A1 -> A2 A1 -> A3 A2 -> A3 A3 -> Stable } Stable --> Closing Revoking --> Closing Assigning --> Closing Closing --> RECONCILING : new assignment received\ntrigger callbacks RECONCILING ---> RECONCILING : Heartbeat RELEASING_ASSIGNMENT ---> RELEASING_ASSIGNMENT_COMPLETE : 'onLost' callback completed FATAL ---> [*] @enduml |
| Step | Thread | Starting State | Ending State | Notes |
|---|---|---|---|---|
| 1 | Background | Stable | Stable | No new assignments are included in the heartbeat response. |
| 2 | Background | Stable | Updating | When the heartbeat response contains a new assignment, this is passed to the MemberAssignmentReconciler along with the current set of assigned partitions. |
| 3 | Background | Updating | Updating | The MemberAssignmentReconciler will compare the new assignment against the current assignment to determine any newly revoked partitions. |
| 4 | Background | Updating | Revoking via Callback | If there are partitions that need to be revoked and there is a |
| 5 | Background | Updating | Assigning | If there are no partitions to revoke or there is no |
| 6 | Application | Revoking via Callback | Revoking via Callback | When the user next invokes Consumer.poll(), the events from the background event queue will be examined and acted upon. When the RevokePartitionsEvent is processed, the ConsumerRebalanceListener.onPartitionsRevoked() method will be invoked, passing along the partitions contained within the event. |
| 7 | Application | Revoking | Revoking | After onPartitionsRevoked() has been successfully(?) invoked, the Consumer will enqueue a PartitionsRevokedEvent containing the set of partitions that were revoked onto the queue that flows from the application thread back to the background thread. |
| 8 | Background | Revoking | Awaiting Revocation Confirmation | Read the events of the application event queue and invoke the appropriate ApplicationEventProcessor handler for the PartitionsRevokedEvent. This will invoke the MemberAssignmentReconciler.onRevocation() method to update its state. |
| 9 | Background | Awaiting Revocation Confirmation | Awaiting Revocation Confirmation | The |
| 9 | Background | Awaiting Revocation Confirmation | Updating | When the heartbeat response confirms (how?) that the revocation has been acknowledged by the coordinator, we can move to step 2. |
| 10 | Background | Updating | Updating | The MemberAssignmentReconciler will compare the new assignment against the current assignment to determine any newly assigned partition sets. |
| 11 | Background | Updating | Assigning via Callback | If there are partitions that need to be assigned and there is a ConsumerRebalanceListener, the MemberAssignmentReconciler will enqueue an AssignPartitionsEvent containing the set of partitions to assign onto the queue that flows from the background thread to the application thread. |
| 12 | If there are no partitions to assign or there is no ConsumerRebalanceListener, skip to step 1 | |||
| 13 | Application | Assigning via Callback | When the user next invokes Consumer.poll(), the events from the background event queue will be examined and acted upon. When the AssignPartitionsEvent is processed, the ConsumerRebalanceListener's onPartitionsAssigned() method will be invoked, passing along the partitions contained within the event. | |
| 14 | ||||
| 15 | ||||
| 13 | ||||
| 14 | ||||
| 19 |