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/09/01 10:57:02 UTC
RE: Problem during upgrade from 0.7.3 to 0.8.2
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>.
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