[
https://issues.apache.org/jira/browse/JAMES-3803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17578485#comment-17578485
]
Benoit Tellier commented on JAMES-3803:
---------------------------------------
Looks great to me.
I would be interested if you coud share a thread dump of when this issue
occurs... (jmap command?)
I did succeed to reproduce it the hacky way (putting a sleep in
DeliveryRunnable) and send 400 emails to a remote server in an integration
test. I confirm ActiveMQ queue implementation is impacted, but not the memory
one and not the RabbitMQ one. I also confirm that the fix solves the issue.
Tomorrow, I will be looking at adapting the mock-smtp-server sub-project
(https://github.com/apache/james-project/tree/master/server/mailet/mock-smtp-server)
in order to inject this delayon the remote SMTP server side and come up with a
robust integration test suite for remote delivery for existing packaging,
including a non-regression test for this very issue.
> DeliveryRunnable blocks email in BoundedElasticScheduler-queue if running out
> of threads
> ----------------------------------------------------------------------------------------
>
> Key: JAMES-3803
> URL: https://issues.apache.org/jira/browse/JAMES-3803
> Project: James Server
> Issue Type: Bug
> Components: Remote Delivery
> Affects Versions: 3.7.0, 3.8.0
> Reporter: Adrian Bucher
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The DeliveryRunnable does use the same BoundedElasticScheduler (ThreadPool)
> for dequeuing the messages (long running thread), and processing (delivering)
> them, if lots of messages are dequeued and the BoundedElasticScheduler starts
> to queue them, the one queueing behind the dequeuing - long running thread
> are never processed nor delivered.
>
> Messages are still visible in the embedded activemq delivery queues, a
> restart of the james will process them, as they will be reacknoledged by the
> dequeuer.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
