dongyikuan919 commented on issue #10375: URL: https://github.com/apache/rocketmq/issues/10375#issuecomment-4534400676
The root cause makes sense to me. The suspicious part is that `flush(ConsumeQueueInterface, int)` receives a concrete queue instance, but then turns around and calls `getLifeCycle(topic, queueId)`, whose implementation has create semantics through `findOrCreateConsumeQueue`. For a delete/flush race, a flush path should probably not be allowed to resurrect metadata that has already been removed by `deleteTopic`. Two possible boundaries seem worth separating: 1. normal append/read paths may use `findOrCreateConsumeQueue` because creation is expected there; 2. maintenance paths like flush/destroy/checkpoint should use lookup-only semantics, or operate on the instance already captured by the iterator. A regression test could make this deterministic by pausing the flush thread after it has captured the old `ConsumeQueueInterface`, then completing `deleteTopic`, and finally resuming `flush`. The assertion should be that `consumeQueueTable` does not contain the deleted topic after flush returns. I would lean toward avoiding `findOrCreateConsumeQueue` in the flush path rather than adding a special deleted-topic flag, because the former keeps create semantics out of a maintenance operation. -- 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]
