You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Matt Pryor <pr...@international-presence.com> on 2025/08/01 09:59:50 UTC
Long delays between spooling and delivering
Hi, I'm running Apache James 3.82.
I'm seeing long delays between spooling messages and then delivering them.
For example:
2025-08-01 04:22:22.253 [DEBUG] o.a.j.m.i.JamesMailSpooler - ==== End
processing mail
Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-to-xxxxx.com ====
And then.... 2025-08-01 04:41:00.785 [DEBUG]
o.a.j.t.m.r.d.DeliveryRunnable - will process mail
Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-to-xxxxx.com
What could be the cause of this I wonder? The server doesn't seem massively
busy in between those times.
I upgraded from 3.80 to 3.82 in the hope this would fix the problem but it
doesn't seem to have.
Kind regards
Matt Pryor
Research and Development Manager
The International Presence Group of Companies
EMAIL: pryor@presencebpm.com
URL: www.International-presence.com
Re: Long delays between spooling and delivering
Posted by Matt Pryor <pr...@international-presence.com>.
Hi Quan and anyone else interested
I tracked this down to issues with JVM heap space and a generally
overworked server.
Once I persuaded the customer to add another 8 Gb RAM to the VM, the
problem seems to have gone away (not wanting to tempt fate!).
Kind regards
Matt Pryor
Research and Development Manager
The International Presence Group of Companies
EMAIL: pryor@presencebpm.com
URL: www.International-presence.com
On Mon, 4 Aug 2025 at 11:23, Matt Pryor <pr...@international-presence.com>
wrote:
> Hi Quan
>
> Yes I agree it's the default date when messages are first added to the
> sendQueue, but to my mind that should trigger immediate processing to
> MailDelivrerToHost, whereas these messages were sat with that timestamp for
> over 48 hours.
> When messages are retried the next delivery date gets updated to the next
> try time, so they weren't in retry state.
> Restarting the server caused them to be dequeued and delivered immediately.
>
> My RemoteDelivery mailet config below.
>
> <processor state="relay" enableJmx="true">
> <mailet match="All" class="RemoteDelivery">
> <outgoingQueue>outgoing</outgoingQueue>
> <delayTime>
> 1*10 minute,
> 2*30 minute,
> 4*1 hour,
> 8*2 hour,
> 4*6 hour
> </delayTime>
> <maxRetries>20</maxRetries>
> <maxDnsProblemRetries>5</maxDnsProblemRetries>
> <deliveryThreads>20</deliveryThreads>
> <sendpartial>true</sendpartial>
> <bounceProcessor>bounces</bounceProcessor>
> <debug>true</debug>
> <startTLS>true</startTLS> <!-- added by MP 2025-07-17-->
> <mail.smtp.starttls.required>false</mail.smtp.starttls.required>
> <mail.smtp.ssl.protocols>TLSv1.3 TLSv1.2 TLSv1.1 TLSv1 SSLv3
> SSLv2Hello</mail.smtp.ssl.protocols>
>
> </mailet>
> </processor>
>
>
> Kind regards
> Matt Pryor
> Research and Development Manager
>
> The International Presence Group of Companies
> EMAIL: pryor@presencebpm.com
> URL: www.International-presence.com
>
>
>
>
> On Mon, 4 Aug 2025 at 11:03, Quan tran hong <qu...@gmail.com>
> wrote:
>
>> Hi,
>>
>> IMO, there is nothing harmful about the delivery date of 1969.
>>
>> I guess you get it from the mail queue route. It was likely the result
>> of Unix epoch plus -1 millisecond (the -1 default delay, which means
>> there
>> is no delay) cf
>>
>> https://github.com/apache/james-project/blob/master/server/queue/queue-jms/src/main/java/org/apache/james/queue/jms/JMSCacheableMailQueue.java#L705
>>
>> As long as the delivery time is prior to the current system time, then the
>> email should be dequeued and delivered. cf
>>
>> https://github.com/apache/james-project/blob/master/server/queue/queue-jms/src/main/java/org/apache/james/queue/jms/JMSCacheableMailQueue.java#L529
>>
>> Who knows, something is wrong with your time system?
>>
>> Otherwise, I am still curious about your remote delivery metrics. I doubt
>> remote delivery could fail, so it takes time for the mail to be retried.
>> If
>> you are too, you can try to turn on the metrics webadmin routes:
>>
>> https://github.com/apache/james-project/blob/master/server/grafana-reporting/prometheus-datasource/README.md#expose-metrics-for-prometheus-collection
>>
>> Also, sharing the RemoteDelivery mailet configuration (especially
>> *delayTime*,* maxRetries*...) could help too.
>>
>> Quan
>>
>>
>> On Mon, Aug 4, 2025 at 4:19 PM Matt Pryor <
>> pryor@international-presence.com>
>> wrote:
>>
>> > Hi Quan, that webadmin feature doesn't seem to exist:
>> >
>> > {"statusCode":404,"type":"notFound","message":"GET /metrics can not be
>> > found","details":null}
>> >
>> > As an aside after restarting James those messages with delivery date of
>> > 1969 were immediately picked up and sent, but looking through the logs
>> it
>> > seems they were queued on Friday 1st August at 16:44.
>> >
>> > Kind regards
>> > Matt Pryor
>> > Research and Development Manager
>> >
>> > The International Presence Group of Companies
>> > EMAIL: pryor@presencebpm.com
>> > URL: www.International-presence.com
>> >
>> >
>> >
>> >
>> > On Mon, 4 Aug 2025 at 10:02, Quan tran hong <
>> quan.tranhong1999@gmail.com>
>> > wrote:
>> >
>> > > Hi Matt,
>> > >
>> > > Can you share the remote delivery timer metric?
>> > > *curl **localhost:8000/metrics*, then you can search for the
>> > > *RemoteDeliveryTrial* metrics.
>> > >
>> > > Quan
>> > >
>> > > On Mon, Aug 4, 2025 at 3:45 PM Matt Pryor <
>> > > pryor@international-presence.com>
>> > > wrote:
>> > >
>> > > > Thanks Quan.
>> > > >
>> > > > The delays I'm seeing are between initial spooling and the very
>> first
>> > > > delivery attempt.
>> > > >
>> > > > Currently seeing a number of messages in the outgoing mailQueue with
>> > next
>> > > > delivery of
>> > > >
>> > > > 1969-12-31T23:59:59.999Z
>> > > > They do not seem to be progressing.
>> > > > I've noticed that when a message is first queued it has this date
>> but
>> > > only
>> > > > for a very short period until it's picked up by the deliverer.
>> > > > Suggests to me that some thread has died?
>> > > > A call to the healthcheck suggests everything is fine:
>> > > >
>> > > > {"status":"healthy","checks":[{"componentName":"Guice application
>> > > >
>> > > >
>> > >
>> >
>> lifecycle","escapedComponentName":"Guice%20application%20lifecycle","status":"healthy","cause":null},{"componentName":"MailReceptionCheck","escapedComponentName":"MailReceptionCheck","status":"healthy","cause":null},{"componentName":"EventDeadLettersHealthCheck","escapedComponentName":"EventDeadLettersHealthCheck","status":"healthy","cause":null},{"componentName":"EmptyErrorMailRepository","escapedComponentName":"EmptyErrorMailRepository","status":"healthy","cause":null},{"componentName":"Embedded
>> > > >
>> > > >
>> > >
>> >
>> ActiveMQ","escapedComponentName":"Embedded%20ActiveMQ","status":"healthy","cause":null}]}
>> > > >
>> > > >
>> > > >
>> > > > Kind regards
>> > > > Matt Pryor
>> > > > Research and Development Manager
>> > > >
>> > > > The International Presence Group of Companies
>> > > > EMAIL: pryor@presencebpm.com
>> > > > URL: www.International-presence.com
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Fri, 1 Aug 2025 at 18:14, Quan tran hong <
>> > quan.tranhong1999@gmail.com
>> > > >
>> > > > wrote:
>> > > >
>> > > > > Hi Matt,
>> > > > >
>> > > > > > What could be the cause of this I wonder? The server doesn't
>> seem
>> > > > > massively
>> > > > > busy in between those times.
>> > > > >
>> > > > > In my opinion, something could be wrong with your SMTP remote
>> gateway
>> > > > that
>> > > > > makes James (here RemoteDelivery mailet) can not send mail
>> outbound
>> > > right
>> > > > > away. Then, RemoteDelivery would delay some time before retrying
>> the
>> > > > > next remote delivery, which could explain the delay time you
>> > observed.
>> > > > >
>> > > > > You can send an inbound email to verify the theory. If inbound is
>> > fast,
>> > > > > then the problem is likely at the SMTP remote gateway.
>> > > > >
>> > > > > Quan
>> > > > >
>> > > > > On Fri, Aug 1, 2025 at 8:33 PM Matt Pryor <
>> > > > > pryor@international-presence.com>
>> > > > > wrote:
>> > > > >
>> > > > > > I'm seeing long periods where MailDelivrerToHost isn't
>> mentioned in
>> > > the
>> > > > > > logs even though there are plenty of emails being spooled.
>> > > > > >
>> > > > > > How can I find out what's going on?
>> > > > > >
>> > > > > > I've increased the delivery threads to 20 and the spool threads
>> to
>> > > 200
>> > > > > but
>> > > > > > if anything it's made it worse.
>> > > > > >
>> > > > > > Customer now screaming at me.
>> > > > > >
>> > > > > > E.g.
>> > > > > > 2025-08-01 13:11:41.199 [DEBUG] o.a.j.m.i.JamesMailSpooler -
>> ====
>> > End
>> > > > > > processing mail
>> > > > > > Mail1754053901091-441b1ec5-bce3-40ee-af08-94d5a109240e-
>> > to-gmail.com
>> > > > ====
>> > > > > >
>> > > > > > Then... nothing.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > Kind regards
>> > > > > > Matt Pryor
>> > > > > > Research and Development Manager
>> > > > > >
>> > > > > > The International Presence Group of Companies
>> > > > > > EMAIL: pryor@presencebpm.com
>> > > > > > URL: www.International-presence.com
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Fri, 1 Aug 2025 at 10:59, Matt Pryor <
>> > > > > pryor@international-presence.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Hi, I'm running Apache James 3.82.
>> > > > > > >
>> > > > > > > I'm seeing long delays between spooling messages and then
>> > > delivering
>> > > > > > them.
>> > > > > > > For example:
>> > > > > > >
>> > > > > > > 2025-08-01 04:22:22.253 [DEBUG] o.a.j.m.i.JamesMailSpooler -
>> > ====
>> > > > End
>> > > > > > > processing mail
>> > > > > > > Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-
>> > > to-xxxxx.com
>> > > > > ====
>> > > > > > >
>> > > > > > > And then.... 2025-08-01 04:41:00.785 [DEBUG]
>> > > > > > > o.a.j.t.m.r.d.DeliveryRunnable - will process mail
>> > > > > > > Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-
>> > > to-xxxxx.com
>> > > > > > >
>> > > > > > > What could be the cause of this I wonder? The server doesn't
>> seem
>> > > > > > > massively busy in between those times.
>> > > > > > >
>> > > > > > > I upgraded from 3.80 to 3.82 in the hope this would fix the
>> > problem
>> > > > but
>> > > > > > it
>> > > > > > > doesn't seem to have.
>> > > > > > >
>> > > > > > > Kind regards
>> > > > > > > Matt Pryor
>> > > > > > > Research and Development Manager
>> > > > > > >
>> > > > > > > The International Presence Group of Companies
>> > > > > > > EMAIL: pryor@presencebpm.com
>> > > > > > > URL: www.International-presence.com
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
Re: Long delays between spooling and delivering
Posted by Matt Pryor <pr...@international-presence.com>.
Hi Quan
Yes I agree it's the default date when messages are first added to the
sendQueue, but to my mind that should trigger immediate processing to
MailDelivrerToHost, whereas these messages were sat with that timestamp for
over 48 hours.
When messages are retried the next delivery date gets updated to the next
try time, so they weren't in retry state.
Restarting the server caused them to be dequeued and delivered immediately.
My RemoteDelivery mailet config below.
<processor state="relay" enableJmx="true">
<mailet match="All" class="RemoteDelivery">
<outgoingQueue>outgoing</outgoingQueue>
<delayTime>
1*10 minute,
2*30 minute,
4*1 hour,
8*2 hour,
4*6 hour
</delayTime>
<maxRetries>20</maxRetries>
<maxDnsProblemRetries>5</maxDnsProblemRetries>
<deliveryThreads>20</deliveryThreads>
<sendpartial>true</sendpartial>
<bounceProcessor>bounces</bounceProcessor>
<debug>true</debug>
<startTLS>true</startTLS> <!-- added by MP 2025-07-17-->
<mail.smtp.starttls.required>false</mail.smtp.starttls.required>
<mail.smtp.ssl.protocols>TLSv1.3 TLSv1.2 TLSv1.1 TLSv1 SSLv3
SSLv2Hello</mail.smtp.ssl.protocols>
</mailet>
</processor>
Kind regards
Matt Pryor
Research and Development Manager
The International Presence Group of Companies
EMAIL: pryor@presencebpm.com
URL: www.International-presence.com
On Mon, 4 Aug 2025 at 11:03, Quan tran hong <qu...@gmail.com>
wrote:
> Hi,
>
> IMO, there is nothing harmful about the delivery date of 1969.
>
> I guess you get it from the mail queue route. It was likely the result
> of Unix epoch plus -1 millisecond (the -1 default delay, which means there
> is no delay) cf
>
> https://github.com/apache/james-project/blob/master/server/queue/queue-jms/src/main/java/org/apache/james/queue/jms/JMSCacheableMailQueue.java#L705
>
> As long as the delivery time is prior to the current system time, then the
> email should be dequeued and delivered. cf
>
> https://github.com/apache/james-project/blob/master/server/queue/queue-jms/src/main/java/org/apache/james/queue/jms/JMSCacheableMailQueue.java#L529
>
> Who knows, something is wrong with your time system?
>
> Otherwise, I am still curious about your remote delivery metrics. I doubt
> remote delivery could fail, so it takes time for the mail to be retried. If
> you are too, you can try to turn on the metrics webadmin routes:
>
> https://github.com/apache/james-project/blob/master/server/grafana-reporting/prometheus-datasource/README.md#expose-metrics-for-prometheus-collection
>
> Also, sharing the RemoteDelivery mailet configuration (especially
> *delayTime*,* maxRetries*...) could help too.
>
> Quan
>
>
> On Mon, Aug 4, 2025 at 4:19 PM Matt Pryor <
> pryor@international-presence.com>
> wrote:
>
> > Hi Quan, that webadmin feature doesn't seem to exist:
> >
> > {"statusCode":404,"type":"notFound","message":"GET /metrics can not be
> > found","details":null}
> >
> > As an aside after restarting James those messages with delivery date of
> > 1969 were immediately picked up and sent, but looking through the logs it
> > seems they were queued on Friday 1st August at 16:44.
> >
> > Kind regards
> > Matt Pryor
> > Research and Development Manager
> >
> > The International Presence Group of Companies
> > EMAIL: pryor@presencebpm.com
> > URL: www.International-presence.com
> >
> >
> >
> >
> > On Mon, 4 Aug 2025 at 10:02, Quan tran hong <quan.tranhong1999@gmail.com
> >
> > wrote:
> >
> > > Hi Matt,
> > >
> > > Can you share the remote delivery timer metric?
> > > *curl **localhost:8000/metrics*, then you can search for the
> > > *RemoteDeliveryTrial* metrics.
> > >
> > > Quan
> > >
> > > On Mon, Aug 4, 2025 at 3:45 PM Matt Pryor <
> > > pryor@international-presence.com>
> > > wrote:
> > >
> > > > Thanks Quan.
> > > >
> > > > The delays I'm seeing are between initial spooling and the very first
> > > > delivery attempt.
> > > >
> > > > Currently seeing a number of messages in the outgoing mailQueue with
> > next
> > > > delivery of
> > > >
> > > > 1969-12-31T23:59:59.999Z
> > > > They do not seem to be progressing.
> > > > I've noticed that when a message is first queued it has this date but
> > > only
> > > > for a very short period until it's picked up by the deliverer.
> > > > Suggests to me that some thread has died?
> > > > A call to the healthcheck suggests everything is fine:
> > > >
> > > > {"status":"healthy","checks":[{"componentName":"Guice application
> > > >
> > > >
> > >
> >
> lifecycle","escapedComponentName":"Guice%20application%20lifecycle","status":"healthy","cause":null},{"componentName":"MailReceptionCheck","escapedComponentName":"MailReceptionCheck","status":"healthy","cause":null},{"componentName":"EventDeadLettersHealthCheck","escapedComponentName":"EventDeadLettersHealthCheck","status":"healthy","cause":null},{"componentName":"EmptyErrorMailRepository","escapedComponentName":"EmptyErrorMailRepository","status":"healthy","cause":null},{"componentName":"Embedded
> > > >
> > > >
> > >
> >
> ActiveMQ","escapedComponentName":"Embedded%20ActiveMQ","status":"healthy","cause":null}]}
> > > >
> > > >
> > > >
> > > > Kind regards
> > > > Matt Pryor
> > > > Research and Development Manager
> > > >
> > > > The International Presence Group of Companies
> > > > EMAIL: pryor@presencebpm.com
> > > > URL: www.International-presence.com
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, 1 Aug 2025 at 18:14, Quan tran hong <
> > quan.tranhong1999@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Hi Matt,
> > > > >
> > > > > > What could be the cause of this I wonder? The server doesn't seem
> > > > > massively
> > > > > busy in between those times.
> > > > >
> > > > > In my opinion, something could be wrong with your SMTP remote
> gateway
> > > > that
> > > > > makes James (here RemoteDelivery mailet) can not send mail outbound
> > > right
> > > > > away. Then, RemoteDelivery would delay some time before retrying
> the
> > > > > next remote delivery, which could explain the delay time you
> > observed.
> > > > >
> > > > > You can send an inbound email to verify the theory. If inbound is
> > fast,
> > > > > then the problem is likely at the SMTP remote gateway.
> > > > >
> > > > > Quan
> > > > >
> > > > > On Fri, Aug 1, 2025 at 8:33 PM Matt Pryor <
> > > > > pryor@international-presence.com>
> > > > > wrote:
> > > > >
> > > > > > I'm seeing long periods where MailDelivrerToHost isn't mentioned
> in
> > > the
> > > > > > logs even though there are plenty of emails being spooled.
> > > > > >
> > > > > > How can I find out what's going on?
> > > > > >
> > > > > > I've increased the delivery threads to 20 and the spool threads
> to
> > > 200
> > > > > but
> > > > > > if anything it's made it worse.
> > > > > >
> > > > > > Customer now screaming at me.
> > > > > >
> > > > > > E.g.
> > > > > > 2025-08-01 13:11:41.199 [DEBUG] o.a.j.m.i.JamesMailSpooler - ====
> > End
> > > > > > processing mail
> > > > > > Mail1754053901091-441b1ec5-bce3-40ee-af08-94d5a109240e-
> > to-gmail.com
> > > > ====
> > > > > >
> > > > > > Then... nothing.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Kind regards
> > > > > > Matt Pryor
> > > > > > Research and Development Manager
> > > > > >
> > > > > > The International Presence Group of Companies
> > > > > > EMAIL: pryor@presencebpm.com
> > > > > > URL: www.International-presence.com
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, 1 Aug 2025 at 10:59, Matt Pryor <
> > > > > pryor@international-presence.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi, I'm running Apache James 3.82.
> > > > > > >
> > > > > > > I'm seeing long delays between spooling messages and then
> > > delivering
> > > > > > them.
> > > > > > > For example:
> > > > > > >
> > > > > > > 2025-08-01 04:22:22.253 [DEBUG] o.a.j.m.i.JamesMailSpooler -
> > ====
> > > > End
> > > > > > > processing mail
> > > > > > > Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-
> > > to-xxxxx.com
> > > > > ====
> > > > > > >
> > > > > > > And then.... 2025-08-01 04:41:00.785 [DEBUG]
> > > > > > > o.a.j.t.m.r.d.DeliveryRunnable - will process mail
> > > > > > > Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-
> > > to-xxxxx.com
> > > > > > >
> > > > > > > What could be the cause of this I wonder? The server doesn't
> seem
> > > > > > > massively busy in between those times.
> > > > > > >
> > > > > > > I upgraded from 3.80 to 3.82 in the hope this would fix the
> > problem
> > > > but
> > > > > > it
> > > > > > > doesn't seem to have.
> > > > > > >
> > > > > > > Kind regards
> > > > > > > Matt Pryor
> > > > > > > Research and Development Manager
> > > > > > >
> > > > > > > The International Presence Group of Companies
> > > > > > > EMAIL: pryor@presencebpm.com
> > > > > > > URL: www.International-presence.com
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Long delays between spooling and delivering
Posted by Quan tran hong <qu...@gmail.com>.
Hi,
IMO, there is nothing harmful about the delivery date of 1969.
I guess you get it from the mail queue route. It was likely the result
of Unix epoch plus -1 millisecond (the -1 default delay, which means there
is no delay) cf
https://github.com/apache/james-project/blob/master/server/queue/queue-jms/src/main/java/org/apache/james/queue/jms/JMSCacheableMailQueue.java#L705
As long as the delivery time is prior to the current system time, then the
email should be dequeued and delivered. cf
https://github.com/apache/james-project/blob/master/server/queue/queue-jms/src/main/java/org/apache/james/queue/jms/JMSCacheableMailQueue.java#L529
Who knows, something is wrong with your time system?
Otherwise, I am still curious about your remote delivery metrics. I doubt
remote delivery could fail, so it takes time for the mail to be retried. If
you are too, you can try to turn on the metrics webadmin routes:
https://github.com/apache/james-project/blob/master/server/grafana-reporting/prometheus-datasource/README.md#expose-metrics-for-prometheus-collection
Also, sharing the RemoteDelivery mailet configuration (especially
*delayTime*,* maxRetries*...) could help too.
Quan
On Mon, Aug 4, 2025 at 4:19 PM Matt Pryor <pr...@international-presence.com>
wrote:
> Hi Quan, that webadmin feature doesn't seem to exist:
>
> {"statusCode":404,"type":"notFound","message":"GET /metrics can not be
> found","details":null}
>
> As an aside after restarting James those messages with delivery date of
> 1969 were immediately picked up and sent, but looking through the logs it
> seems they were queued on Friday 1st August at 16:44.
>
> Kind regards
> Matt Pryor
> Research and Development Manager
>
> The International Presence Group of Companies
> EMAIL: pryor@presencebpm.com
> URL: www.International-presence.com
>
>
>
>
> On Mon, 4 Aug 2025 at 10:02, Quan tran hong <qu...@gmail.com>
> wrote:
>
> > Hi Matt,
> >
> > Can you share the remote delivery timer metric?
> > *curl **localhost:8000/metrics*, then you can search for the
> > *RemoteDeliveryTrial* metrics.
> >
> > Quan
> >
> > On Mon, Aug 4, 2025 at 3:45 PM Matt Pryor <
> > pryor@international-presence.com>
> > wrote:
> >
> > > Thanks Quan.
> > >
> > > The delays I'm seeing are between initial spooling and the very first
> > > delivery attempt.
> > >
> > > Currently seeing a number of messages in the outgoing mailQueue with
> next
> > > delivery of
> > >
> > > 1969-12-31T23:59:59.999Z
> > > They do not seem to be progressing.
> > > I've noticed that when a message is first queued it has this date but
> > only
> > > for a very short period until it's picked up by the deliverer.
> > > Suggests to me that some thread has died?
> > > A call to the healthcheck suggests everything is fine:
> > >
> > > {"status":"healthy","checks":[{"componentName":"Guice application
> > >
> > >
> >
> lifecycle","escapedComponentName":"Guice%20application%20lifecycle","status":"healthy","cause":null},{"componentName":"MailReceptionCheck","escapedComponentName":"MailReceptionCheck","status":"healthy","cause":null},{"componentName":"EventDeadLettersHealthCheck","escapedComponentName":"EventDeadLettersHealthCheck","status":"healthy","cause":null},{"componentName":"EmptyErrorMailRepository","escapedComponentName":"EmptyErrorMailRepository","status":"healthy","cause":null},{"componentName":"Embedded
> > >
> > >
> >
> ActiveMQ","escapedComponentName":"Embedded%20ActiveMQ","status":"healthy","cause":null}]}
> > >
> > >
> > >
> > > Kind regards
> > > Matt Pryor
> > > Research and Development Manager
> > >
> > > The International Presence Group of Companies
> > > EMAIL: pryor@presencebpm.com
> > > URL: www.International-presence.com
> > >
> > >
> > >
> > >
> > > On Fri, 1 Aug 2025 at 18:14, Quan tran hong <
> quan.tranhong1999@gmail.com
> > >
> > > wrote:
> > >
> > > > Hi Matt,
> > > >
> > > > > What could be the cause of this I wonder? The server doesn't seem
> > > > massively
> > > > busy in between those times.
> > > >
> > > > In my opinion, something could be wrong with your SMTP remote gateway
> > > that
> > > > makes James (here RemoteDelivery mailet) can not send mail outbound
> > right
> > > > away. Then, RemoteDelivery would delay some time before retrying the
> > > > next remote delivery, which could explain the delay time you
> observed.
> > > >
> > > > You can send an inbound email to verify the theory. If inbound is
> fast,
> > > > then the problem is likely at the SMTP remote gateway.
> > > >
> > > > Quan
> > > >
> > > > On Fri, Aug 1, 2025 at 8:33 PM Matt Pryor <
> > > > pryor@international-presence.com>
> > > > wrote:
> > > >
> > > > > I'm seeing long periods where MailDelivrerToHost isn't mentioned in
> > the
> > > > > logs even though there are plenty of emails being spooled.
> > > > >
> > > > > How can I find out what's going on?
> > > > >
> > > > > I've increased the delivery threads to 20 and the spool threads to
> > 200
> > > > but
> > > > > if anything it's made it worse.
> > > > >
> > > > > Customer now screaming at me.
> > > > >
> > > > > E.g.
> > > > > 2025-08-01 13:11:41.199 [DEBUG] o.a.j.m.i.JamesMailSpooler - ====
> End
> > > > > processing mail
> > > > > Mail1754053901091-441b1ec5-bce3-40ee-af08-94d5a109240e-
> to-gmail.com
> > > ====
> > > > >
> > > > > Then... nothing.
> > > > >
> > > > >
> > > > >
> > > > > Kind regards
> > > > > Matt Pryor
> > > > > Research and Development Manager
> > > > >
> > > > > The International Presence Group of Companies
> > > > > EMAIL: pryor@presencebpm.com
> > > > > URL: www.International-presence.com
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, 1 Aug 2025 at 10:59, Matt Pryor <
> > > > pryor@international-presence.com>
> > > > > wrote:
> > > > >
> > > > > > Hi, I'm running Apache James 3.82.
> > > > > >
> > > > > > I'm seeing long delays between spooling messages and then
> > delivering
> > > > > them.
> > > > > > For example:
> > > > > >
> > > > > > 2025-08-01 04:22:22.253 [DEBUG] o.a.j.m.i.JamesMailSpooler -
> ====
> > > End
> > > > > > processing mail
> > > > > > Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-
> > to-xxxxx.com
> > > > ====
> > > > > >
> > > > > > And then.... 2025-08-01 04:41:00.785 [DEBUG]
> > > > > > o.a.j.t.m.r.d.DeliveryRunnable - will process mail
> > > > > > Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-
> > to-xxxxx.com
> > > > > >
> > > > > > What could be the cause of this I wonder? The server doesn't seem
> > > > > > massively busy in between those times.
> > > > > >
> > > > > > I upgraded from 3.80 to 3.82 in the hope this would fix the
> problem
> > > but
> > > > > it
> > > > > > doesn't seem to have.
> > > > > >
> > > > > > Kind regards
> > > > > > Matt Pryor
> > > > > > Research and Development Manager
> > > > > >
> > > > > > The International Presence Group of Companies
> > > > > > EMAIL: pryor@presencebpm.com
> > > > > > URL: www.International-presence.com
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Long delays between spooling and delivering
Posted by Matt Pryor <pr...@international-presence.com>.
Hi Quan, that webadmin feature doesn't seem to exist:
{"statusCode":404,"type":"notFound","message":"GET /metrics can not be
found","details":null}
As an aside after restarting James those messages with delivery date of
1969 were immediately picked up and sent, but looking through the logs it
seems they were queued on Friday 1st August at 16:44.
Kind regards
Matt Pryor
Research and Development Manager
The International Presence Group of Companies
EMAIL: pryor@presencebpm.com
URL: www.International-presence.com
On Mon, 4 Aug 2025 at 10:02, Quan tran hong <qu...@gmail.com>
wrote:
> Hi Matt,
>
> Can you share the remote delivery timer metric?
> *curl **localhost:8000/metrics*, then you can search for the
> *RemoteDeliveryTrial* metrics.
>
> Quan
>
> On Mon, Aug 4, 2025 at 3:45 PM Matt Pryor <
> pryor@international-presence.com>
> wrote:
>
> > Thanks Quan.
> >
> > The delays I'm seeing are between initial spooling and the very first
> > delivery attempt.
> >
> > Currently seeing a number of messages in the outgoing mailQueue with next
> > delivery of
> >
> > 1969-12-31T23:59:59.999Z
> > They do not seem to be progressing.
> > I've noticed that when a message is first queued it has this date but
> only
> > for a very short period until it's picked up by the deliverer.
> > Suggests to me that some thread has died?
> > A call to the healthcheck suggests everything is fine:
> >
> > {"status":"healthy","checks":[{"componentName":"Guice application
> >
> >
> lifecycle","escapedComponentName":"Guice%20application%20lifecycle","status":"healthy","cause":null},{"componentName":"MailReceptionCheck","escapedComponentName":"MailReceptionCheck","status":"healthy","cause":null},{"componentName":"EventDeadLettersHealthCheck","escapedComponentName":"EventDeadLettersHealthCheck","status":"healthy","cause":null},{"componentName":"EmptyErrorMailRepository","escapedComponentName":"EmptyErrorMailRepository","status":"healthy","cause":null},{"componentName":"Embedded
> >
> >
> ActiveMQ","escapedComponentName":"Embedded%20ActiveMQ","status":"healthy","cause":null}]}
> >
> >
> >
> > Kind regards
> > Matt Pryor
> > Research and Development Manager
> >
> > The International Presence Group of Companies
> > EMAIL: pryor@presencebpm.com
> > URL: www.International-presence.com
> >
> >
> >
> >
> > On Fri, 1 Aug 2025 at 18:14, Quan tran hong <quan.tranhong1999@gmail.com
> >
> > wrote:
> >
> > > Hi Matt,
> > >
> > > > What could be the cause of this I wonder? The server doesn't seem
> > > massively
> > > busy in between those times.
> > >
> > > In my opinion, something could be wrong with your SMTP remote gateway
> > that
> > > makes James (here RemoteDelivery mailet) can not send mail outbound
> right
> > > away. Then, RemoteDelivery would delay some time before retrying the
> > > next remote delivery, which could explain the delay time you observed.
> > >
> > > You can send an inbound email to verify the theory. If inbound is fast,
> > > then the problem is likely at the SMTP remote gateway.
> > >
> > > Quan
> > >
> > > On Fri, Aug 1, 2025 at 8:33 PM Matt Pryor <
> > > pryor@international-presence.com>
> > > wrote:
> > >
> > > > I'm seeing long periods where MailDelivrerToHost isn't mentioned in
> the
> > > > logs even though there are plenty of emails being spooled.
> > > >
> > > > How can I find out what's going on?
> > > >
> > > > I've increased the delivery threads to 20 and the spool threads to
> 200
> > > but
> > > > if anything it's made it worse.
> > > >
> > > > Customer now screaming at me.
> > > >
> > > > E.g.
> > > > 2025-08-01 13:11:41.199 [DEBUG] o.a.j.m.i.JamesMailSpooler - ==== End
> > > > processing mail
> > > > Mail1754053901091-441b1ec5-bce3-40ee-af08-94d5a109240e-to-gmail.com
> > ====
> > > >
> > > > Then... nothing.
> > > >
> > > >
> > > >
> > > > Kind regards
> > > > Matt Pryor
> > > > Research and Development Manager
> > > >
> > > > The International Presence Group of Companies
> > > > EMAIL: pryor@presencebpm.com
> > > > URL: www.International-presence.com
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, 1 Aug 2025 at 10:59, Matt Pryor <
> > > pryor@international-presence.com>
> > > > wrote:
> > > >
> > > > > Hi, I'm running Apache James 3.82.
> > > > >
> > > > > I'm seeing long delays between spooling messages and then
> delivering
> > > > them.
> > > > > For example:
> > > > >
> > > > > 2025-08-01 04:22:22.253 [DEBUG] o.a.j.m.i.JamesMailSpooler - ====
> > End
> > > > > processing mail
> > > > > Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-
> to-xxxxx.com
> > > ====
> > > > >
> > > > > And then.... 2025-08-01 04:41:00.785 [DEBUG]
> > > > > o.a.j.t.m.r.d.DeliveryRunnable - will process mail
> > > > > Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-
> to-xxxxx.com
> > > > >
> > > > > What could be the cause of this I wonder? The server doesn't seem
> > > > > massively busy in between those times.
> > > > >
> > > > > I upgraded from 3.80 to 3.82 in the hope this would fix the problem
> > but
> > > > it
> > > > > doesn't seem to have.
> > > > >
> > > > > Kind regards
> > > > > Matt Pryor
> > > > > Research and Development Manager
> > > > >
> > > > > The International Presence Group of Companies
> > > > > EMAIL: pryor@presencebpm.com
> > > > > URL: www.International-presence.com
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Long delays between spooling and delivering
Posted by Quan tran hong <qu...@gmail.com>.
Hi Matt,
Can you share the remote delivery timer metric?
*curl **localhost:8000/metrics*, then you can search for the
*RemoteDeliveryTrial* metrics.
Quan
On Mon, Aug 4, 2025 at 3:45 PM Matt Pryor <pr...@international-presence.com>
wrote:
> Thanks Quan.
>
> The delays I'm seeing are between initial spooling and the very first
> delivery attempt.
>
> Currently seeing a number of messages in the outgoing mailQueue with next
> delivery of
>
> 1969-12-31T23:59:59.999Z
> They do not seem to be progressing.
> I've noticed that when a message is first queued it has this date but only
> for a very short period until it's picked up by the deliverer.
> Suggests to me that some thread has died?
> A call to the healthcheck suggests everything is fine:
>
> {"status":"healthy","checks":[{"componentName":"Guice application
>
> lifecycle","escapedComponentName":"Guice%20application%20lifecycle","status":"healthy","cause":null},{"componentName":"MailReceptionCheck","escapedComponentName":"MailReceptionCheck","status":"healthy","cause":null},{"componentName":"EventDeadLettersHealthCheck","escapedComponentName":"EventDeadLettersHealthCheck","status":"healthy","cause":null},{"componentName":"EmptyErrorMailRepository","escapedComponentName":"EmptyErrorMailRepository","status":"healthy","cause":null},{"componentName":"Embedded
>
> ActiveMQ","escapedComponentName":"Embedded%20ActiveMQ","status":"healthy","cause":null}]}
>
>
>
> Kind regards
> Matt Pryor
> Research and Development Manager
>
> The International Presence Group of Companies
> EMAIL: pryor@presencebpm.com
> URL: www.International-presence.com
>
>
>
>
> On Fri, 1 Aug 2025 at 18:14, Quan tran hong <qu...@gmail.com>
> wrote:
>
> > Hi Matt,
> >
> > > What could be the cause of this I wonder? The server doesn't seem
> > massively
> > busy in between those times.
> >
> > In my opinion, something could be wrong with your SMTP remote gateway
> that
> > makes James (here RemoteDelivery mailet) can not send mail outbound right
> > away. Then, RemoteDelivery would delay some time before retrying the
> > next remote delivery, which could explain the delay time you observed.
> >
> > You can send an inbound email to verify the theory. If inbound is fast,
> > then the problem is likely at the SMTP remote gateway.
> >
> > Quan
> >
> > On Fri, Aug 1, 2025 at 8:33 PM Matt Pryor <
> > pryor@international-presence.com>
> > wrote:
> >
> > > I'm seeing long periods where MailDelivrerToHost isn't mentioned in the
> > > logs even though there are plenty of emails being spooled.
> > >
> > > How can I find out what's going on?
> > >
> > > I've increased the delivery threads to 20 and the spool threads to 200
> > but
> > > if anything it's made it worse.
> > >
> > > Customer now screaming at me.
> > >
> > > E.g.
> > > 2025-08-01 13:11:41.199 [DEBUG] o.a.j.m.i.JamesMailSpooler - ==== End
> > > processing mail
> > > Mail1754053901091-441b1ec5-bce3-40ee-af08-94d5a109240e-to-gmail.com
> ====
> > >
> > > Then... nothing.
> > >
> > >
> > >
> > > Kind regards
> > > Matt Pryor
> > > Research and Development Manager
> > >
> > > The International Presence Group of Companies
> > > EMAIL: pryor@presencebpm.com
> > > URL: www.International-presence.com
> > >
> > >
> > >
> > >
> > > On Fri, 1 Aug 2025 at 10:59, Matt Pryor <
> > pryor@international-presence.com>
> > > wrote:
> > >
> > > > Hi, I'm running Apache James 3.82.
> > > >
> > > > I'm seeing long delays between spooling messages and then delivering
> > > them.
> > > > For example:
> > > >
> > > > 2025-08-01 04:22:22.253 [DEBUG] o.a.j.m.i.JamesMailSpooler - ====
> End
> > > > processing mail
> > > > Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-to-xxxxx.com
> > ====
> > > >
> > > > And then.... 2025-08-01 04:41:00.785 [DEBUG]
> > > > o.a.j.t.m.r.d.DeliveryRunnable - will process mail
> > > > Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-to-xxxxx.com
> > > >
> > > > What could be the cause of this I wonder? The server doesn't seem
> > > > massively busy in between those times.
> > > >
> > > > I upgraded from 3.80 to 3.82 in the hope this would fix the problem
> but
> > > it
> > > > doesn't seem to have.
> > > >
> > > > Kind regards
> > > > Matt Pryor
> > > > Research and Development Manager
> > > >
> > > > The International Presence Group of Companies
> > > > EMAIL: pryor@presencebpm.com
> > > > URL: www.International-presence.com
> > > >
> > > >
> > > >
> > >
> >
>
Re: Long delays between spooling and delivering
Posted by Matt Pryor <pr...@international-presence.com>.
Thanks Quan.
The delays I'm seeing are between initial spooling and the very first
delivery attempt.
Currently seeing a number of messages in the outgoing mailQueue with next
delivery of
1969-12-31T23:59:59.999Z
They do not seem to be progressing.
I've noticed that when a message is first queued it has this date but only
for a very short period until it's picked up by the deliverer.
Suggests to me that some thread has died?
A call to the healthcheck suggests everything is fine:
{"status":"healthy","checks":[{"componentName":"Guice application
lifecycle","escapedComponentName":"Guice%20application%20lifecycle","status":"healthy","cause":null},{"componentName":"MailReceptionCheck","escapedComponentName":"MailReceptionCheck","status":"healthy","cause":null},{"componentName":"EventDeadLettersHealthCheck","escapedComponentName":"EventDeadLettersHealthCheck","status":"healthy","cause":null},{"componentName":"EmptyErrorMailRepository","escapedComponentName":"EmptyErrorMailRepository","status":"healthy","cause":null},{"componentName":"Embedded
ActiveMQ","escapedComponentName":"Embedded%20ActiveMQ","status":"healthy","cause":null}]}
Kind regards
Matt Pryor
Research and Development Manager
The International Presence Group of Companies
EMAIL: pryor@presencebpm.com
URL: www.International-presence.com
On Fri, 1 Aug 2025 at 18:14, Quan tran hong <qu...@gmail.com>
wrote:
> Hi Matt,
>
> > What could be the cause of this I wonder? The server doesn't seem
> massively
> busy in between those times.
>
> In my opinion, something could be wrong with your SMTP remote gateway that
> makes James (here RemoteDelivery mailet) can not send mail outbound right
> away. Then, RemoteDelivery would delay some time before retrying the
> next remote delivery, which could explain the delay time you observed.
>
> You can send an inbound email to verify the theory. If inbound is fast,
> then the problem is likely at the SMTP remote gateway.
>
> Quan
>
> On Fri, Aug 1, 2025 at 8:33 PM Matt Pryor <
> pryor@international-presence.com>
> wrote:
>
> > I'm seeing long periods where MailDelivrerToHost isn't mentioned in the
> > logs even though there are plenty of emails being spooled.
> >
> > How can I find out what's going on?
> >
> > I've increased the delivery threads to 20 and the spool threads to 200
> but
> > if anything it's made it worse.
> >
> > Customer now screaming at me.
> >
> > E.g.
> > 2025-08-01 13:11:41.199 [DEBUG] o.a.j.m.i.JamesMailSpooler - ==== End
> > processing mail
> > Mail1754053901091-441b1ec5-bce3-40ee-af08-94d5a109240e-to-gmail.com ====
> >
> > Then... nothing.
> >
> >
> >
> > Kind regards
> > Matt Pryor
> > Research and Development Manager
> >
> > The International Presence Group of Companies
> > EMAIL: pryor@presencebpm.com
> > URL: www.International-presence.com
> >
> >
> >
> >
> > On Fri, 1 Aug 2025 at 10:59, Matt Pryor <
> pryor@international-presence.com>
> > wrote:
> >
> > > Hi, I'm running Apache James 3.82.
> > >
> > > I'm seeing long delays between spooling messages and then delivering
> > them.
> > > For example:
> > >
> > > 2025-08-01 04:22:22.253 [DEBUG] o.a.j.m.i.JamesMailSpooler - ==== End
> > > processing mail
> > > Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-to-xxxxx.com
> ====
> > >
> > > And then.... 2025-08-01 04:41:00.785 [DEBUG]
> > > o.a.j.t.m.r.d.DeliveryRunnable - will process mail
> > > Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-to-xxxxx.com
> > >
> > > What could be the cause of this I wonder? The server doesn't seem
> > > massively busy in between those times.
> > >
> > > I upgraded from 3.80 to 3.82 in the hope this would fix the problem but
> > it
> > > doesn't seem to have.
> > >
> > > Kind regards
> > > Matt Pryor
> > > Research and Development Manager
> > >
> > > The International Presence Group of Companies
> > > EMAIL: pryor@presencebpm.com
> > > URL: www.International-presence.com
> > >
> > >
> > >
> >
>
Re: Long delays between spooling and delivering
Posted by Quan tran hong <qu...@gmail.com>.
Hi Matt,
> What could be the cause of this I wonder? The server doesn't seem
massively
busy in between those times.
In my opinion, something could be wrong with your SMTP remote gateway that
makes James (here RemoteDelivery mailet) can not send mail outbound right
away. Then, RemoteDelivery would delay some time before retrying the
next remote delivery, which could explain the delay time you observed.
You can send an inbound email to verify the theory. If inbound is fast,
then the problem is likely at the SMTP remote gateway.
Quan
On Fri, Aug 1, 2025 at 8:33 PM Matt Pryor <pr...@international-presence.com>
wrote:
> I'm seeing long periods where MailDelivrerToHost isn't mentioned in the
> logs even though there are plenty of emails being spooled.
>
> How can I find out what's going on?
>
> I've increased the delivery threads to 20 and the spool threads to 200 but
> if anything it's made it worse.
>
> Customer now screaming at me.
>
> E.g.
> 2025-08-01 13:11:41.199 [DEBUG] o.a.j.m.i.JamesMailSpooler - ==== End
> processing mail
> Mail1754053901091-441b1ec5-bce3-40ee-af08-94d5a109240e-to-gmail.com ====
>
> Then... nothing.
>
>
>
> Kind regards
> Matt Pryor
> Research and Development Manager
>
> The International Presence Group of Companies
> EMAIL: pryor@presencebpm.com
> URL: www.International-presence.com
>
>
>
>
> On Fri, 1 Aug 2025 at 10:59, Matt Pryor <pr...@international-presence.com>
> wrote:
>
> > Hi, I'm running Apache James 3.82.
> >
> > I'm seeing long delays between spooling messages and then delivering
> them.
> > For example:
> >
> > 2025-08-01 04:22:22.253 [DEBUG] o.a.j.m.i.JamesMailSpooler - ==== End
> > processing mail
> > Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-to-xxxxx.com ====
> >
> > And then.... 2025-08-01 04:41:00.785 [DEBUG]
> > o.a.j.t.m.r.d.DeliveryRunnable - will process mail
> > Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-to-xxxxx.com
> >
> > What could be the cause of this I wonder? The server doesn't seem
> > massively busy in between those times.
> >
> > I upgraded from 3.80 to 3.82 in the hope this would fix the problem but
> it
> > doesn't seem to have.
> >
> > Kind regards
> > Matt Pryor
> > Research and Development Manager
> >
> > The International Presence Group of Companies
> > EMAIL: pryor@presencebpm.com
> > URL: www.International-presence.com
> >
> >
> >
>
Re: Long delays between spooling and delivering
Posted by Matt Pryor <pr...@international-presence.com>.
I'm seeing long periods where MailDelivrerToHost isn't mentioned in the
logs even though there are plenty of emails being spooled.
How can I find out what's going on?
I've increased the delivery threads to 20 and the spool threads to 200 but
if anything it's made it worse.
Customer now screaming at me.
E.g.
2025-08-01 13:11:41.199 [DEBUG] o.a.j.m.i.JamesMailSpooler - ==== End
processing mail
Mail1754053901091-441b1ec5-bce3-40ee-af08-94d5a109240e-to-gmail.com ====
Then... nothing.
Kind regards
Matt Pryor
Research and Development Manager
The International Presence Group of Companies
EMAIL: pryor@presencebpm.com
URL: www.International-presence.com
On Fri, 1 Aug 2025 at 10:59, Matt Pryor <pr...@international-presence.com>
wrote:
> Hi, I'm running Apache James 3.82.
>
> I'm seeing long delays between spooling messages and then delivering them.
> For example:
>
> 2025-08-01 04:22:22.253 [DEBUG] o.a.j.m.i.JamesMailSpooler - ==== End
> processing mail
> Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-to-xxxxx.com ====
>
> And then.... 2025-08-01 04:41:00.785 [DEBUG]
> o.a.j.t.m.r.d.DeliveryRunnable - will process mail
> Mail1754022142176-e4670a57-8cf4-4412-934e-f0981e559015-to-xxxxx.com
>
> What could be the cause of this I wonder? The server doesn't seem
> massively busy in between those times.
>
> I upgraded from 3.80 to 3.82 in the hope this would fix the problem but it
> doesn't seem to have.
>
> Kind regards
> Matt Pryor
> Research and Development Manager
>
> The International Presence Group of Companies
> EMAIL: pryor@presencebpm.com
> URL: www.International-presence.com
>
>
>