You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Ka...@seb.se on 2006/08/04 14:07:34 UTC
Problem during upgrade from 0.7.3 to 0.8.2
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
Re: Problem during upgrade from 0.7.3 to 0.8.2
Posted by Trustin Lee <tr...@gmail.com>.
On 9/4/06, Kaj.Bjurman@seb.se <Ka...@seb.se> wrote:
>
> > I thought you are using 0.9.0? It is also in a unstable branch.
> > 0.9.5-SNAPSHOT is better than 0.9.0 if so.
>
> No, I'm currently using 0.8.2, hence the subject :)
How stupid I am! :)
Adding a thread pool on the client side is done like this in 0.8.x:
connector.getFilterChain().addFirst("threadPool", new
IoThreadPoolFilter(...));
It's exactly same with the server side.
Trustin
--
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
RE: Problem during upgrade from 0.7.3 to 0.8.2
Posted by Ka...@seb.se.
> I thought you are using 0.9.0? It is also in a unstable branch.
> 0.9.5-SNAPSHOT is better than 0.9.0 if so.
No, I'm currently using 0.8.2, hence the subject :)
Re: Problem during upgrade from 0.7.3 to 0.8.2
Posted by Trustin Lee <tr...@gmail.com>.
On 9/1/06, Kaj.Bjurman@seb.se <Ka...@seb.se> wrote:
>
> > It's a number of I/O threads rather than a thread that is
> > assigned to your
> > IoHandler. It means your handler will run in a single thread mode.
> > Fortunately, we changed MINA to add a thread pool
> > automatically by default
> > since 0.9.4. Why don't you upgrade to 0.9.4 or 0.9.5-SNAPSHOT?
>
> Because it's unstable?
I thought you are using 0.9.0? It is also in a unstable branch.
0.9.5-SNAPSHOT is better than 0.9.0 if so.
Trustin
--
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
RE: Problem during upgrade from 0.7.3 to 0.8.2
Posted by Ka...@seb.se.
> It's a number of I/O threads rather than a thread that is
> assigned to your
> IoHandler. It means your handler will run in a single thread mode.
> Fortunately, we changed MINA to add a thread pool
> automatically by default
> since 0.9.4. Why don't you upgrade to 0.9.4 or 0.9.5-SNAPSHOT?
Because it's unstable?
Re: Problem during upgrade from 0.7.3 to 0.8.2
Posted by Trustin Lee <tr...@gmail.com>.
On 9/1/06, Kaj.Bjurman@seb.se <Ka...@seb.se> wrote:
>
> I saw that the constructor to SocketConnector in v0.9 takes an argument
> which is number of threads, but I can't find out how I add a
> ThreadPoolFilter to the client side in v0.8. Does any of the examples
> show how to do it on the client side?
It's a number of I/O threads rather than a thread that is assigned to your
IoHandler. It means your handler will run in a single thread mode.
Fortunately, we changed MINA to add a thread pool automatically by default
since 0.9.4. Why don't you upgrade to 0.9.4 or 0.9.5-SNAPSHOT?
Trustin
--
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
RE: Problem during upgrade from 0.7.3 to 0.8.2
Posted by Ka...@seb.se.
Ok. I will try to produce a complete thread dump during the day.
It's the server side which is calling session.close(true), and the
server is using SimpleServiceRegistry, and I thought that it created a
ThreadPoolFilter for me.
> -----Original Message-----
> From: Trustin Lee [mailto:trustin@gmail.com]
> Sent: 31 August 2006 04:28
> To: mina-dev@directory.apache.org
> Subject: Re: Problem during upgrade from 0.7.3 to 0.8.2
>
> 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, Kaj.Bjurman@seb.se <Ka...@seb.se> 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:niklas@trillian.se]
> > > Sent: 30 August 2006 16:07
> > > To: mina-dev@directory.apache.org
> > > 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
> > >
> > > Kaj.Bjurman@seb.se 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:trustin@gmail.com]
> > > >> Sent: 22 August 2006 06:56
> > > >> To: mina-dev@directory.apache.org
> > > >> 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, Kaj.Bjurman@seb.se <Ka...@seb.se> 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
>
RE: Problem during upgrade from 0.7.3 to 0.8.2
Posted by Ka...@seb.se.
Hi again,
I think you are correct. I found out that session.close(true) works on
the server side, but not on the client side.
My client code looks like this:
private class Client implements Controller {
private SocketConnector connector;
private IoSession session;
Client() {
connector = new SocketConnector();
}
public void start() throws Exception {
stop();
stopInitiated = false;
Address address = addresses.get(currentAddressIndex);
LOGGER.info("start", "Client " + getName() +
" trying to connect to " + address);
session = connector.connect(
new InetSocketAddress(address.host,
address.port),
timeoutSeconds,
DatastructureProtocolHandler.this);
}
<snip>
(Client is a nested class to DatastructureProtocolHandler)
I saw that the constructor to SocketConnector in v0.9 takes an argument
which is number of threads, but I can't find out how I add a
ThreadPoolFilter to the client side in v0.8. Does any of the examples
show how to do it on the client side?
Thanks for all of your help.
> -----Original Message-----
> From: Trustin Lee [mailto:trustin@gmail.com]
> Sent: 31 August 2006 04:28
> To: mina-dev@directory.apache.org
> Subject: Re: Problem during upgrade from 0.7.3 to 0.8.2
>
> 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, Kaj.Bjurman@seb.se <Ka...@seb.se> 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:niklas@trillian.se]
> > > Sent: 30 August 2006 16:07
> > > To: mina-dev@directory.apache.org
> > > 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
> > >
> > > Kaj.Bjurman@seb.se 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:trustin@gmail.com]
> > > >> Sent: 22 August 2006 06:56
> > > >> To: mina-dev@directory.apache.org
> > > >> 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, Kaj.Bjurman@seb.se <Ka...@seb.se> 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
>
Re: Problem during upgrade from 0.7.3 to 0.8.2
Posted by Trustin Lee <tr...@gmail.com>.
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, Kaj.Bjurman@seb.se <Ka...@seb.se> 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:niklas@trillian.se]
> > Sent: 30 August 2006 16:07
> > To: mina-dev@directory.apache.org
> > 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
> >
> > Kaj.Bjurman@seb.se 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:trustin@gmail.com]
> > >> Sent: 22 August 2006 06:56
> > >> To: mina-dev@directory.apache.org
> > >> 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, Kaj.Bjurman@seb.se <Ka...@seb.se> 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
Re: Problem during upgrade from 0.7.3 to 0.8.2
Posted by Emmanuel Lecharny <el...@gmail.com>.
using JIRA is really simple :
first, go to :
http://issues.apache.org/jira/browse/DIR
As you never added any issues in it, you will have to create an account on
it. Very simple.
Then, log in.
On the top level meny, select "Create new issue"
Select project "Directory MINA" and issue type "Bug"
On the next page, add a summary, and a description (you can modify the
other input box if needed) and if necessary, attach files.
Submit the page, and, bang, you have added an issue :)
Emmanuel
Re: Problem during upgrade from 0.7.3 to 0.8.2
Posted by Niklas Therning <ni...@trillian.se>.
I'm not sure we're talking about the same thing here. The thread dump
you are referring to looks more like a stack trace to me. A thread dump
contains a stack trace for all threads currently running in the JVM and
it also lists the locks a thread has acquired and whether it is waiting
for a particular lock to become available. This is extremely useful when
resolving deadlocks and such (which could be the problem here).
Anyways, when you have your thread dump here's how you create an issue
in JIRA:
Go to https://issues.apache.org/jira/secure/Dashboard.jspa and register.
Once you've registered and logged in go to
https://issues.apache.org/jira/secure/CreateIssue!default.jspa and
create the new issue. Attach your thread dump to the issue.
HTH
/Niklas
Kaj.Bjurman@seb.se 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:niklas@trillian.se]
>> Sent: 30 August 2006 16:07
>> To: mina-dev@directory.apache.org
>> 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
>>
>> Kaj.Bjurman@seb.se 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:trustin@gmail.com]
>>>> Sent: 22 August 2006 06:56
>>>> To: mina-dev@directory.apache.org
>>>> 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, Kaj.Bjurman@seb.se <Ka...@seb.se> 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
>>>>
>>
RE: Problem during upgrade from 0.7.3 to 0.8.2
Posted by Ka...@seb.se.
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:niklas@trillian.se]
> Sent: 30 August 2006 16:07
> To: mina-dev@directory.apache.org
> 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
>
> Kaj.Bjurman@seb.se 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:trustin@gmail.com]
> >> Sent: 22 August 2006 06:56
> >> To: mina-dev@directory.apache.org
> >> 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, Kaj.Bjurman@seb.se <Ka...@seb.se> 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
> >>
>
>
Re: Problem during upgrade from 0.7.3 to 0.8.2
Posted by Niklas Therning <ni...@trillian.se>.
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
Kaj.Bjurman@seb.se 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:trustin@gmail.com]
>> Sent: 22 August 2006 06:56
>> To: mina-dev@directory.apache.org
>> 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, Kaj.Bjurman@seb.se <Ka...@seb.se> 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
>>
RE: Problem during upgrade from 0.7.3 to 0.8.2
Posted by Ka...@seb.se.
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:trustin@gmail.com]
> Sent: 22 August 2006 06:56
> To: mina-dev@directory.apache.org
> 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, Kaj.Bjurman@seb.se <Ka...@seb.se> 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
>
Re: Problem during upgrade from 0.7.3 to 0.8.2
Posted by Trustin Lee <tr...@gmail.com>.
Could you please open a JIRA issue which attaches your full thread dump?
Thanks in advance,
Trustin
On 8/4/06, Kaj.Bjurman@seb.se <Ka...@seb.se> 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