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, "btell...@apache.org" <btell...@apache.org> 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: server-user-unsubscr...@james.apache.org
>     For additional commands, e-mail: server-user-h...@james.apache.org
>
>
>
>
> ---
> 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: server-user-unsubscr...@james.apache.org
> For additional commands, e-mail: server-user-h...@james.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org

Reply via email to