This issue has been ongoing for the last week, and was only noticed when one of our technicians mentioned that they had not received any notifications from the service desk. Upon checking the mail queue, it was discovered that the queue was significantly backed up. Manually flushing the queue was successful at resolving the issue temporarily. However, the issue still occurs afterwards.
Version of JIRA Service Desk: 4.2.0
Version of JIRA Core: 8.2.0
No additional plugins.
Hi Ryan,
Sorry to hear about this problem. I can see that Jira seems to be working when forced to clear and manually sending test message, but that the mail queue appears to be frequently getting stuck with messages. I was able to take a closer look at your support zip from the other ticket and I found a number of errors in the logs Jira has that appear to be related to this problem:
Caused by: com.sun.mail.util.MailConnectException: Couldn't connect to host, port: smtp.office365.com, 587; timeout 0;
nested exception is:
java.net.UnknownHostException: smtp.office365.com
Which just tells us that at the time Jira is trying to send that message, it appears to be getting an unknown host error. This makes me believe this is a networking problem. For some reason at that specific time, the application can't reach that host. That does seem strange and combined with the fact that you can send out test messages and manually flush the queue, it sounds like this probably is happening intermittently.
I came across a related Confluence KB article in https://confluence.atlassian.com/confkb/mail-fails-to-send-intermittently-with-unknown-smtp-host-error-789087034.html
The error message is the same, so perhaps you can try the same steps here to see if this might help with Jira. That KB seems to have narrowed the problem down to SMTP hosts that use a dynamic and frequently changing set of IP addresses (I'm confident that outlook meets that criteria). Should an application like Jira or Confluence have a stale DNS cache of that addresses lookup IP then perhaps that might cause this problem.
The resolution of that KB is to set the networkaddress.cache.ttl=60 in order to force the java application (like jira or confluence) to keep a much shorting interval of network address cache than default. You can do that by going to the $JAVA_HOME/jre/lib/security/java.security
file and setting a value of
networkaddress.cache.ttl=60
Granted that changes to this file would require you to save and restart Jira before they took affect.
I hope this helps.
Andy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.