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, "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.