IMAP4でFETCH要求後にログアウトしても、サーバ側の処理が続きCPU負荷が高い状態となることがある new!
クライアント側で処理を終了したように見えても、サーバ側では要求の処理が継続している場合があります。サポートによるログ解析結果と、確認時の注意点を説明します。
【回答】
クライアント側でログアウトや終了を行っても、E-Post IMAP4サーバ側で実行中のFETCH処理が直ちに中断されるとは限りません。サポート回答では、受け付けた要求の処理が継続し、その間CPU負荷が高い状態となる場合があることを、E-Post IMAP4サーバの仕様上想定される動作として説明しました。
【要求の送信と処理完了は別】
IMAP4ではサーバ側の処理完了を待たずにクライアントが次の要求を出せるため、FETCH要求後にLOGOUT要求を出すことも可能です。ただし、LOGOUT要求の送信、サーバによるLOGOUT処理の完了、通信切断、実行中のFETCH処理の終了は、それぞれ区別して確認する必要があります。クライアント側でLOGOUT要求を出したことだけで、サーバ側の処理がすべて終了したとは判断できません。
【ログ解析で確認された事例】
サポート案件で実際に確認したログでは、セッション番号01c78040で15:57:45にログインし、16:06:15にUID FETCHが開始されました。その後も同じセッションでFETCH応答が続き、16:17:51にもメール本文の応答が記録されています。16:17:56には「send() SOCKET_ERROR OTHER CODE=10053」が記録され、サポートはこの時点で切断されたと見ています。16:17:51は正常完了応答を確認した時刻ではなく、少なくともその時刻まで処理が続いていたことを示す記録です。
【LOGOUTの記録を同一セッションと決めつけない】
同案件のログには、上記ログイン直後の時間帯に16:10:37のLOGOUTも記録されていましたが、UID FETCH開始時とは接続元IPアドレスが異なっていました。サポート回答では、このLOGOUTは別のログインに対応する可能性があることを示し、たとえ同じアカウント名であっても、別端末・別接続の記録を一つの処理や同一セッションとして決めつけないようにしてください。本事例のLOGOUTが、上記FETCHと同一セッションであると確認されたわけではありません。
【「延々と続く」の意味】
ここでいう「処理継続」とは、受け付けた要求を処理している状態を指します。「必ず無限に処理する」「切断後も必ず全件を正常完了する」という意味ではありません。本事例でも処理途中の応答に続いて送信エラーが記録されています。クライアント終了後のCPU高負荷だけで異常や無限ループと断定せず、詳細ログで処理の進行と終了状況を確認してください。
【確認手順】
- IMAP4ログ（imap4log）とIMAP4詳細ログ（receiveimap4）を取得し、対象時刻のアカウント、接続元IPアドレス、セッション番号を確認します。
- IMAP4詳細ログをセッション番号ごとに抽出し、LOGIN、UID FETCH、FETCH応答、LOGOUT、送信エラーの順序を確認します。
- FETCH応答のメール番号やUIDが進んでいるかを確認し、処理が継続している状態と、同じ要求を繰り返している状態を区別します。
- LOGOUTが対象FETCHと同じセッションに属するか確認します。アカウント名と時刻が近いことだけでは同一接続と判断しません。
- 正常完了応答、切断、エラーの記録を確認します。高負荷が続き処理の進行も確認できない場合は、対象セッションの詳細ログと負荷の発生時刻をサポートへ提示してください。
※本FAQはサポート案件に基づきます。記載の動作説明は当該E-Postのサポート案件に関するものであり、すべてのIMAP4サーバが同じ中断・終了動作を行うと保証するものではありません。