[
https://issues.apache.org/jira/browse/AMQ-7144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16759932#comment-16759932
]
Megaraj Mahadikar edited comment on AMQ-7144 at 2/4/19 3:29 PM:
----------------------------------------------------------------
Yes I agree that the thread pool size is unlimited (integer max) and hence if
there is a exhaustion of this pool then there is a genuine problem with the
system. In such cases we must not catch an exception and just propagate the
exception.
Since our application heavily uses activeMQ (we have around 6500-7000
connections be created) there were few problem when the OS thread limit was hit
and hence we had to limit various thread pools in activeMq and one such thread
pool was ASYNC_TASKS used in AbstactInactivityMonitor. With this we started
facing the problems of Timer been canceled and the broker been in inconsistent
state. Hence I think we must revisit this introduction of limit on the thread
pool
was (Author: megarajtm):
Yes I agree that the thread pool size is unlimited (integer max) and hence if
there is a exhaustion of this pool then there is a genuine problem with the
system. In such cases we must not catch an exception and just propagate the
exception.
Since our application heavily uses activeMQ (we have around 6500-7000
connections be created) there were few problem when the OS thread limit was hit
and hence we had to limit various thread pools in activeMq and one such thread
pool was ASYNC_TASKS used in AbstactInactivityMonitor. With this we started
facing the problems of Timer been canceled and the broker been in inconsistent
state.
> Issue with Timer in AbstactInactivityMonitor
> --------------------------------------------
>
> Key: AMQ-7144
> URL: https://issues.apache.org/jira/browse/AMQ-7144
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.x
> Reporter: Megaraj Mahadikar
> Priority: Critical
>
> Hi,
> If there is an exception in the Timers that schedules the write checker or
> read check, then this timer is cancelled (refer the java docs of
> java.util.Timer). As a result of this any new connection to the broker will
> never go through since the same Timer is used again to schedule the write or
> read checker. This issue affects the complete broker and the broker needs to
> be restarted to recover from this issue.
> Ideally any such exceptions within the Timer must be never thrown back which
> causes the Timer to be cancelled.
> Regards,
> Megaraj
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
