The broadcasting consumes most of the threads but has lower priority than other messages being sent.
By separating that thread pool from the common sendMessage executor we can reduce the risk that a burst of
broadcasts exhausts the thread pool and might drop send message tasks.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
The previously used newCachedThreadPool carries higher risk for execution exceptions if exceeded.
Originally we had only one executor with a corePoolSize of 15 and a maximumPoolSize of 30 and queueCapacity was set to maximumPoolSize.
This was risky when the 15 corePool threads have been busy and new messages or connection creation threads are
queued up with potentially significant delay until getting served leading to timeouts.
Now we use (if maxConnections is 12) corePoolSize of 24, maximumPoolSize 36 and queueCapacity 10. This gives
considerable headroom. We also have split up the executors in 2 distinct ones.
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>
Remove torStartupFuture as it was not needed.
Make executorService private and add shutdownNow call.
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>
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>
I want to avoid to risk changes with not calling error handlers/listeners in those cases
as not 100% sure if that could have unintended effects.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Rename to expectedInitialDataResponses as we compare with numInitialDataResponses.
Add comment to make it more clear how its used.
Let the LiteNode increment only if getBlocks get called (e.g. blocks are missing).
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
logging of: `The requester had version x.x.x. Our historical data
store has version y.y.y As the requester version is not older as our
historical store we do not add the data to the result map.`
Which takes up many screenfuls of log for every client getDataRequest.
