Hi Kaj, It seems like you didn't add any ThreadPoolFilter. Calling session.close(true) causes the current thread wait for the SocketIoProcessor to close the underlying channel. If you didn't add a ThreadPoolFilter, then this means you are running in the same context with SocketIoProcessor. This is a kind of deadlock. Please add a ThreadPoolFilter, or call session.close(false) instead of close(true).
Now you see the thread dump is very important to track down a problem. ;) Trustin On 8/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Oh, that was not the problem. Creating the JIRA was the problem :) I just didn't think that the thread dump was important, since it doesn't contain much information. Thread[SocketIoProcessor] Object.wait(long) line: not available [native method] SocketSession(Object).wait() line: 474 SocketSession.close(boolean) line: 137 DatastructureProtocolHandler.exceptionCaught(IoSession, Throwable) line: 438 As I said, the calling thread gets blocked in the wait. > -----Original Message----- > From: Niklas Therning [mailto:[EMAIL PROTECTED] > Sent: 30 August 2006 16:07 > To: [email protected] > Subject: Re: Problem during upgrade from 0.7.3 to 0.8.2 > > To get a thread dump on Windows hit Ctrl+Break in the console window > running your application. The thread dump will be written on > the console. > > To get a thread dump on Linux/Unix hit Ctrl+\ in the console > window or > send the QUIT signal to the process like this: > > kill -3 <pid> > > where <pid> is the id of your Java process. The thread dump will be > written to the console (or wherever you've directed stdout). > > HTH > > /Niklas > > [EMAIL PROTECTED] wrote: > > Hi, > > > > I don't know how to do that, and I don't know what to add > except for the > > information which I already have posted. > > > > This worked as a workaround: > > > > public void exceptionCaught(final IoSession session, Throwable > > e) throws Exception { > > String logString = "Caught exception on session: " + > > session + " "; > > if (session instanceof BaseSession) { > > logString += " remote: " + > > ((BaseSession)session).getRemoteAddress() + " "; > > } > > LOGGER.warn("exceptionCaught", logString + > > e.getMessage()); > > //XXX: Workaround for bug(?) in MINA 0.8.2. > > //session closed can't be invoked by calling thread. > > Could be > > //changed so that it uses a thread pool > > new Thread() { > > public void run() { > > //This call will block calling thread so > > no one can do > > //notify if we don't spawn a new thread > > session.close(true); > > } > > }.start(); > > } > > > > > > > >> -----Original Message----- > >> From: Trustin Lee [mailto:[EMAIL PROTECTED] > >> Sent: 22 August 2006 06:56 > >> To: [email protected] > >> Subject: Re: Problem during upgrade from 0.7.3 to 0.8.2 > >> > >> Could you please open a JIRA issue which attaches your full > >> thread dump? > >> > >> Thanks in advance, > >> Trustin > >> > >> On 8/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >>> Hi, > >>> > >>> I have some problems during upgrade from 0.7.3 to 0.8.2. I > >> think I can > >>> write a work around for the problem, but I'm not sure how > things are > >>> supposed to be. > >>> > >>> The scenario is that a client connection which implements > >> IoHandler has > >>> a connection towards the server. The session on the > >> connection should be > >>> removed if the connection is terminated, and I should > also inform my > >>> upper layers about the disconnect. > >>> > >>> This is how the flow was in 0.7.3 when a disconnect was > >> detected (Remote > >>> end is abruptly disconnecting): > >>> > >>> exceptionCaught -> session.close(true) -> sessionClosed > >>> > >>> That is I call session.close(true) from the method > >> exceptionCaught, and > >>> that leads to a callback to sessionClosed. I do some cleanup in > >>> sessionClosed and informs my upper layers about the disconnect. > >>> > >>> This happens in 0.8.2: > >>> > >>> exceptionCaught -> session.close(true) -> blocked in wait. > >>> > >>> That is, the thread hangs / is blocked in wait, and never > >> gets out of > >>> it. > >>> > >>> The problem does not occur if session.close(true) is called > >> on client > >>> side during normal program flow. > >>> > >>> Is this how it's supposed to work? > >>> > >>> Thanks for your help > >>> Kaj > >>> > >>> > >>> > >>> > >> > >> -- > >> what we call human nature is actually human habit > >> -- > >> http://gleamynode.net/ > >> -- > >> PGP key fingerprints: > >> * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E > >> * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6 > >> > >
-- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
