不幸は忘れたころにやってくる - OutOfMemoryError 2016/12/29


この一年、レガシーな環境の開発に参加させてもらっています。
java1.4で、各種ライブラリは、2006年、ほっとだったspring,hibernateのバージョンそのままです。

それで不幸は忘れた頃にやってくるわけですが、OutOfMemoryErrorがぽこぽこ発生。

結論からいいますと、java1.4と使用していたcommons-fileuploadの組み合わせが原因。

こちらのブログの内容が、まさにヒットでした。

File.deleteOnExit() を使用していたライブラリ - HHeLiBeXの日記 正道編

java1.4のdeleteOnExitは、メモリーリークというか、使ったらシステムが落ちるまで掴みぱなしでCヒープが消費されていきます。

javaヒープは十分にあるようにみえました。gcも動いてるし、なのにALLOCATION FAILUREがおきて、コアをはいてずどーんと落ちます。

javaヒープ、CヒープとOutOfMemoryErrorについての説明は、下記の記事がよかったです。こういう記事はずーと残って欲しいな。
2010年の記事です。

現場にキく、Webシステムの問題解決ノウハウ(4):調査の難しい「OutOfMemoryError」事例、5選 - @IT
Native Methodの呼び出しでのOutOfMemoryErrorですね。はい。

いろいろ不運な要素が重なりました。

WEBのアプリケーションは1日一度再起動されるので、これが数千件程度の呼び出しであれば、問題は発覚しなかったのでしょう。

わかったのは、strutsとこのバージョンのcommons-fileuploadですと、画面のformの項目数分、File.deleteOnExit()が呼ばれるのでした。
そして、画面の項目数が100以上あり、submitするたびにFile.deleteOnExit()が呼ばれます。

それで、上のブログの記事を参考に、fileuploadのバージョンを1.1にあげました。ただし、このバージョンのfileuploadは、commons-ioを必要とします。

依存ライブラリがひとつ増えてしまう。。。

commons-fileupload – Home
Commons IO – Commons IO Overview
いまの時代、1.4に対応したものってold versionの深い闇にしかないんですよね。
そして上記のブログには続きがあるようで、Commons IOにも何かしら問題が潜んでいるようでして。。。
Webアプリケーション開発の際の注意事項(3) - HHeLiBeXの日記 正道編

この問題まだ続くのかな(笑)

さて、何年も、メモしてきたこのブログですが、今年は2回しか、書けていなかったです。いろいろ知見を得ることができた1年だったのですが、メモしなかったのは反省です。来年(2017年)こそは。。。。

: