Wait for the async broker port listener close operations to complete at shutdown - #9308
Conversation
|
/pulsarbot run-failure-checks |
3 similar comments
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
f43e286 to
0714b29
Compare
|
@merlimat I have revisited the solution by adding closeAsync methods so that it's possible to wait for shutdown using the existing |
|
/pulsarbot run-failure-checks |
0714b29 to
2faceb6
Compare
|
@eolivelli I have made the change to closeAsync so that it doesn't throw checked exceptions. I took another look at MessagingServiceShutdownHook logic and unfortunately I didn't find a way to simplify the logic. There the intention is to run the shutdown in a background thread so that the actual shutdown can continue if the shutdown takes longer than the timeout. Although the code might look bad, there isn't a real alternative. Catching Exceptions is necessary to catch also possible runtime exceptions that could happen at shutdown. You can try to suggest a better way, I tried and simply didn't find one. :) |
|
/pulsarbot run-failure-checks |
3 similar comments
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
|
/pulsarbot run-failure-checks |
- add BrokerService.closeAsync and PulsarService.closeAsync so that shutdown can handle asynchronous closing operations
- address review comment
2faceb6 to
81b5945
Compare
|
/pulsarbot run-failure-checks |
|
@merlimat Please review this PR since it has changed since you approved it. |
merlimat
left a comment
There was a problem hiding this comment.
Looks good. Just a couple of comments
Catching RuntimeExceptions isn't sufficient since checked exceptions can be thrown in the JVM with solutions like "sneaky throws" This reverts commit 01b5f6f.
|
/pulsarbot run-failure-checks |
|
@sijie @merlimat I have continued the work started in this PR in another PR . Please review #10199 since it will also help improve CI stability when the asynchronous tasks of broker shutdown can be controlled in tests. This prevents problems which are caused by too many brokers being active at the same time. This could currently happen when previous brokers are asynchronously shutting down. |
Motivation
The main motivation for making this change to shut down port listeners synchronously in
BrokerService.closeis to reduce test flakiness.While investigating the flaky test MessageIdTest, these type of exceptions were seen in logs:
It seems that this problem could occur when the test code is able to access the broker instance that is already terminated.
Modifications
To understand the modifications:
The original solution was to wait up to 10 seconds until the port listeners were closed.
A change was requested to add a new setting for this. After adding this, another change was requested to combine these operations in a way that the existing
brokerShutdownTimeoutMssetting would also apply to the closing of the port listeners.This solution for this adds BrokerService.closeAsync and PulsarService.closeAsync methods so that it's possible to combine the closing of the ports to the close operation that uses
brokerShutdownTimeoutMssetting.