Palaiologos1453 commented on issue #10983: URL: https://github.com/apache/rocketmq/issues/10983#issuecomment-5558231311
We would like to help implement this for long-running Agent sessions. Before opening a code PR, could maintainers confirm the protocol direction? A minimal design we suggest is an atomic broker-side operation scoped to (parentTopic, liteTopic, consumerGroup): 1. Under the broker's LiteTopic/consumer-offset lock, record a cancellation boundary at the current LMQ max offset. 2. Advance the group's LMQ consume offset to that boundary, so messages accepted before the boundary are skipped. 3. Publish one durable control message carrying a client-supplied requestId and cancellation payload. 4. Deliver that control message as the next relevant message. Messages accepted after the boundary remain available. 5. Treat requestId as idempotency key and persist enough state for retry, failover, and resubscription. The operation must not revoke an already popped message; the control message only asks the Agent runtime to stop its active work. This likely needs an additive RPC in apache/rocketmq-apis plus broker/proxy implementation. We would prefer a first version that targets one LiteTopic and one consumer group, with no changes to normal topics or priority-message semantics. If this direction is acceptable, we can prepare the API proposal/RIP and a draft implementation with broker unit tests. In particular, please advise whether the control message should be a normal LiteTopic message with a reserved command field, or a dedicated control lane in the LiteTopic protocol. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
