Skip to main content

This content has been archived and is no longer being updated. Links may not function; however, this content may be relevant to outdated versions of the product.

Support Article

Email Listener connection timeout behavior

SA-9858

Summary



Email listeners behave irregularly.
Email server connection gets timed out and a java.net.SocketException is thrown in the Logs stating that the connection has been reset. The listener starts functioning after 25 minutes of inactivity.
This results in stagnation of unread emails in the mailboxes causing a bottleneck in processing.


Error Messages



015-04-29 10:08:14,718 [ EMAIL-Thread-16] [ STANDARD] [ ] [LServiceReq:01.03.01] ( services.email.EmailListener) ERROR EMAIL.XXX_LSNR.Listener SvcReqEmailRequestor - Caught exception while connecting to email server(s)
javax.mail.MessagingException: Connection reset;
nested exception is:
java.net.SocketException: Connection reset
at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:571)
at javax.mail.Service.connect(Service.java:288)
at com.pega.pegarules.integration.engine.internal.services.email.EmailListener.emailConnect(EmailListener.java:2680)
at com.pega.pegarules.integration.engine.internal.services.email.EmailListener.oneIteration(EmailListener.java:2291)
at com.pega.pegarules.integration.engine.internal.services.email.EmailListener.run_(EmailListener.java:2206)
at com.pega.pegarules.integration.engine.internal.services.listener.ServiceListenerBaseImpl.run(ServiceListenerBaseImpl.java:448)


Steps to Reproduce



This is a sporadic issue which can occur at any time and there is no specific use case to reproduce it.

Root Cause



The root cause of this problem lies within the network infrastructure or the email server itself.  As the listener attempts to connect, there are sporadic times when that connection is unsuccessful (yet a retry or a connection from the next run will work without any changes in the network or mail server infrastructure).

Resolution



It is possible to change the sleep/retry value for the PRPC Email Listener, according to the following detailed explanation:

The EmailListener code has a fairly complex algorithm for re-calculating the sleep time after an exception is encountered.

The purpose of this algorithm is to alter (increase) the sleep time when the current run ends with an exception - so as to implement a "black out" period after exception (with the assumption that the email server is unavailable, for example).

There are two Dynamic System Settings that can be created (or altered, if they exist):

Owning RuleSet: Pega-IntegrationEngine
Setting Purpose: email/exceptionLatency
Default value if DSS does not exist: 5 (minutes)

Owning RuleSet: Pega-IntegrationEngine
Setting Purpose: email/initialLatencyTime
Default value if DSS does not exist: 300 (seconds)


The exceptionLatency setting defines an EXCEPTION_BLACKOUT period (used as part of a calculation).
The initialLatencyTime setting is used in a subsequent calculation (a value that gets added to EXCEPTION_BLACKOUT).

The code also takes into account a RETRY variable, which keeps track of the number of failed connection attempts.

At the top of the entry routine, the listener code will set a sleep time with the formula:

EXCEPTION_BLACKOUT + optimalTimeValue(retries)

In the optimal time calculation, the email/exceptionLatency value is checked first, and if it exists, it will be set as the return value (essentially doubling the EXCEPTION_BLACKOUT value).

If there is no DSS record for email/exceptionLatency, the code will use the value for the email/initialLatencyTime DSS (or it's default), multiplied by the number of retries.

To insure a limited time spent after an exception, add a DSS for the email/exceptionLatency, with a value of 1.

Under certain situations, this results in a sleep time of 6 minutes (depending on the type of exception, a separate default of 5 minutes is used for the initial blackout at the top of the routine), but in most cases result in a sleep time of 2 minutes - unless there are multiple consecutive failures for the same listener.

Published June 12, 2015 - Updated October 8, 2020

Was this useful?

0% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us