ここで少し興味深いのは、アプリの 1 つで (IBM 64 ビット JVM で) Dozer (5.3.2) を実行していることです。先週の金曜日、JVM が一般保護違反を発したため、本番環境のボックスの 1 つが突然停止しました。残念ながら、当時何が起こっていたかを示す有用なログはありませんが、JVM の javacore ファイルは、Dozer の DozerBeanMapper でコードを実行しているときに問題が発生したことを示しています。
1XMCURTHDINFO Current thread
NULL ----------------------
3XMTHREADINFO "WebContainer : 70" J9VMThread:0x0000000011B1C600, j9thread_t:0x00002AAAC4F95920, java/lang/Thread:0x000000012D92E198, state:R, prio=5
3XMTHREADINFO1 (native thread ID:0x6BE2, native priority:0x5, native policy:UNKNOWN)
3XMTHREADINFO2 (native stack address range from:0x00002AAAC2CD4000, to:0x00002AAAC2D15000, size:0x41000)
3XMTHREADINFO3 Java callstack:
4XESTACKTRACE at org/dozer/DozerBeanMapper.getMappingProcessor(DozerBeanMapper.java:184)
1INTERNAL Unable to walk in-flight data on call stack
DozerBeanMapper の Dozer ソースをざっと見てみると、javacore ログに報告されているコード行がSun のjava.util.concurrent.atomic.AtomicBooleanを使用していて、それ自体がsun.misc.Unsafeを使用していることに気付きました。それについて理解していることからsun.misc.Unsafe、JVMによって通常公開されるよりも、むしろ直接的かつ任意のメモリ割り当て機能が可能になります。私はもちろんここで推測していますが、私たちが見た gpf が Dozer のsun.misc.Unsafe.
残念なことに、アプリケーションで複数の DozerBeanMappers を使用しているため、さらに複雑になっています (修正に取り組んでいます... コードを継承するのは楽しいことではありません)。これらのマッパーは、リクエストごとではなく、アプリの起動時に少なくとも 1 回だけインスタンス化されます。
残念ながら、問題を再現する方法をまだ理解していないので、自分の理論を証明/反証する方法を考えるのに苦労しているので、試しながら情報を収集しようと思いました. Dozer を使用しているときに gpf の状況を経験した人はいますか? 複数の DozerMapperBeans の使用が問題を引き起こしている可能性はありますか?
あらゆる考えに感謝し、
エド