Mail processing results in duplicates due to read timed out error in Jira server


アトラシアン コミュニティをご利用ください。



Issues creation, comments, or notifications are being created within JIRA applications.

Errors similar to the following appears in the atlassian-jira.log:

2012-03-08 13:33:59,987 QuartzWorker-0 ERROR ServiceRunner    The Avengers Initiative [] Mail Handler[10000]: Error connecting to host '' as user 'mailuser' via protocol 'pop3s': javax.mail.MessagingException: Connect failed;
  nested exception is: Read timed out
Caused by: Read timed out


JIRA applications are hitting the configured timeout before a success message comes back from the mail server. At this point a JIRA application does not remove the message from the mailbox or mail queue and on the next mail processing round it will send the same message. This happens until the application receives the success message from the SMTP within the server timeout, then the message clears out from the queue. This bug was corrected in JIRA 6.3.9 as detailed in the below bug report.

JRA-27644 - 課題詳細を取得中... ステータス

JRASERVER-67825 - 課題詳細を取得中... ステータス


Upgrade to JIRA 6.3.9 or higher as per our Upgrading JIRA applications guide, as that version includes a fix for the afore-mentioned bug.


Increase the timeout

  1. Login to JIRA application as a user with System Administrator (global permission);
  2. Go to Administration > System > Outgoing Mail;
  3. Click Edit on the right of the SMTP server used to send those notifications;
  4. Under the SMTP Host section, change the value for Timeout by incrementing 10000 ms to the original value;
  5. Save the changes and check if the problem persists;
    • If so, increase the timeout by an additional 10000 ms and test again;

(warning) In case you still face problems after increasing the timeout to more than 60000 ms, please check for possible connection problems in between the JIRA application and your mail server or follow further workarounds below.

Force JIRA not to wait for the mail server to respond to a QUIT command

As described by Piotr on this comment, adding the -Dmail.smtp.quitwait=false (or -Dmail.smtps.quitwait=false for SMTPS connections) flag to the application startup options should also help resolve the problem.

Change MaxAcknowledgementDelay on Microsoft Exchange

As described by Ryan on this comment, it may be necessary to change the above property on Exchange to not have it wait acknowledgement signals from recipients expected by Exchange by default for 30 seconds.

最終更新日 2019 年 9 月 25 日


Powered by Confluence and Scroll Viewport.