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. > --------------------------------------------------------------------- To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org For additional commands, e-mail: server-user-h...@james.apache.org
