Just had a thought. Are you using any jni third party packages, or pure jni or something swig generated?
I ask only because I had a situation (non-river though) where a third party tool wasn't certified for a c++ dll only c ones. After a dll upgrade the system suddenly and strangely started to fail. We removed the jni helper library and the problem disappeared. I know your situation is the other way around (I was initiating java to call native dll) but thought it might be worth a punt. Grammar and spelling have been sacrificed on the altar of messaging via mobile device. On 22 Sep 2011 16:11, "Christopher Dolan" <[email protected]> wrote: > Agreed, and furthermore our code is definitely not doing any weaving or reflection skullduggery that could break that "final". > > No, no special GC options. Except being launched via JNI, I believe it's a pretty straightforward JVM argument list: just classpath and a handful of "-D" options. But I should double check that... > > A JIT re-ordering bug is a scary thought. I'd think that this problem would be seen more widely if that were the case. > > Chris > > -----Original Message----- > From: Dan Creswell [mailto:[email protected]] > Sent: Thursday, September 22, 2011 8:54 AM > To: [email protected] > Subject: Re: What can cause IllegalMonitorStateException from inside a synchronized block? > > final Object muxLock = new Object(); > > I believe that should mean muxLock cannot change.... > > > On 22 September 2011 14:29, Sim IJskes - QCG <[email protected]> wrote: >> On 22-09-11 14:38, Sim IJskes - QCG wrote: >>> >>> On 22-09-11 14:32, Sim IJskes - QCG wrote: >>>> >>>> On 22-09-11 14:04, Christopher Dolan wrote: >>>>> >>>>> It's quite reproducible, but only in integration not in isolation >>>>> (yet). It was discovered as a hang in QA, then after several >>>>> reproductions, someone attached a debugger and found that surprising >>>>> exception. >>>>> >>>>> We've discovered that switching from Sun Java 1.6 back to 1.5 makes >>>>> it go away. >>>>> >>>>> One noteworthy fact I've since learned (and it's obvious from the >>>>> stacktrace in retrospect): this is a C++ thread and the root of the >>>>> Java stack comes from C++ via JNI. In theory that shouldn't matter, >>>>> right? But that's sure has a suspicious smell to me. >>>> >>>> I guess the exception is created JNI side. >>> >>> Are you using special garbage collector options? Can you try without? >>> >>> Gr. Sim >>> >>> >> >> Just to be sure. muxLock is garantueed to be constant during the execution >> of this code is it? No other thread assigning some other instance to it? >> >> Gr. Sim >> >> -- >> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl >> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397 >>
