: 4582 | 108584 | 12352

Throttle delivery of large msgs with more than priority 
New idea submissions, commenting and voting are no longer available on this site. Logins have also been disabled.
Use this IdeaSpace to post ideas about Domino Server.

: 28
: 28
: 0
: Domino Server / Messaging router
: Mail, routing, throttle
: Craig Linke217 07 Feb 2008
:
: / Email
I would like to see a method to 'throttle' mail delivery allowing small messages to continue to route when queue lengths are high.

Problem:
Use of priority as a method to throttle mail delivery is not effective enough for companies that operate 24 hrs a day or have worldwide locations -- it is always primetime somewhere. In my environment, mail backs up when we get several large messages (attachments) all being routed simultaneously to the same destination server.

Impact: our monitoring tools frequently page that mail is backing up, and administrators have to check the status of mail routing. Sometimes this involves them waking up to do so only to discover that mail is routing were just temporarily backed up.

My Suggestion/Idea/Solution: Allow for reserving some of the concurrent transfer threads (MailMaxConcurrentXferThreads) to be reserved to route messages of a defined KB size or less. That way, it will be unlikely that the message queue for a particular server destination will become substantially backed up. Even in times of high message volume we should be moving a consistent number of messages. For example, if you have a limit of 5 concurrent messages to a server, perhaps 1 or 2 of those threads could be reserved for messages 40KB or less.



1) Chris Whisonant2445 (07 Feb 2008)
This is a good idea. But allow me to mention something else that you may want to consider. If you haven't heard of DAOS in Domino 8.5 (announced at Lotusphere), then you should check out the second paragraph here:

{ Link }

With that in mind, the router/mail.box dbs should be able to utilize DAOS. This would mean that the router would only need to create one copy of the attachment on the file system and then the internally delivered messages would all refer to that attachment. This would tremendously speed up large file routing since a text-only document would need to be routed to each mail file instead of routing the attachment as well.
2) Bill Malchisky9254 (08 Feb 2008)
Also, keep in-mind that the more checks the router must accomplish on each message, will impact negatively, performance (even if using spare threads, which I'm sure you've considered).

Perhaps have more granularity over what constitutes a low, medium, and high priority message? Then, when the client send it, the new field gets set and the router feeds off of that. So, mail a setting in the Mail Settings document like, "Normal priority messages > 2M automatically get sent as low priority" or "Low priority messages from <group_name> get sent with a <integer> hour delay".
3) Sjef Bosman2089 (08 Feb 2008)
Implementation thoughts: multiple mail*.box databases are already implemented. Why not allow a threshold mail-size for each mailbox, and process multiple queues simultaneously?
4) Volker Rast10 (11 Jul 2008)
In our environment we are battling with WAN links with satellite latency where users send large messages. Due to local mail-in databases we need to keep the local message size relatively high (50MB) vs. what we allow over the link (10MB). We therefore set the limit in the Hub on the HQ side of the link to 10MB. The router on the remote end happily sends the 10MB+ messages over the link, then the router on the hub happily rejects the ENTIRE message back to the sender, causing a dual delay. We recently figured out that you can use RouterAllowConcurrentXferToAll=1 in the ini to allow multiple transfer threads outside the NNN (our remote locations are all on different NNNs due to dial-up as backup to the WAN links). Furthermore, we use the switch to low priority based on size config setting on the remote server, thereby delaying the large messages to the night time on the remote side and are working on an agent to remove the messages on a regular basis with a notice back to the sender.

As far as modifications to the router are concerned I'd therefore want to see a) the router being intelligent enough not to transfer a message if the receiving router won't accept the size; b) have the ability to send only during off-hours (night time) at the receiving router; c) have the ability to tag threads with size limits; d) have the ability to defer messages by size to breaks in traffic (i.e., when there are no smaller messages use n threads or use # of threads -1 to transfer larger messages)

It would also be nice to expand the server rules with intelligence to differentiate between local delivery and transfers










:
:




Welcome to IdeaJam™


You can run IdeaJam™ in your company. It's easy to install, setup and customize. Your employees, partners and customers will immediately see results.

Use IdeaJam to:

  • Collect ideas from employees
  • Solicit feedback and suggestions from employees and customers
  • Run innovation contests and competitions
  • Validate concepts
  • Use the power of "crowd-sourcing" to rank ideas and allow the best ideas to rise to the top

IdeaJam™ works with:

  • IBM Connections
  • IBM Lotus Quickr
  • Blogs and Wikis
  • Websphere Portal
  • Microsoft Sharepoint
  • and other applications.

IdeaJam has an extensive set of widgets and API's that allow you to extend and integrate IdeaJam™ with other applications.

Learn more about IdeaJam >>






IdeaJam developed by

Elguji Software Logo