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
> >>
> 
> 

Reply via email to