James Server
  1. James Server
  2. JAMES-1429

FileMailQueue looks like it does not survive James restart

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0-beta3
    • Fix Version/s: 3.0.0-beta5
    • Component/s: Queue
    • Labels:
      None
    • Environment:
      Java 6 on Linux

      Description

      When I restart James (eg. for emergency reconfiguration), the mails in the queue (for example ca 2500 of them) look like they are stuck.

      The mails in the queue were mostly retries (and it was emergency) - if that matters.

      I believe that after the restart they are not delivered, not retried, not deleted at all.

      BTW, we use FileMailQueue becasue the ActiveMQ based queue tended to hang for us for no good reason.

        Issue Links

          Activity

          Hide
          Eric Charles added a comment -

          Hi Andrzej,
          So you confirm this JIRA can be closed?
          (Also, I realize I mentioned in a previous post JAMES-1429 , but it should be JAMES-1432)
          Eric

          Show
          Eric Charles added a comment - Hi Andrzej, So you confirm this JIRA can be closed? (Also, I realize I mentioned in a previous post JAMES-1429 , but it should be JAMES-1432 ) Eric
          Hide
          Andrzej Rusin added a comment -

          Eric,
          Probably I was using some old version of RemoteDelivery.

          Show
          Andrzej Rusin added a comment - Eric, Probably I was using some old version of RemoteDelivery.
          Hide
          Eric Charles added a comment -

          To help the RemoteDelivery configuration, I have create JAMES-1429.
          If Ok for you Andrzej, we could close this JIRA.

          Show
          Eric Charles added a comment - To help the RemoteDelivery configuration, I have create JAMES-1429 . If Ok for you Andrzej, we could close this JIRA.
          Hide
          Eric Charles added a comment -

          Andrzej, I futher debugged and the file queue seems ok, the issue is not there.

          Let me explain

          1. Configuring a bad remote server is not that trivial. Something your socket simply hangs for a the default connectionTimeout (6000ms), which makes the remote delivery waiting long. To really have a delivery failure, I had to remove my ethernet cable

          2. Once the failure occur, i had configured the delayTime such as shown in the mailetcontainer-template, with multiple delayTime tags, which is not how the current code expect. in fact, it excepts something like <delayTime>5000, 10000, 500000</delayTime> where the delay is expressed in ms

          I will fix template and documentation for remotedelivery, but here, it retries correctly after a restart.

          Show
          Eric Charles added a comment - Andrzej, I futher debugged and the file queue seems ok, the issue is not there. Let me explain 1. Configuring a bad remote server is not that trivial. Something your socket simply hangs for a the default connectionTimeout (6000ms), which makes the remote delivery waiting long. To really have a delivery failure, I had to remove my ethernet cable 2. Once the failure occur, i had configured the delayTime such as shown in the mailetcontainer-template, with multiple delayTime tags, which is not how the current code expect. in fact, it excepts something like <delayTime>5000, 10000, 500000</delayTime> where the delay is expressed in ms I will fix template and documentation for remotedelivery, but here, it retries correctly after a restart.
          Hide
          Andrzej Rusin added a comment - - edited

          Eric,

          For what it's worth, it looks like after the fix it is not retrying AT ALL with the regular schedule of remote delivery.
          To be clear, it retries only on James restarts, but not according to the configured retry intervals.
          Wonder why.

          Show
          Andrzej Rusin added a comment - - edited Eric, For what it's worth, it looks like after the fix it is not retrying AT ALL with the regular schedule of remote delivery. To be clear, it retries only on James restarts, but not according to the configured retry intervals. Wonder why.
          Hide
          Andrzej Rusin added a comment -

          Eric,

          Maybe I was not clear enough from the beginning, but I always meant the 'outgoing' use case, basically the queue of emails being attempted to send out with RemoteDelivery and their retries. This was also the case in the original issue report.
          So, your original fix made some difference, that the emails now ARE retried one time instead of zero after james restart, in the context of what you call 'remotedelivery'.

          Show
          Andrzej Rusin added a comment - Eric, Maybe I was not clear enough from the beginning, but I always meant the 'outgoing' use case, basically the queue of emails being attempted to send out with RemoteDelivery and their retries. This was also the case in the original issue report. So, your original fix made some difference, that the emails now ARE retried one time instead of zero after james restart, in the context of what you call 'remotedelivery'.
          Hide
          Eric Charles added a comment -

          Hi Andrzej,

          FileMailQueue is used for both 'spool' and 'remotedelivery'.

          I looked at the spool usecase based on the description you gave (read the pending mails in the spool queue).
          Can you confirm this usecase is fixed?

          Your last comment is more related to the scheduled remotedelivery which I didn't review. I will look at this second use case in the coming days.

          Show
          Eric Charles added a comment - Hi Andrzej, FileMailQueue is used for both 'spool' and 'remotedelivery'. I looked at the spool usecase based on the description you gave (read the pending mails in the spool queue). Can you confirm this usecase is fixed? Your last comment is more related to the scheduled remotedelivery which I didn't review. I will look at this second use case in the coming days.
          Hide
          Andrzej Rusin added a comment -

          Eric,

          Thanks for the atempt to fix it.

          Let me summarize how it behaves after your fix (I am experimenting on 1 email in the queue for clarity):

          0. I compose an email and let it attempt delivery once (while simulating undeliverability conditions). When it attempts and stores back into outgoing, I restart James
          1. After the restart the email is retried IMMEDIATELY, while I think it should wait a bit for it's retry time.
          2. When the attempt is unsuccessful, the log says:
          Storing message Mail1344941530953-04fcaffc-b060-4901-bb6d-d3c99f3a8961 into outgoing after 1 retries
          3. The retry times are configured 5, 10, 45 minutes, 2, 3, 6... hours. So theoretically, after the 1st retry, it should wait 10 minutes and retry again. However, it does not. It's already 55 minutes after point 1 and no retry.

          BTW, it's very easy to simulate undeliverability conditions by misconfiguring the gateway for RemoteDelivery.

          Show
          Andrzej Rusin added a comment - Eric, Thanks for the atempt to fix it. Let me summarize how it behaves after your fix (I am experimenting on 1 email in the queue for clarity): 0. I compose an email and let it attempt delivery once (while simulating undeliverability conditions). When it attempts and stores back into outgoing, I restart James 1. After the restart the email is retried IMMEDIATELY, while I think it should wait a bit for it's retry time. 2. When the attempt is unsuccessful, the log says: Storing message Mail1344941530953-04fcaffc-b060-4901-bb6d-d3c99f3a8961 into outgoing after 1 retries 3. The retry times are configured 5, 10, 45 minutes, 2, 3, 6... hours. So theoretically, after the 1st retry, it should wait 10 minutes and retry again. However, it does not. It's already 55 minutes after point 1 and no retry. BTW, it's very easy to simulate undeliverability conditions by misconfiguring the gateway for RemoteDelivery.
          Hide
          Eric Charles added a comment -

          Fixed in trunk. Thx for the report Andrzej.

          Show
          Eric Charles added a comment - Fixed in trunk. Thx for the report Andrzej.

            People

            • Assignee:
              Eric Charles
              Reporter:
              Andrzej Rusin
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development