Handle exception at send #6459
Merged
Handle exception at send #6459
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…call on connection is blocking. This was likely a major bug for seed nodes that at sending hash responses the main thread got blocked. Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
… of the executor in NetworkNode. We use double the maxConnection size for the core size and 4x for the max pool size. Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
…ire a jvm option to allow it. Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
It is more convenient to handle the RejectedExecutionException in the calling code to get more context for error logging. Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
…kingQueue. When ArrayBlockingQueue is used (as in case of using Utilities.getListeningExecutorService) the maxPoolSize has no effect. The pool creates never more threads than the core pool size. Thus we have been limited to 15 threads for message sending and connection creation. This was likely a reason why seed nodes are not accepting new connections if the pool is exhausted. Slow message send can block a thread for 1-3 minutes. Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Make sendMessage package scope to not be used from client code. Remove stacktrace print. The caller in NetworkNode would report a onSuccess in the future callback because we do not escalate the exception but only handle it inside handleException. Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
…r instead. Make executorService protected final Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
… class. Remove torStartupFuture as it was not needed. Make executorService private and add shutdownNow call. Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Wrap nodeAddressProperty.set into UserThread.execute as it is a javafx api. We call startServer also in that execute scope to maintain order of calls. Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Add name param to newCachedThreadPool Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
|
I'd be fine merging this into the release branch and do more extensive release testing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR carries maybe a bit of risk as we did not handle exceptions at send message before. Now the onFailure handler is called. Before the onSuccess was called. There might be some unintended effects from that. If discovered we should fix that as now it uses the correct behaviour.
Based on #6458