You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Steve Bate <st...@technoetic.com> on 2006/09/21 15:14:02 UTC
Close future join behavior
I have some code where I want to close my session and not return from the
current method until the close is complete. I wrote something similar to...
iosession.close().join();
This code is called during a session's exceptionCaught filter chain
invocation. The problem is that the callback happens in the socket io
processor thread and the thread blocks in the join() operation so the close
future status never set.
Am I doing something incorrect here or is this a bug? The code fragment
described above is also called from application threads (without blocking
indefinitely, as expected). Any advice?
Thanks,
Steve
RE: Close future join behavior
Posted by Steve Bate <st...@technoetic.com>.
No problem. I agree it is similar symptoms.
Steve
> -----Original Message-----
> From: Frederic Soulier [mailto:frederic@wallaby.uklinux.net]
> Sent: Thursday, September 21, 2006 5:54 PM
> To: mina-dev@directory.apache.org
> Subject: RE: Close future join behavior
>
> On Thu, 2006-09-21 at 17:43 +0200, Steve Bate wrote:
> > > From: Frederic Soulier [mailto:frederic@wallaby.uklinux.net]
> > > This is the same issue as DIRMINA-261.
> >
> > Hi Frederic,
> >
> > I haven't set SO_LINGERING and I'm runnning on Windows. It doesn't
> > appear to be exactly the same problem.
>
> Sorry Steve.
>
> What I meant was the behaviour is the same although triggered
> differently. Basically the wait for the close blocks the thread.
>
> --
> Frederic Soulier <fr...@wallaby.uklinux.net> OpenPGP key
> available on http://www.keyserver.net
> 1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
>
>
RE: Close future join behavior
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
On Thu, 2006-09-21 at 17:43 +0200, Steve Bate wrote:
> > From: Frederic Soulier [mailto:frederic@wallaby.uklinux.net]
> > This is the same issue as DIRMINA-261.
>
> Hi Frederic,
>
> I haven't set SO_LINGERING and I'm runnning on Windows. It
> doesn't appear to be exactly the same problem.
Sorry Steve.
What I meant was the behaviour is the same although triggered
differently. Basically the wait for the close blocks the thread.
--
Frederic Soulier <fr...@wallaby.uklinux.net>
OpenPGP key available on http://www.keyserver.net
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
RE: Close future join behavior
Posted by Steve Bate <st...@technoetic.com>.
> From: Frederic Soulier [mailto:frederic@wallaby.uklinux.net]
> This is the same issue as DIRMINA-261.
Hi Frederic,
I haven't set SO_LINGERING and I'm runnning on Windows. It
doesn't appear to be exactly the same problem.
Steve
Re: Close future join behavior
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
On Thu, 2006-09-21 at 23:33 +0900, Trustin Lee wrote:
> Hello Steve,
>
> On 9/21/06, Steve Bate <st...@technoetic.com> wrote:
> >
> > I have some code where I want to close my session and not return from the
> > current method until the close is complete. I wrote something similar
> > to...
> >
> > iosession.close().join();
> >
> > This code is called during a session's exceptionCaught filter chain
> > invocation. The problem is that the callback happens in the socket io
> > processor thread and the thread blocks in the join() operation so the
> > close
> > future status never set.
>
>
> Did you add the filter *before* the ThreadPoolFilter (or ExecutorFilter)?
> Then it can happen. Please try to add your filter after the
> ThreadPoolFilter. If you are using the latest release of MINA and don't
> need to add a ThreadPoolFilter by yourself; it's added by default. If you
> are adding your filter by calling addFirst, then please try to add it by
> calling addLast.
>
> Am I doing something incorrect here or is this a bug? The code fragment
> > described above is also called from application threads (without blocking
> > indefinitely, as expected). Any advice?
>
>
> I think it is not really a bug. We just need more documentation. As you
> figured out, it is impossible to wait for the future when the thread you
> called join() is also supposed to notify the future. The only way to avoid
> this deadlock is to wait in another thread.
This is the same issue as DIRMINA-261.
--
Frederic Soulier <fr...@wallaby.uklinux.net>
OpenPGP key available on http://www.keyserver.net
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
RE: Close future join behavior
Posted by Steve Bate <st...@technoetic.com>.
Hi Trustin,
The filter is the "tailFilter" that calls my IoHandler. My handler's
exceptionCaught method closes the IoSession. In other words, I'm not
closing the session from a user-defined filter.
I wanted to be sure I understood the issue correctly. I'll probably
just remove the joins for now.
Thanks,
Steve
> -----Original Message-----
> From: Trustin Lee [mailto:trustin@gmail.com]
> Sent: Thursday, September 21, 2006 4:33 PM
> To: mina-dev@directory.apache.org
> Subject: Re: Close future join behavior
>
> Hello Steve,
>
> On 9/21/06, Steve Bate <st...@technoetic.com> wrote:
> >
> > I have some code where I want to close my session and not
> return from
> > the current method until the close is complete. I wrote something
> > similar to...
> >
> > iosession.close().join();
> >
> > This code is called during a session's exceptionCaught filter chain
> > invocation. The problem is that the callback happens in the
> socket io
> > processor thread and the thread blocks in the join()
> operation so the
> > close future status never set.
>
>
> Did you add the filter *before* the ThreadPoolFilter (or
> ExecutorFilter)?
> Then it can happen. Please try to add your filter after the
> ThreadPoolFilter. If you are using the latest release of
> MINA and don't need to add a ThreadPoolFilter by yourself;
> it's added by default. If you are adding your filter by
> calling addFirst, then please try to add it by calling addLast.
>
> Am I doing something incorrect here or is this a bug? The
> code fragment
> > described above is also called from application threads (without
> > blocking indefinitely, as expected). Any advice?
>
>
> I think it is not really a bug. We just need more
> documentation. As you figured out, it is impossible to wait
> for the future when the thread you called join() is also
> supposed to notify the future. The only way to avoid this
> deadlock is to wait in another thread.
>
> HTH,
> 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: Close future join behavior
Posted by Trustin Lee <tr...@gmail.com>.
Hello Steve,
On 9/21/06, Steve Bate <st...@technoetic.com> wrote:
>
> I have some code where I want to close my session and not return from the
> current method until the close is complete. I wrote something similar
> to...
>
> iosession.close().join();
>
> This code is called during a session's exceptionCaught filter chain
> invocation. The problem is that the callback happens in the socket io
> processor thread and the thread blocks in the join() operation so the
> close
> future status never set.
Did you add the filter *before* the ThreadPoolFilter (or ExecutorFilter)?
Then it can happen. Please try to add your filter after the
ThreadPoolFilter. If you are using the latest release of MINA and don't
need to add a ThreadPoolFilter by yourself; it's added by default. If you
are adding your filter by calling addFirst, then please try to add it by
calling addLast.
Am I doing something incorrect here or is this a bug? The code fragment
> described above is also called from application threads (without blocking
> indefinitely, as expected). Any advice?
I think it is not really a bug. We just need more documentation. As you
figured out, it is impossible to wait for the future when the thread you
called join() is also supposed to notify the future. The only way to avoid
this deadlock is to wait in another thread.
HTH,
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