Hello,
This is how the mailet is looking like. I also by adding the following optional
elements and increasing timeout to 10 mins was able to get better connection
reuse on the gateway. I need to further optimise the reuse. - Amlan
<connectionTimeout>600000</connectionTimeout>
<timeout>600000</timeout>
Mailet:
<mailet match="All" class="RemoteDelivery">
<outgoing>outgoing</outgoing>
<!-- Enabled tls -->
<startTLS>true</startTLS>
<!-- This was customised -->
<delayTime>4 * 60 minutes, 2 * 4 hours, 18 * 12 hours</delayTime>
<maxRetries>3</maxRetries>
<maxDnsProblemRetries>3</maxDnsProblemRetries>
<connectionTimeout>600000</connectionTimeout>
<timeout>600000</timeout>
<!-- This was customised to a value of 1-->
<!-- The number of threads that should be trying to deliver outgoing
messages -->
<deliveryThreads>${env:MTA_DELIVERY_THREADS}</deliveryThreads>
<!-- If false the message will not be sent to given server if any
recipients fail -->
<sendpartial>true</sendpartial>
<!-- By default we send bounces to the "bounce" processor -->
<!-- By removing this configuration James will fallback to hardcoded
bounce -->
<!-- notifications -->
<bounceProcessor>bounces</bounceProcessor>
<!-- A single mail server to deliver all outgoing messages. -->
<gateway>${env:SMTP_GATEWAY_1}</gateway>
<gateway>${env:SMTP_GATEWAY_2}</gateway>
<gateway>${env:SMTP_GATEWAY_3}</gateway>
<gateway>${env:SMTP_GATEWAY_4}</gateway>
<!-- If the gateway requires smtp authentication the following
directives -->
<gatewayUsername>${env:SMTP_WEBSSO_USERNAME}</gatewayUsername>
<gatewayPassword>${env:SMTP_WEBSSO_PASSWORD}</gatewayPassword>
<!-- Set the HELO/EHLO name to use when connecting to remote
SMTP-Server -->
<mail.smtp.localhost>${env:SMTP_LOCALHOST_NAME}</mail.smtp.localhost>
</mailet>
On 13/07/2021, 11:21, "[email protected]" <[email protected]> wrote:
Hello Amlan,
Could you please share your remote delivery configuration in
mailetcontainer.xml? Have you been configuring it as a SMTP gateway?
I noticed this too in a performance enhancement session with flame
graphs. To be fairly honest the code paths handling direct resolution
and gateway resolution are relying on the very same code path,
preventing efforts to pool the underlying SMTP transports and do
effectively connection pooling.
I think this could be achieved by segregating the two use cases and
actually write two transport layers (both relying on javax.mail), one
doing just direct resolution with connection churn, one achieving
gateway forward with good connection pooling.
Also with gateway mode turned on, we no longer need per-domain delivery
and can group deliveries (this would reduce network exchanges /
connection overhead).
We can discuss those more these technical details. I would personally
more than welcome contribution on the topic of "Outgoing SMTP connection
reuse when gateway mode is active". I would also be happy to be
sponsored to contribute it.
Cheers,
Benoit
On 13/07/2021 16:18, Amlan Sengupta wrote:
> Hello,
>
> We are seeing something very strange with Apache James MTA.
>
> Keeping the flow below in context, we have a client which only uses 1
connection ad reuses it send emails to Apache James. We have confirmed this
through connection tracking. We are seeing Apache James spawning up to 60
connections.
>
> Flow :
> Docker Client ---- ( 1 connection : 60 emails ) ----> Apache James ( MTA
) on Docker ---( spawning 60 new connections ) -> SMTP Gateway.
>
> Configuration:
> I have sent the following to 1 and retested. It still behaves the same
way.
>
> MTA_SPOOL_THREADS=1
> MTA_DELIVERY_THREADS=1
>
>
> <!-- Number of spool threads -->
>
> <spooler>
>
> <threads>${env:MTA_SPOOL_THREADS}</threads>
>
>
<errorRepository>file:///deployments/logs/mail/error/</errorRepository>
>
> </spooler>
>
> <!-- The number of threads that should be trying to deliver outgoing
messages -->
> <deliveryThreads>${env:MTA_DELIVERY_THREADS}</deliveryThreads>
>
>
> Objective here is limit the no of connections made to SMTPGateway.
>
> Any guidance ? Amlan
>
>
> ---
> This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.
>
> Please refer to https://www.db.com/disclosures for additional EU
corporate and regulatory disclosures and to
http://www.db.com/unitedkingdom/content/privacy.htm for information about
privacy.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the material in this e-mail is strictly forbidden.
Please refer to https://www.db.com/disclosures for additional EU corporate and
regulatory disclosures and to
http://www.db.com/unitedkingdom/content/privacy.htm for information about
privacy.
