We have some users reporting an issue with Email Listener on versions Maximo 7.5 and 7.6 , where the emails are not getting processed without delays.
In this specific scenario that I mentioned there is some delay happening in the processing of emails by the users. They checked the Last Run time for Email listener and it was getting updated with the most recent time. They checked the Email Cron task by reloading the request for the respective schedulers it was getting updated with the most recent time. Still the email was not getting processed.
Users deactivated & activated the email listener and still the same. Then they stopped and started the cluster where the Cron was running and they could see the emails in the queue were getting processed.
After repeating the steps above, the email listener works as expected. This problem is highly intermittent
The Email Listener is the only cron task which is getting delayed. They cannot create any other cron task as this is the production server. Please note they do not have this issue in development and this functionality cannot be tested in development. All other cron tasks are working fine.
They have already used dedicated JVM to run the crons, and did not make any changes or restart the server. However after 20 min all the emails were processed automatically.
Sometimes there is a delay in processing of Emails for 40 min. They did not make any changes or restart the server. However after 20 min all the emails were processed automatically.
Upon reloading the LSNRCRON (Email listener CRON) and by Deactivation / Activation of Email listener all the pending emails were processed.
Whenever the issue occurs we manually reload the email listener CRON and deactivate / Activate the Email listener, then all the pending emails would be processed.
After some investigation :
We've been investigating the JavaMail debug logs and noted all of the IMAP FETCH statements in the logs are in increments of 16384 bytes. In this case, users are receiving attachments and the default behavior is to download them partially in small segments. We saw a 32 MB file --- that's 2048 trips to the email server 16KB at a time. It takes between 0.8 and 1 sec for each fetch and there are 5952 individual fetches indicated in the logs.
We've seen this behavior before and did some trials with various sizing parameters as well as disabling the partial fetch. Adding the property mail.imap.fetchsize and adjusting the fetch increment (or setting it to false) should improve performance. What you should set this to is up to you, as there is not a recommendation for a specific value that Support offers. As the article suggests, you should test to determine what works well for the environment.
Email Listener: Reducing IMAP Message Fetch Latency Due to Large Attachments
The caveat here, though the time should be significantly reduced, it will still take some amount of time to process large attachments, a period with which you may not be absolutely happy with. That is the cost of receiving very large attachments. Further, you have the listener polling the email server every minute. You may want to consider stretching this out a bit so that the server has sufficient time to clear the INBOX before the cron runs again. This and the fetch size may have been causing a train wreck. :)