Mmmm, What JDK are you running on and with which operating system (Windows judging by your IDE)?
And did you compile the river code yourself or is this straight from the download pages? I'd at least be curious about running javap on ConnectionManager to see what the bytecode looks like. If that's solid I'd be expecting a JIT problem or similar assuming the stacktrace is correct. On 21 September 2011 17:58, Christopher Dolan <[email protected]> wrote: > That's a good thought, but I think it's the right stack. I have the > stacktrace in a screenshot, but not in text (sorry). It looks pretty > straightforward: > http://i.imgur.com/UPPQS.png > Chris > > -----Original Message----- > From: Tom Hobbs [mailto:[email protected]] > Sent: Wednesday, September 21, 2011 11:53 AM > To: [email protected] > Subject: Re: What can cause IllegalMonitorStateException from inside a > synchronized block? > > It looks alright to me. Can you post the whole stack trace? > > I see that muxLock is not private, could something else be calling > wait/notify from outside this class and outside a sync block? > > > > Grammar and spelling have been sacrificed on the altar of messaging via > mobile device. > > On 21 Sep 2011 17:13, "Christopher Dolan" <[email protected]> > wrote: >> This may not actually be related to River, but it's a very curious bug > that happens in River code. I posted the detailed question here: >> >> > http://stackoverflow.com/questions/7502905/what-can-cause-illegalmonitorstateexception-from-inside-a-synchronized-block >> >> The short version is that we're getting IllegalMonitorStateException > thrown from code that looks like this: >> >> synchronized (lock) { >> lock.wait(timeout); >> } >> >> Shouldn't be possible, right? The River code in question is here: >> > http://svn.apache.org/viewvc/river/jtsk/trunk/src/com/sun/jini/jeri/internal/mux/Mux.java?view=markup#l222 >> >> Chris >> >
