Kafka
  1. Kafka
  2. KAFKA-345

Add a listener to ZookeeperConsumerConnector to get notified on rebalance events

    Details

    • Type: Improvement Improvement
    • Status: Patch Available
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 0.7, 0.8.0
    • Fix Version/s: None
    • Component/s: core
    • Labels:
      None

      Description

      A sample use-case

      In our scenario we partition events by userid and then apply these to some kind of state machine, that modifies the actual state of a user. So events trigger state transitions. In order to avoid the need of loading user's state upon each event processed, we cache that. But if a user's partition is moved to another consumer and then back to the previous consumer we have stale caches and hell breaks loose. I guess the same kind of problem occurs in other scenarios like counting numbers by user, too.

      1. KAFKA-345.patch
        11 kB
        Peter Romianowski

        Issue Links

          Activity

          Gavin made changes -
          Link This issue is depended upon by KAFKA-346 [ KAFKA-346 ]
          Gavin made changes -
          Link This issue blocks KAFKA-346 [ KAFKA-346 ]
          Peter Romianowski made changes -
          Link This issue blocks KAFKA-346 [ KAFKA-346 ]
          Peter Romianowski made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]
          Peter Romianowski made changes -
          Attachment KAFKA-345.patch [ 12528065 ]
          Peter Romianowski made changes -
          Description h1. A sample use-case

          In our scenario we partition events by userid and then apply these to some kind of state machine, that modifies the actual state of a user. So events trigger state transitions. In order to avoid the need of loading user's state upon each event processed, we cache that. But if a user's partition is moved to another consumer and then back to the previous consumer we have stale caches and hell breaks loose. I guess the same kind of problem occurs in other scenarios like counting numbers by user, too.
          A sample use-case

          In our scenario we partition events by userid and then apply these to some kind of state machine, that modifies the actual state of a user. So events trigger state transitions. In order to avoid the need of loading user's state upon each event processed, we cache that. But if a user's partition is moved to another consumer and then back to the previous consumer we have stale caches and hell breaks loose. I guess the same kind of problem occurs in other scenarios like counting numbers by user, too.
          Peter Romianowski made changes -
          Field Original Value New Value
          Description h1. A sample use-case

          In our scenario we partition events by userid and then apply these to some kind of state machine, that modifies the actual state of a user. So events trigger state transitions. In order to avoid the need of loading user's state upon each event processed, we cache that. But if a user's partition is moved to another consumer and then back to the previous consumer we have stale caches and hell breaks loose. I guess the same kind of problem occurs in other scenarios like counting numbers by user, too.
          Peter Romianowski created issue -

            People

            • Assignee:
              Unassigned
              Reporter:
              Peter Romianowski
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Development