XWiki Platform
  1. XWiki Platform
  2. XWIKI-13991

Prepared mails might be never sent if the XWiki server crash or is restarted

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 8.4.4, 9.0-rc-1
    • Fix Version/s: 9.3-rc-1
    • Component/s: Mail
    • Labels:
      None
    • Tests:
      Unit
    • Difficulty:
      Unknown
    • Similar issues:

      Description

      The send queue is not persistent between server restart leaving prepared mail unsent if they were not sent between their preparation and the next server restart.

      A very bad example is the watch list that is scheduled periodically. If you also schedule a server restart close to the watchlist schedule, all the mail prepare by the watchlist will never get sent, only a first few will be.

        Activity

        Hide
        Denis Gervalle added a comment - - edited

        Sure, but don't forget to reopen all the issues related to it as well... or why not just fixing this one ASAP since you agreed it is important ?

        Show
        Denis Gervalle added a comment - - edited Sure, but don't forget to reopen all the issues related to it as well... or why not just fixing this one ASAP since you agreed it is important ?
        Hide
        Vincent Massol added a comment -

        I'm +1 to fix it ASAP. When do you start?

        Show
        Vincent Massol added a comment - I'm +1 to fix it ASAP. When do you start?
        Hide
        Vincent Massol added a comment -

        I'll implement it!

        Show
        Vincent Massol added a comment - I'll implement it!
        Hide
        Vincent Massol added a comment - - edited

        First functional version done. What needs to be improved:

        • Perform the resending in an async Job. Even though the actual resending is async already, the loading of statuses from the DB and the messages from the FS are done in the EvenListener ATM and if there are thousands of mails to be resent that could lead to long starting times for XWiki.
        • [minor] The resending will serialize the message again on the FS which is not needed since the message was actually read from the FS when resending... The re-save should be bypassed in this case.

        Right now I'm also resending automatically all mails in the prepare state but also all mails in error. We may want to only resend mails in prepare state and leave it to the Admin UI to offer a button to try resending mails that were in error. Denis Gervalle any opinion on this?

        Show
        Vincent Massol added a comment - - edited First functional version done. What needs to be improved: Perform the resending in an async Job. Even though the actual resending is async already, the loading of statuses from the DB and the messages from the FS are done in the EvenListener ATM and if there are thousands of mails to be resent that could lead to long starting times for XWiki. [minor] The resending will serialize the message again on the FS which is not needed since the message was actually read from the FS when resending... The re-save should be bypassed in this case. Right now I'm also resending automatically all mails in the prepare state but also all mails in error. We may want to only resend mails in prepare state and leave it to the Admin UI to offer a button to try resending mails that were in error. Denis Gervalle any opinion on this?
        Hide
        Vincent Massol added a comment -

        Note: I've modified the algorithm to only resend mails that are in the prepare state FTM.

        Show
        Vincent Massol added a comment - Note: I've modified the algorithm to only resend mails that are in the prepare state FTM.

          People

          • Assignee:
            Vincent Massol
            Reporter:
            Denis Gervalle
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Date of First Response: