...
A FolderClosedException is caused when the connection between Jira and the inbound Mail server is closed abruptly by the mail server whilst mail is being retrieved. This is caused by the configuration of your mail server, and the Jira environment.
Is this a JEMH bug?
No, this is not a bug, it's just the consequence of your mail-server closing the connection to JEMH/C whilst the mail was still being read (by JEMH). It is not caused by JEMH/C and cannot be solved by JEMH/C. See Impact and Migration steps possible:
Impact
When a FolderClosedException occurs, it stops all mail processing, specifically, as the mail was not read fully:
it was not processed at all, will not be consumed / marked read and will be retried
it will not be available in JEMH Auditing and cannot be exported as part of the support zip
Mitigation
Your mailserver can drop connections for two main reasons:
Too many concurrent logins using the same account
Your mailserver may simply kill off the one that is oldest, which was unfortunately still in use. To check if this is a problem, count how many inbound mail servers you have defined using the same account. If its more than 15 you could be affected.
Mails are taking too long to download
The mailserver may determine the connection ‘dead’ if it takes too long. This can be caused by large emails for some IMAP servers. See IMAP batch sizes too low, below for background, steps to verify if this problem affects you, and action you can take to increase the default batching size as described in Download performance of POP vs IMAP
Background
What you see in JEMH Auditing
Current versions of JEMH prevent the ‘download’ button operating and show the following information dialog:
...
| Code Block |
|---|
2013-07-12 09:52:50,478 ERROR [xxx] QuartzScheduler_Worker-3 ServiceRunner xxxx[xxxxx]: Exception: null javax.mail.FolderClosedException at com.sun.mail.imap.IMAPMessage.getProtocol(IMAPMessage.java:145) at com.sun.mail.imap.IMAPMessage.getHeader(IMAPMessage.java:743) at com.atlassian.jira.service.services.mail.MailFetcherService$MessageProviderImpl.getAndProcessMail(MailFetcherService.java:257) at com.atlassian.jira.service.services.mail.MailFetcherService.runImpl(MailFetcherService.java:356) at com.atlassian.jira.service.services.file.AbstractMessageHandlingService.run(AbstractMessageHandlingService.java:257) at com.atlassian.jira.service.JiraServiceContainerImpl.run(JiraServiceContainerImpl.java:61) at com.atlassian.jira.service.ServiceRunner.execute(ServiceRunner.java:48) at org.quartz.core.JobRunShell.run(JobRunShell.java:195) |
Is this a JEMH bug?
No, this is not a bug, it's just the consequence of your mail-server closing the connection to JEMH/C whilst the mail was still being read (by JEMH). It is not caused by JEMH/C and cannot be solved by JEMH/C. See Impact and Migration steps possible:
Causes
When a FolderClosedException occurs, it stops all mail processing, specifically, as the mail was not read fully:
it was not processed at all, will not be consumed / marked read and will be retried
it will not be available in JEMH Auditing and cannot be exported as part of the support zip
Mitigation
Your mailserver can drop connections for two main reasons:
Too many concurrent logins using the same account
Your mailserver may simply kill off the one that is oldest, which was unfortunately still in use. To check if this is a problem, count how many inbound mail servers you have defined using the same account. If its more than 15 you could be affected.
Mails are taking too long to download
The mailserver may determine the connection ‘dead’ if it takes too long. This can be caused by large emails for some IMAP servers. See IMAP batch sizes too low, below for background, steps to verify if this problem affects you, and action you can take to increase the default batching size as described in Download performance of POP vs IMAP