On 13/07/2021 17:38, Amlan Sengupta wrote:
> 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>
Did it work?
(The MailDelivrerToHost is explicitly closing the connection on each
mail so I doubt it)
>
>
> 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>
The right syntax is
<gateway>${env:SMTP_GATEWAY_1},${env:SMTP_GATEWAY_2},${env:SMTP_GATEWAY_3},${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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]