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 >
