Re: Apache James MTA 3.6.0 spawning additional connections.

Hello,

Using : Apache James Server 3.6.0
OS : RHEL 7
JDK : OpenJDK 11

I understand from the community that

"With gateway mode turned on, we no longer need per-domain delivery
and can group deliveries (this would reduce network exchanges /
connection overhead). "

The question is, is there a way to do it through configuration to minimise connection over head ? I am looking at https://james.apache.org/server/3/config-domainlist.html but the config is not very obvious from this.

Amlan




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]