[
https://issues.apache.org/jira/browse/QPID-7819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16044277#comment-16044277
]
Rob Godfrey commented on QPID-7819:
-----------------------------------
Is the number of available processors really the right metric? I'm not sure
that store recovery is necessarily CPU intensive - what we actually want to
achieve is that all queues are recovering concurrently rather than some queues
are blocking others. I think if you want to limit the number of executors it
would make sense to change the processing logic such that the work is chunked
up, so recovering of one queue is interleaved with another.
> [Java Broker] The executor in asynchronous store recoverer is effectively
> unbounded and might cause running out of threads
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-7819
> URL: https://issues.apache.org/jira/browse/QPID-7819
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: 0.32, qpid-java-6.0.7, qpid-java-6.1.3
> Reporter: Alex Rudyy
>
> The executor service used in asynchronous message store recoverer is bounded
> by {{Integer.MAX_VALUE}}. On brokers with thousands of queues and low max
> process limit (imposed by OS), it might cause Broker to run out of threads. I
> think we should bound the maximum number of threads by number of available
> processors.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
