Re: Rate limiting

Hello Alman,

James so far have no component leveraging throtling.

You will need to implement your own. I think combining a mailet +
requeing with delays when the throttling is exceeded looks like the best
way to go.

Here is a contribution (that ended up not being merged) on the topic.
https://github.com/linagora/james-project/pull/1742

Also let's be in for the usual FileMailQueue disclaimer:

https://github.com/apache/james-project/blob/master/server/queue/queue-file/src/test/java/org/apache/james/queue/file/FileCacheableMailQueueTest.java

FileMailQueue is an outdated unmaintained component suffering incomplete
features and is not thread safe
This includes:
 - JAMES-2298 Unsupported remove management feature
 - JAMES-2954 Incomplete browse implementation
 - JAMES-2544 Mixing concurrent operation might lead to a deadlock and
missing fields
 - JAMES-2979 dequeue is not thread safe

Use it at your own risks. I would suggest the ActiveMQ one, which is safer.

Cheers,

Benoit

Le 29/03/2021 à 17:54, Amlan Sengupta a écrit :
> Hello,
> 
> Apache James : 3.5.0
> 
> I have a non functional requirement which I am trying to implement through Apache James which is “ A maximum of ( very low number ) emails per hour is allowed ”. I am currently using the default FileMailQueue approach while trying  to adhere to ( very low number ) emails per hour requirement. I have configured the following
> 
> CONNECTION_LIMIT : Set the maximum simultaneous incoming connections for this MTA service : 10
> CONNECTION_LIMIT_PERIP : Set the maximum simultaneous incoming connections per IP for this MTA service : 10
> DELIVERY_THREADS : The number of threads that should be trying to deliver outgoing messages : 10
> SPOOL_THREADS : This is a required positive integer element. It specifies the number of threads the SpoolManager will use to process messages in the spool. This parameter tends to substantially impact performance, so it is advisable to tune it in production configurations. : 30
> 
> This meets my email per hour allowed requirement, but the functional component can peak at 216 emails / s so we get lost emails.
> 
> When the following is done,
> 
> CONNECTION_LIMIT : Set the maximum simultaneous incoming connections for this MTA service : 20
> CONNECTION_LIMIT_PERIP : Set the maximum simultaneous incoming connections per IP for this MTA service : 20
> DELIVERY_THREADS : The number of threads that should be trying to deliver outgoing messages : 10
> SPOOL_THREADS : This is a required positive integer element. It specifies the number of threads the SpoolManager will use to process messages in the spool. This parameter tends to substantially impact performance, so it is advisable to tune it in production configurations. : 30
> 
> We are blowing the emails per hour limit.
> 
> So the question is, do I need to do any custom queueing ? or configuration to enable throttling ?
> 
> 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.
>