[
https://issues.apache.org/jira/browse/KAFKA-12156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Bentley updated KAFKA-12156:
--------------------------------
Description:
If users block the response handling thread in one call waiting for the result
of a second "nested" call then the client effectively hangs because the 2nd
call's response will never be processed. For example:
{noformat}
admin.listTopics().names().thenApply(topics -> {
// ... Some code to decide the topicsToCreate based on the topics
admin.createTopics(topicsToCreate).all().get()
return null;
}).get();
{noformat}
The {{createTopics()...get()}} blocks, indefinitely preventing the
{{ListTopics}} response processing from dealing with the {{CreateTopics}}
response.
This can be surprising to users of the Admin API, so we should at least
document that this pattern should not be used.
was:
If users block the response handling thread in one call waiting for the result
of a second "nested" call then the client effectively hangs because the 2nd
call's response will never be processed. For example:
admin.listTopics().names().thenApply(topics -> {
// ... Some code to decide the topicsToCreate based on the topics
admin.createTopics(topicsToCreate).all().get()
return null;
}).get();
The {{createTopics()...get()}} block's indefinitely preventing the
{{ListTopics}} response processing from dealing with the {{CreateTopics}}
response.
This can be surprising to users of the Admin API, so we should at least
document that this pattern should not be used.
> Document consequences of single threaded response handling
> ----------------------------------------------------------
>
> Key: KAFKA-12156
> URL: https://issues.apache.org/jira/browse/KAFKA-12156
> Project: Kafka
> Issue Type: Improvement
> Components: admin
> Reporter: Tom Bentley
> Assignee: Tom Bentley
> Priority: Minor
>
> If users block the response handling thread in one call waiting for the
> result of a second "nested" call then the client effectively hangs because
> the 2nd call's response will never be processed. For example:
> {noformat}
> admin.listTopics().names().thenApply(topics -> {
> // ... Some code to decide the topicsToCreate based on the topics
> admin.createTopics(topicsToCreate).all().get()
> return null;
> }).get();
> {noformat}
> The {{createTopics()...get()}} blocks, indefinitely preventing the
> {{ListTopics}} response processing from dealing with the {{CreateTopics}}
> response.
> This can be surprising to users of the Admin API, so we should at least
> document that this pattern should not be used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
