Long delay in processing incoming email

[Simon Gao]

Hi Andy,

Today we notice one email was siting in the inbox for 18 minutes before it was added to JIRA. We have 6 profiles. One of the profiles should pick up the email and add it to JIRA. All the profiles are set run every 1 minute.

Where the delay came from? Shouldn't all the profiles scan the mailbox every 1 minute? Or each profile runs in sequence?

What we can do to prevent this from happening?

Another quest is JEMH 1.2.79 still does not clean up emails that can't be added to JIRA. As a result, I saw emails dated back Nov 5, 2012 still left in the mailbox. This made the mailbox continuously grow. When the feature will be available?

Thanks,

Simon

[Andy Brook [Plugin People]]

Q1. Assuming your JIRA server is not overloaded, underpowered etc (check CPU, disk IO contention etc), usually the delay comes from an overloaded mail server, you can get some indication of whats going on my enabling JIRA mail debugging: https://confluence.atlassian.com/display/JIRA/Logging+email+protocol+details

JEMH was written to solve scalability issues, with only 6 profiles (equivalent to having 6 standard JIRA mail handler configurations) I would not expect any performance degredation caused by JEMH.

Q2. Audit History purging was reworked in 1.2.74, its possible some 'old' content has not been purged, can you confirm that 'recent' history has been purged, according to your retention settings? If in doubt there is a 'Delete All Events' link on the Audit history page, that will flush everything and give you a clean start.

Again, please review your open questions, mark any answered that are, comment on those that are not? Doing so helps me know Ive solved your problem, helps others see a succsessful resolution to perhaps the same?

[Simon Gao]

Our server has 8 CPUs, 16G memory, 8G allocated for JIRA/Tomcat. It's the JIRA/Tomcat process consumes 100% CPU all the time. The mail server is on the same machine and only account is for JIRA email. The mailbox is about 12MB in size. I doubt mail server is a bottleneck.

Many times I saw JIRA/JEMH not making connection to the mail server until I restarted JIRA. So what's the reason for JIRA not to connect to a mail server? Messed up Quartz scheduler?

I tried "Delete All Events". My browser crashed while waiting for response to the page. I have to restart my browser. I am going to try it again.

Simon

[Simon Gao]

{noformat}

2013-02-18 10:50:55,438 ERROR [JIRA IMAP server] QuartzWorker-0 anonymous JEMH JEMH[10001]: Exception: null
javax.mail.MessageRemovedException
at com.sun.mail.imap.IMAPMessage.checkExpunged(IMAPMessage.java:205)
at com.sun.mail.imap.IMAPMessage.getSentDate(IMAPMessage.java:361)
at com.javahollic.jira.emh.service.DefaultJEMHMailManager.updateContextForMessage(DefaultJEMHMailManager.java:1153)
at com.javahollic.jira.emh.service.DefaultJEMHMailManager.sendForwardEmail(DefaultJEMHMailManager.java:513)
at com.javahollic.jira.emh.service.EnterpriseMessageHandlerImpl.handleException(EnterpriseMessageHandlerImpl.java:362)
at com.javahollic.jira.emh.service.EnterpriseMessageHandlerImpl.handleMessage(EnterpriseMessageHandlerImpl.java:244)
at com.javahollic.jira.emh.service.EnterpriseMessageHandlerProxy.handleMessage(EnterpriseMessageHandlerProxy.java:44)
at com.atlassian.jira.service.services.mail.MailFetcherService$1.process(MailFetcherService.java:361)
at com.atlassian.jira.service.services.mail.MailFetcherService$MessageProviderImpl.getAndProcessMail(MailFetcherService.java:264)
at com.atlassian.jira.service.services.mail.MailFetcherService.runImpl(MailFetcherService.java:349)
at com.atlassian.jira.service.services.file.AbstractMessageHandlingService.run(AbstractMessageHandlingService.java:250)
at com.atlassian.jira.service.JiraServiceContainerImpl.run(JiraServiceContainerImpl.java:61)
at com.atlassian.jira.service.ServiceRunner.execute(ServiceRunner.java:47)
at org.quartz.core.JobRunShell.run(JobRunShell.java:195)
at com.atlassian.multitenant.quartz.MultiTenantThreadPool$MultiTenantRunnable.run(MultiTenantThreadPool.java:72)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)

{noformat}

[Andy Brook [Plugin People]]

OK, great, sounds like plenty of resources for your JIRA.

I wonder if there are other systems/configs/users makes use of the same mailbox JEMH uses.

Some background; JIRA is responsible for scheduling mailbox polls, it drives mail handlers when mail is found. I'm sure there would be safeguards in place to stop polling whilst 'handling' was already underway, without more detailed logs its hard to say.

From the looks of the message above, JEMH was trying to forward a mail as it could not be processed for some reason, yet when it tried to , found that the message had been removed. This is curious because, until the 'forwarding' is completed, JEMH will not actually have indicated to JIRA that the message should be removed.

To rule out any possible access issue, I would check existing mailhandler configuration in your JIRA and possible event change the mailbox password to rule out external usage.

Forums aren't the best place for detailed support triage, e.g. you aren't able/advised to post logs here. Creating issues in the JEMH Jira would be better.

If the automated clean up is not adequate/working for you, a manual method is possible: https://javahollic.atlassian.net/wiki/display/JEMH/Common+Problems#CommonProblems-AuditHistoryistoolarge , current releases (1.3.x) include a feature to 'autodelete' successfuly processed traffic, this measure was specifically to help reduce retained history and related clear up problems.

[Simon Gao]

I created a new ticket JEMH-1197.

[Simon Gao]

I can't create new comment anymore on JEMH-1197. Since making the Subject data type change, I have not seen the long delay problem. Could it be fixed by the data type change?

[Andy Brook [Plugin People]]

Its possible, as I cant reproduce your enviroment I can only guess. You should be able to comment on that issue, you're the reporter. I'll resolve that issue pending further info.