[
https://issues.apache.org/jira/browse/AMQ-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494954#comment-16494954
]
Gary Tully commented on AMQ-6979:
---------------------------------
I had a quick peek at giving the existing TimerThread based scheduler a pool
via ScheduledThreadPoolExecutor but b/c that pool is fixed, it still can have
the same problem and changing that implementation detail may have more
unintentional side effects.
The solution is to keep the scheduler task short lived, in the case of expiry
processing - treat it as a signal generator.
> consumer message pull timeout being effected by long running scheduled tasks
> ----------------------------------------------------------------------------
>
> Key: AMQ-6979
> URL: https://issues.apache.org/jira/browse/AMQ-6979
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client, Message Store
> Affects Versions: 5.15.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Priority: Major
> Fix For: 5.16.0
>
>
> The messagePull timeout, used for prefetch=0 consumers with
> consumer.receive(timeout) is not reliable in the event that the broker
> scheduler timer task is busy with long running tasks.
> If an existing task exceeds the timeout then the pull response is delayed.
> In the main, scheduled tasks should be short lived and in the case of message
> expiry processing for topic durable subs, they may not be, depending on the
> amount of durable subs and their backlog.
>
> The expiryProcessing scheduler task should simply signal the start of the
> task such that it can return and leave the real work to the taskExecutor
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
