Duplicated issue creation, comments or notifications
Issues creation, comments, or notifications are being created within JIRA applications.
Errors similar to the following appears in the
2012-03-08 13:33:59,987 QuartzWorker-0 ERROR ServiceRunner The Avengers Initiative [service.services.mail.MailFetcherService] Mail Handler: Error connecting to host 'mail.sampledomain.com' as user 'mailuser' via protocol 'pop3s': javax.mail.MessagingException: Connect failed; nested exception is: java.net.SocketTimeoutException: Read timed out ... Caused by: java.net.SocketTimeoutException: 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.
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
- Login to JIRA application as a user with System Administrator (global permission);
- Go to Administration > System > Outgoing Mail;
- Click Edit on the right of the SMTP server used to send those notifications;
- Under the SMTP Host section, change the value for Timeout by incrementing 10000 ms to the original value;
- Save the changes and check if the problem persists;
- If so, increase the timeout by an additional 10000 ms and test again;
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
As described by Piotr on this comment, adding the
-Dmail.smtps.quitwait=false for SMTPS connections) flag to the application startup options should also help resolve the problem.
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.