1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Mail queue w/ priority

Discussion in 'XenForo Suggestions' started by digitalpoint, Jan 14, 2012.

  1. digitalpoint

    digitalpoint Well-Known Member

    From the looks of the existing XenForo_Mail class, it looks like a queue system is already planned. One thing I would suggest would be to allow an optional priority of sorts you can set when queuing something.

    For example say I sent an email to 500,000 users (you could of course argue that maybe you shouldn't be sending that many from the AdminCP, but just for sake of argument...)

    So now I have 500,000 emails inserted into the queue and they may take quite awhile to send (hours)... you wouldn't really want the higher priority stuff in the queue to have to wait (things like registration emails) for the bulk stuff to finish.

    Two different queue senders... a "normal" and a "bulk" would be ideal in my opinion. Then you don't have the queue senders affecting each other.
  2. EQnoble

    EQnoble Well-Known Member

    So what your proposing if I understand it correctly...

    2 queue instances , bulk being a low priority with however many it can send per unit of time according to whatever else is going on..
    and normal, something is queued and processed no questions asked?

    Do I understand you correctly.
  3. Digital Doctor

    Digital Doctor Well-Known Member

    what about registrations being sent the default way (instantly)
    and other mail sent via the queue.
  4. ragtek

    ragtek Guest

    not only registration;)

    1. registration mail / account confirmation
    2. "password forgotten" mail
    3. and last but not least, several add-ons sending important mails
    4. and i would also prefer to get the "watched thread" & conversation mails ASAP

    so yes, i agree that it would be great to have 2 priorities (immediately & a "cronjob based" mailqueue for mails like "ragtek, you weren't online for 2 months,... we miss you..bla bla)
    Rigel Kentaurus likes this.
  5. Digital Doctor

    Digital Doctor Well-Known Member

    deebs uses some software for queuing the mail.
  6. digitalpoint

    digitalpoint Well-Known Member

    Yep... for very important things that consist of a single email, I still think "instant" should be the way to go (no queue), but for some things like new post email notifications should go to a queue with a higher priority than the bulk stuff.

    Speaking of... what happens currently if you have a thread with a lot of people subscribed getting email notifications? Does the page load of whoever is posting a reply get slower with it trying to send them all instantly?

    For example... I have some threads with over 1,000 users getting email notifications of replies. If someone posting the reply has to wait for 1,000 emails to be sent before they see their post, it's ultimately going to time out I would think.
  7. Rigel Kentaurus

    Rigel Kentaurus Well-Known Member

    It does. Actually it is insanely and extremely slow. That is also why I switched to "no email notification" as the default for newly registered members.

    The user posting the reply would have to wait for the mails to complete which would be too slow most of the times. Worst part is that it can make the AJAX timeout for the reply, so the user is kept without feedback. And then they may click again in the Post Reply button which makes it worse (a double post).

    A while ago I was complaining about that, here

    You actually suggested moving it to the destruct method.
  8. digitalpoint

    digitalpoint Well-Known Member

    Oh yeah..... I forgot I already made an add-on that moves the actual sending to __destruct(). lol I guess that takes care of the issue of trying to send 100 or 1,000 notifications emails in realtime.

    I still think there needs to be a proper queue system though. If you send an email to 500,000 users as a mailing, I suspect PHP (or maybe the entire server) will run out of memory just tracking the emails that need to be sent on __destruct(). :)
  9. AlexT

    AlexT Well-Known Member

    +1 for a mail queue.

Share This Page