AgileWorksでフォームのアップロードが完了しない｜処理は成功していて、切れていたのはApacheだった

AgileWorksでフォームだけをアップロードしたところ、画面の処理が完了しませんでした。処理中の表示が出たまま、完了画面へ進みません。ログインも申請も承認も普通に使えていたので、ファイル側の問題なのか、AgileWorks側の問題なのか、この時点では判断できませんでした。

先に結論を書きます。アップロード処理そのものは成功していました。失敗していたのは、結果をブラウザへ返す部分だけです。ApacheとTomcatの間で約60秒でタイムアウトが起きていた一方、実際の処理には約68秒かかっていました。恒久対応として、Apache側のタイムアウトを100秒へ延長しています。

画面は完了しないのに、フォームは反映されていた

症状はシンプルで、フォームファイルを選択してアップロードを開始すると、完了画面へ進まず処理中の表示が続く、というものです。AgileWorksへのログイン、申請画面の表示、申請データの登録、承認操作は、どれも問題ありませんでした。

おかしいと思ったのは、アップロード後にフォームの状態を見たときです。対象のフォームは、最新バージョンとして反映されていました。画面上は失敗したように見えるのに、結果だけは正しく残っている。この食い違いが、原因を絞り込む手がかりになりました。

もし画面の表示だけを見て失敗と決めつけていたら、再アップロードを何度も繰り返していたはずです。重い処理を無駄に走らせるうえに、状態がさらに分かりにくくなります。画面が完了しないときほど、結果がどうなっているかを先に見たほうがいいと実感しました。

原因はApache–Tomcat間のタイムアウトだった

AgileWorksのサポートへ問い合わせ、ログを確認してもらいました。該当のアップロード要求に対して、約60秒後にApache–Tomcat間でタイムアウトが発生していたことが分かりました。

実際のアップロード処理にかかっていた時間は、約68秒です。処理が終わる8秒前に、手前のApacheが接続を切っていたことになります。

アップロード処理自体にエラーは出ておらず、フォームデータが不正な状態になったわけでもありません。Tomcat側は最後まで処理を終えていて、その結果を受け取るはずのApacheが、先に待つのをやめていた。それだけでした。

出典：core – Apache HTTP Server Version 2.4

AgileWorksのサーバー側で起きた障害としては、ジョブマネージャーがGC overhead limit exceededで停止した件もあります。こちらはJava VMのヒープ不足が原因でした。

再アップロードは不要と判断した

障害対応では、原因を取り除く前に、滞留したデータをどうするかを決めなければなりません。今回は次の2点を確認して、追加の対応は不要と判断しました。

• 対象フォームが、最新バージョンとして反映されていること
• アップロード処理自体にエラーが出ておらず、フォームデータが不正な状態でないこと

この2つが確認できたため、再アップロードは行っていません。画面が完了しなかったからといって機械的にやり直すと、同じ重い処理をもう一度走らせることになりますし、バージョンが余計に増えます。

そのあと、反映されたフォームを使って申請画面を開き、入力と保存まで確認しました。管理画面で反映済みと表示されていても、実際のフォームが使えなければ意味がないためです。

Apacheの設定ファイルにtimeoutを追記した

恒久対応として、Apache側のタイムアウトを延長しました。修正したのは、Apacheのインストールディレクトリ配下にあるAgileWorks用の設定ファイルです。

(Apacheインストールディレクトリ)/conf/extra/httpd-agileworks.conf

このファイルの ProxyPass に timeout= を追記します。

# 修正前
ProxyPass ajp://localhost:8009/AgileWorks/

# 修正後
ProxyPass ajp://localhost:8009/AgileWorks/ timeout=100

ここで意識したのは、httpd.conf の Timeout を全体的に変えるのではなく、AgileWorksへ振り分けている ProxyPass にだけ指定することです。サーバー全体のタイムアウトを延ばすと、AgileWorks以外の通信にも影響します。時間のかかる処理が特定の経路に限られているなら、その経路だけを延ばすほうが影響範囲を抑えられます。

100秒という値は、どの環境にも当てはまる推奨値ではありません。実際の処理時間が約68秒だったので、余裕を持たせて決めた数字です。設定変更の前に対象ファイルのバックアップを取得し、変更前後の値、作業日時、作業者、変更理由を記録しました。

タイムアウトを延ばすときに考えたこと

タイムアウトを長くすれば、処理が終わるまで接続を維持しやすくなります。ただ、応答しない処理も長く残ることになるので、サーバーの負荷は増える方向へ働きます。極端に大きな値にはせず、処理時間と負荷を見ながら調整する前提で設定しました。

もう一つ意識したのは、通信経路上にタイムアウトが複数あるという点です。ブラウザ、Apache、Tomcat、AgileWorksと経由する中で、一番短い値が先に効きます。今回はApacheが60秒で切っていたので、そこを延ばせば解決しました。仮にTomcat側にもっと短い値があれば、Apacheを100秒にしても改善しません。

それから、タイムアウトは原因そのものではなく、処理時間が延びた結果として表面化することもあります。以前より明らかに遅くなっているなら、CPU、メモリ、ディスク、データベースの応答も見たほうがよさそうです。今回は、フォームアップロードという処理がもともと重く、それが初期値の60秒を超えたという構図でした。

ApacheやTomcatを含むAgileWorks固有の設定を保守する負担も、製品構成を考える材料になります。PleasanterとAgileWorksの統合・併用の判断軸では、機能だけでなく障害対応や保守の負荷も比較しました。

同じ症状が出たときに確認する順番

今回の件を踏まえると、画面が完了しない障害は次の順で見ると整理しやすいと思っています。

• 結果がどうなっているかを先に確認する（処理は成功していないか）
• 操作開始から画面が止まるまでの時間を測る
• 毎回ほぼ同じ秒数なら、固定値のタイムアウトを疑う
• その秒数と一致する設定値が、経路上のどこにあるか探す
• 別の利用者、ブラウザ、端末でも再現するか確認する
• 設定変更後は、対象機能だけでなく通常機能もテストする

特に1つ目です。画面が完了しないと、つい失敗したものとして扱ってしまいます。今回はそこを確認したおかげで、再アップロードを避けられました。

まとめ

AgileWorksでフォームのアップロードが完了しなかった原因は、Apache–Tomcat間のタイムアウトでした。処理に約68秒かかっていたのに対し、Apache側は約60秒で接続を切っています。60秒はApacheの初期値で、誰かが設定した値ではありません。

そして、アップロード処理そのものは成功していました。フォームは最新バージョンとして反映され、データも壊れていません。画面が完了しないことと、処理が失敗していることは別物でした。

恒久対応は、AgileWorks用の設定ファイルにある ProxyPass へ timeout=100 を追記しただけです。サーバー全体ではなく、対象の経路だけを延ばしています。

毎回ほぼ同じ秒数で画面が止まるなら、固定値のタイムアウトを疑ってみてください。設定を変える前に、その処理が本当に失敗しているのかを確認しておくと、余計な作業をせずに済みます。