Agreed. It also needs to be pointed out that if you use those multiple gateway
lines, and all four gateway hosts are the same server, you are connecting four
times to he same server. My suggestion, if possible, is to hide your gateway
behind a VIP server and do a round-robin request from the VIP to the four
gateways. Also, make sure the env:SMTP_GATEWAY_X (where X is 1, 2, w, or
4)points to EITHER an IP address or an host name, but not both, and if it is an
host name, be sure the DNS record does not have two IP’s for the host.
Sent from my iPad
> On Jul 13, 2021, at 6:45 AM, btell...@apache.org wrote:
>
>
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
