Boxクロールが最初の接続で止まったように見えるとき、ファイル取得より前のトークン交換で待っている可能性があります。fess-ds-boxに、初回の認証通信にもタイムアウトを適用する修正が提案されています。
タイムアウトを設定する前に認証していた
従来の接続生成は、キャッシュにトークンがなければBox SDKのファクトリー内部で認証を始めます。connect_timeoutやread_timeoutの設定は、その接続が返された後でした。クロールの最初の接続では、設定値が最初のトークン交換へ届かない問題がありました。
提案では未認証の接続を作り、プロキシ、接続・読み取りタイムアウト、再試行回数を設定してからトークンを取得します。ユーザーを指定する接続にも同じ順序を適用します。
初期値は待ち時間を制限しない
両パラメーターの初期値は0で、正の値の場合だけSDKへ設定します。単位はミリ秒です。たとえば次は接続5秒、読み取り30秒という設定例です。
connect_timeout=5000
read_timeout=30000
修正案を含む対応プラグインを用意した検証環境で、データストアのパラメーターとして設定し、認証から少量の文書取得まで確認します。これは推奨初期値ではなく、回線やBox側の応答時間に合わせて調整する例です。再試行を含むジョブ全体が30秒以内に終わるという保証でもありません。
最深部の例外だけで判断しない
27では接続失敗の例外チェーンを順番に表示します。従来はSocket closedという最深部だけが見え、その途中のSocketTimeoutExceptionが隠れる場合がありました。原因が複数段あれば、途中のtimeoutも確認します。
応答が不正な場合の例外までタイムアウトとして扱う変更ではありません。たとえば認証先が必要なトークンを欠くJSONを返した場合は別の原因になります。ログの改善と待ち時間の制御を分けて確認すると、ネットワークと認証設定の切り分けがしやすくなります。