chia7712 commented on PR #17965:
URL: https://github.com/apache/kafka/pull/17965#issuecomment-2509730026
> Thanks for the PR, but for my understanding when can this scenario happen?
We take a lock in the acquire which means a single thread/client can have
access. And acquire method is synchronous update hence state will be fully
transitioned. How do we encounter this issue?
We can observe this scenario by running
`ShareConsumerTest.testExplicitAcknowledgeReleasePollAccept`. This test case
uses `DefaultStatePersister` and produces both leaked
`acquisitionLockTimeoutTask` instance and null `acquisitionLockTimeoutTask`
instance. This explains why `testExplicitAcknowledgeReleasePollAccept` with
`DefaultStatePersister` is slow to close consumer, as the server is unable to
respond due to the NPE.
```
testExplicitAcknowledgeReleasePollAccept(String).persister=org.apache.kafka.server.share.persister.NoOpShareStatePersister
testExplicitAcknowledgeReleasePollAccept(String)[1] 2.220s passed
testExplicitAcknowledgeReleasePollAccept(String).persister=org.apache.kafka.server.share.persister.DefaultStatePersister
testExplicitAcknowledgeReleasePollAccept(String)[2] 37.992s passed
...
[2024-12-01 19:45:47,417] WARN [ShareConsumer clientId=consumer-group1-4,
groupId=group1] Consumer triggered an unsubscribe event to leave the group but
couldn't complete it within 30000 ms. It will proceed to close.
(org.apache.kafka.clients.consumer.internals.ShareConsumerImpl:889)
```
--
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]
