| Newsgroups |
gmane.comp.jakarta.james.user |
| Message-ID |
<[email protected]> |
Hello Amlan,
On 30/07/2021 16:46, Amlan Sengupta wrote:
> 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). "
This statement missed the `Given extra development` prefix. This cannot
be configured as of today.
We (I) would be glad to welcome contributions on a
RemotreDeliveryThroughGateway mailet that reuses connections and that do
not split emails per domain.
I can also provide (commercial) assistance doing so, if you need to.
Regards,
Benoit
>
> 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]