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>
Use AvailabilityResult.INVALID_SNAPSHOT_HEIGHT instead of AckMessage with error.
Show description in error popup instead of enum name.
Return PRICE_CHECK_FAILED instead of UNKNOWN_FAILURE at error at price check also for non api users.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
This helps to avoid that the legacy BM would get the rest in case there are capped shares.
It still can be that a candidate exceeds the cap and by the adjustment becomes capped. We take that into account and the legacy BM would get some share in that case.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Left side is amount to burn to reach the max allowed receiver share based on the burned amount of all BM.
The right side is the amount to burn to reach the max allowed receiver share based the boosted max burn target.
Increase ISSUANCE_BOOST_FACTOR from 3 to 4.
Add help overlay to burn target table header.
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>
