Imapd Does Not Log (nor Telemetry) The Action Which Took So Long That The Client Gave Up (Doc ID 2922333.1)

Last updated on AUGUST 22, 2023

Applies to:

Symptoms

On:  Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)

Imapd does not log (nor does telemetry) the action which took so long that the client gave up.

A problem occurred where mail for a specific recipient was building up in the queue on the backend.
After dbhang / pstack / imcheck -s analysis, it looked like a lot of imapd threads were all trying to update flags.
IMAP telemetry was enabled for the user and found continuing new sessions doing:

It looked like the root cause must be something on the client side.
Yes, the user has a big INBOX and that would contribute to performance problems, but ...

It looks like the client fired off multiple instances of these at the same time which caused the initial bottleneck. Then, when they took a long time, it timed out and reconnected and repeated them, perpetuating the problem.

The point of this issue is that NEITHER the transaction log nor telemetry logged the completion of the action which took so long -- because the client had closed the connection before it completed. If that had been logged, the repeated flag changes would have been observed in the log file and traced back to when they started.

Imapd should log the completion of the action and then the fact that the session has ended. The same applies to telemetry.

It is expected that both imapd and telemetry should log the completion of the action and then the fact that the session has ended.
Due to this issue, it is very difficult to determine what was going on and this logging defect makes it impossible to determine root cause.

Changes

Cause