Bit of a curious one here, we're running Dozer (5.3.2) in one of our apps (in an IBM 64bit JVM). Last Friday one of our production boxes suddenly came to a halt as the JVM emitted a general protection fault. Unfortunately we don't have any useful logging to show us what was going on at the time however the JVM's javacore file suggests that the issue occurred whilst executing code in Dozer's 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
I took a quick look at the Dozer source for DozerBeanMapper and noticed that the line of code which is reported in the javacore log uses Sun's java.util.concurrent.atomic.AtomicBoolean which itself uses sun.misc.Unsafe. From what understand about sun.misc.Unsafe it allows rather more direct and arbitrary memory allocation capabilities than would usually be exposed by the JVM. I am of course speculating here but that got me wondering whether the gpf that we saw could have been related to Dozer's use of sun.misc.Unsafe.
To further complicate things we are unfortunately using multiple DozerBeanMappers in our application (something we're working towards fixing... isn't it fun inheriting code). These mappers are at least instantiated only once at app-startup time rather than on a per-request basis.
Unfortunately I haven't yet figured out how to replicate the issue so thought I'd gather some information while I try and do so as I'm currently struggling to think how I might prove/ disprove my theory. Has anyone else experienced any gpf situations when using Dozer? Is it likely that our usage of multiple DozerMapperBeans is causing the issue?
Grateful for any thoughts,
Edd
