You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Frederic Soulier <fr...@3g-scene.com> on 2006/08/08 20:21:31 UTC
Issue with disconnection and ioSession.close().join()
Hi
I've been successfully using MINA 0.9.4 for a few weeks now with great
success (running several thousands of threads to simulate clients
sending various encrypted payload).
I've hit a problem recently which I can't figure out.
When a mobile phone is used as a client and is connected to the
SocketAcceptor on the server we can send some messages and all seems
fine.
If the battery of the phone is removed (hence terminating the client
application), we have a process that scans for sessions without activity
for more than 30 seconds. If such a session is found we call:
ioSession.close().join();
At that point the socketAcceptor doesn't accept any connections at all.
Our only way to get it back is to kill it and restart it.
I've printed some debug info to try to figure out what's going on:
- client connects, sends some messages and then is killed.
Case #1 (Wired connection - LAN)
================================
after 30s of inactivity
2006-08-08 16:58:31,779 DEBUG [CA3518C5- ] Disconnected.
true > ioSession.isClosing();
false > ioSession.isConnected();
SocketAcceptor sa = (SocketAcceptor) ioSession.getService();
InetSocketAddress sa1 = new InetSocketAddress(20700);
true > sa.isBound(sa1);
CloseFuture cf = ioSession.close();
true > ioSession.isClosing();
false > ioSession.isConnected();
true > cf.isReady();
true > cf.isClosed();
cf.join();
Working fine afterwards, the SocketAcceptor accepts new connections
without problem.
Case #2 (Wireless connection (GPRS)
===================================
after 30s of inactivity
2006-08-08 17:13:23,412 DEBUG [CA3518C5- ] Disconnected.
false > ioSession.isClosing();
true > ioSession.isConnected();
SocketAcceptor sa = (SocketAcceptor) ioSession.getService();
InetSocketAddress sa1 = new InetSocketAddress(20700);
true > sa.isBound(sa1);
CloseFuture cf = ioSession.close();
true > ioSession.isClosing();
true > ioSession.isConnected();
false > cf.isReady();
false > cf.isClosed();
cf.join();
SocketAcceptor all buggered... Needs complete restart of the server.
Any idea what could cause this problem?
Thx.
--
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: Issue with disconnection and ioSession.close().join()
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
On 11 Aug 2006, at 2:58, Trustin Lee wrote:
> I am sorry that I couldn't give you much help. But I am so glad
> that you
> found the solution. I am gathering this kind of cases to upgrade
> our FAQ
> page. In the long run, we will be able to summarize all possible
> weirdness
> we might experience.
No worries Trustin it was a good exercise to look closely at this issue.
What I don't understand is why this issue (which seems platform
specific) would bring MINA to a halt.
Or is it the case here that MINA is completely relying on the
underlying nio implementation and network stack of the running OS and
can't do anything at all?
--
Frederic P. Soulier
OpenPGP key available on http://pgpkeys.mit.edu/
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
Re: Issue with disconnection and ioSession.close().join()
Posted by Trustin Lee <tr...@gmail.com>.
I am sorry that I couldn't give you much help. But I am so glad that you
found the solution. I am gathering this kind of cases to upgrade our FAQ
page. In the long run, we will be able to summarize all possible weirdness
we might experience.
Thank you,
Trustin
On 8/11/06, Frederic Soulier <fr...@wallaby.uklinux.net> wrote:
>
> On Thu, 2006-08-10 at 18:49 +0100, Frederic Soulier wrote:
> > Here's the twist:
> > I experience this issue on 3 linux boxes
> > FC5 + Sun JDK 1.5.0_07 (also with _08 and JDK 6 b2)
> > CentOS 3.7 + Sun JDK 1.5.0_07
> > SUSE 9.1 + Sun JDK 1.5.0_07
> >
> > but it works fine on a Windows box...
> > Win XP Pro SP2 with Sun JDK 1.5.0_07
>
> Ok the culprit is the SO_LINGER thing
>
> SocketSessionConfig ssc = (SocketSessionConfig)ioSession.getConfig();
> ssc.setSoLinger(2000);
>
> As soon as comment out
> ssc.setSoLinger(2000);
> it all works.
>
> Considering the lingering value is in seconds according to the
> java.net.Socket doc I'm not surprised it stays blocked for a while :)
> Although the behaviour is different on a Windows platform.
>
> Note: we recreated the problem on a wired network by unplugging the
> client while running some tests so nothing particular to running the
> apps over a GPRS network.
>
> --
> 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
>
>
--
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: Issue with disconnection and ioSession.close().join()
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
On 11 Aug 2006, at 7:50, Vinod Panicker wrote:
> On 8/11/06, Frederic Soulier <fr...@wallaby.uklinux.net> wrote:
>> On Thu, 2006-08-10 at 18:49 +0100, Frederic Soulier wrote:
>> > Here's the twist:
>> > I experience this issue on 3 linux boxes
>> > FC5 + Sun JDK 1.5.0_07 (also with _08 and JDK 6 b2)
>> > CentOS 3.7 + Sun JDK 1.5.0_07
>> > SUSE 9.1 + Sun JDK 1.5.0_07
>
> You mean to say that the problem is occuring when you run with JDK
> 6 b2 as well?
Yep we have the same issue with JDK 6 b2 on linux machines. We
haven't tried JDK 6 b2 on a windows box.
--
Frederic P. Soulier
OpenPGP key available on http://pgpkeys.mit.edu/
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
Re: Issue with disconnection and ioSession.close().join()
Posted by Vinod Panicker <vi...@gmail.com>.
On 8/11/06, Frederic Soulier <fr...@wallaby.uklinux.net> wrote:
> On Thu, 2006-08-10 at 18:49 +0100, Frederic Soulier wrote:
> > Here's the twist:
> > I experience this issue on 3 linux boxes
> > FC5 + Sun JDK 1.5.0_07 (also with _08 and JDK 6 b2)
> > CentOS 3.7 + Sun JDK 1.5.0_07
> > SUSE 9.1 + Sun JDK 1.5.0_07
You mean to say that the problem is occuring when you run with JDK 6 b2 as well?
> > but it works fine on a Windows box...
> > Win XP Pro SP2 with Sun JDK 1.5.0_07
We are also experiencing the same :) The problem is not occuring on
windows machines, but only on Linux machines. I was just about to
post that when I saw you had already figured it out :)
Just about to try with JDK 6 b2, and wanted to check if you were
having the same problem with that as well.
> Ok the culprit is the SO_LINGER thing
>
> SocketSessionConfig ssc = (SocketSessionConfig)ioSession.getConfig();
> ssc.setSoLinger(2000);
>
> As soon as comment out
> ssc.setSoLinger(2000);
> it all works.
We're not using SO_LINGER anyways. So it seems like my problem is
connected with something else.
> Considering the lingering value is in seconds according to the
> java.net.Socket doc I'm not surprised it stays blocked for a while :)
> Although the behaviour is different on a Windows platform.
>
> Note: we recreated the problem on a wired network by unplugging the
> client while running some tests so nothing particular to running the
> apps over a GPRS network.
>
> --
> 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
>
>
Regards,
Vinod.
Re: Issue with disconnection and ioSession.close().join()
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
On Thu, 2006-08-10 at 18:49 +0100, Frederic Soulier wrote:
> Here's the twist:
> I experience this issue on 3 linux boxes
> FC5 + Sun JDK 1.5.0_07 (also with _08 and JDK 6 b2)
> CentOS 3.7 + Sun JDK 1.5.0_07
> SUSE 9.1 + Sun JDK 1.5.0_07
>
> but it works fine on a Windows box...
> Win XP Pro SP2 with Sun JDK 1.5.0_07
Ok the culprit is the SO_LINGER thing
SocketSessionConfig ssc = (SocketSessionConfig)ioSession.getConfig();
ssc.setSoLinger(2000);
As soon as comment out
ssc.setSoLinger(2000);
it all works.
Considering the lingering value is in seconds according to the
java.net.Socket doc I'm not surprised it stays blocked for a while :)
Although the behaviour is different on a Windows platform.
Note: we recreated the problem on a wired network by unplugging the
client while running some tests so nothing particular to running the
apps over a GPRS network.
--
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: Issue with disconnection and ioSession.close().join()
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
Here's the twist:
I experience this issue on 3 linux boxes
FC5 + Sun JDK 1.5.0_07 (also with _08 and JDK 6 b2)
CentOS 3.7 + Sun JDK 1.5.0_07
SUSE 9.1 + Sun JDK 1.5.0_07
but it works fine on a Windows box...
Win XP Pro SP2 with Sun JDK 1.5.0_07
Here is the SocketAcceptorIoProcessor thread which seems to be stuck in
a native call in the nio package coming from the ch.close() in the
SocketIoProcessor.
Thread [SocketAcceptorIoProcessor-0.0] (Suspended)
FileDispatcher.preClose0(FileDescriptor) line: not available [native
method]
SocketDispatcher.preClose(FileDescriptor) line: 41
SocketChannelImpl.implCloseSelectableChannel() line: 626 [local
variables unavailable]
SocketChannelImpl(AbstractSelectableChannel).implCloseChannel() line:
201 [local variables unavailable]
SocketChannelImpl(AbstractInterruptibleChannel).close() line: 97
[local variables unavailable]
SocketIoProcessor.doRemove() line: 217
SocketIoProcessor.access$600(SocketIoProcessor) line: 41
SocketIoProcessor$Worker.run() line: 569
In SocketIoProcessor
doRemove()
...
try
{
key.cancel();
ch.close(); < executing
}
catch( IOException e )
Could it be an implementation issue in the SUN nio classes?
Could it be a kernel/threading issue in Linux?
Thx for any help.
--
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: Issue with disconnection and ioSession.close().join()
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
More info on this one...
2006-08-09 10:08:59,167 DEBUG PRE ioSession closing [false]
2006-08-09 10:08:59,167 DEBUG PRE ioSession connected [true]
ioSession.close() here
2006-08-09 10:08:59,167 DEBUG PRE ioSession closing [true]
2006-08-09 10:08:59,168 DEBUG PRE ioSession connected [true]
2006-08-09 10:08:59,168 DEBUG PRE CloseFuture ready [false]
2006-08-09 10:08:59,168 DEBUG PRE CloseFuture closed [false]
Server seems stuck.
Run http://192.168.10.50:20700/ from Firefox. Request doesn't get
through.
Leave server running anyway.
2006-08-09 10:31:45,505 DEBUG POST CloseFuture ready [true]
2006-08-09 10:31:45,506 DEBUG POST CloseFuture closed [true]
2006-08-09 10:31:45,507 DEBUG POST ioSession closing [true]
Comes back to life 22 mins 46s later... without any intervention!
--
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: Issue with disconnection and ioSession.close().join()
Posted by Vinod Panicker <vi...@gmail.com>.
On 8/9/06, Frederic Soulier <fr...@wallaby.uklinux.net> wrote:
> Hi Trustin
>
> Here is the full thread dump.
<snip/>
> On Wed, 2006-08-09 at 16:41 +0900, Trustin Lee wrote:
> > On 8/9/06, Frederic Soulier <fr...@3g-scene.com> wrote:
> > >
> > > When a mobile phone is used as a client and is connected to the
> > > SocketAcceptor on the server we can send some messages and all seems
> > > fine.
> > > If the battery of the phone is removed (hence terminating the client
> > > application), we have a process that scans for sessions without activity
> > > for more than 30 seconds. If such a session is found we call:
> > > ioSession.close().join();
> > >
> > > At that point the socketAcceptor doesn't accept any connections at all.
> > > Our only way to get it back is to kill it and restart it.
> >
> >
> > This is weird because SocketAcceptor thread doesn't take care of closing a
> > session. SocketIoProcessor does it instead. That is, SocketAcceptor thread
> > shouldn't get affected by any I/O after acceptance of a channel. Could you
> > post a full thread dump for us?
>
>
> Full thread dump Java HotSpot(TM) Server VM (1.5.0_07-b03 mixed mode):
<snip/>
I'm facing a vaguely similar problem. The scenario is thus -
1. Server has a few hundred concurrent connections
2. Clients abruptly disconnect due to network failure or some other reason
3. Server processes disconnects
4. Client reconnects
5. Server accepts connection
6. Client writes message
7. messageReceived() is never fired
Currently trying to find out what exactly is causing this.
Regards,
Vinod.
Re: Issue with disconnection and ioSession.close().join()
Posted by Frederic Soulier <fr...@wallaby.uklinux.net>.
Hi Trustin
Here is the full thread dump.
I've now split the
ioSession.close().join();
into
CloseFuture cf = ioSession.close();
cf.join();
Note that I've setup a debug point using Eclipse just before the
ioSession.close() occurs and at that stage I can still access the socket
server (using a browser and pointing it at http://192.168.20.50:20700/)
As soon as I step over the ioSession.close() the socket server doesn't
respond anymore...
As far as I can tell it gets stuck in the lock.wait() of the IoFuture
because it's not ready.
/**
* Wait for the asynchronous operation to end.
*/
public void join()
{
synchronized( lock )
{
while( !ready )
{
try
{
lock.wait();
}
catch( InterruptedException e )
{
}
}
}
}
I can provide more details so let me know.
On Wed, 2006-08-09 at 16:41 +0900, Trustin Lee wrote:
> On 8/9/06, Frederic Soulier <fr...@3g-scene.com> wrote:
> >
> > When a mobile phone is used as a client and is connected to the
> > SocketAcceptor on the server we can send some messages and all seems
> > fine.
> > If the battery of the phone is removed (hence terminating the client
> > application), we have a process that scans for sessions without activity
> > for more than 30 seconds. If such a session is found we call:
> > ioSession.close().join();
> >
> > At that point the socketAcceptor doesn't accept any connections at all.
> > Our only way to get it back is to kill it and restart it.
>
>
> This is weird because SocketAcceptor thread doesn't take care of closing a
> session. SocketIoProcessor does it instead. That is, SocketAcceptor thread
> shouldn't get affected by any I/O after acceptance of a channel. Could you
> post a full thread dump for us?
Full thread dump Java HotSpot(TM) Server VM (1.5.0_07-b03 mixed mode):
"PooledByteBufferExpirer-0" daemon prio=1 tid=0x08dfa180 nid=0xa90
waiting on condition [0x8b479000..0x8b479fc0]
at java.lang.Thread.sleep(Native Method)
at org.apache.mina.common.PooledByteBufferAllocator
$Expirer.run(PooledByteBufferAllocator.java:289)
"AnonymousIoService-2-2" daemon prio=1 tid=0x08b5a780 nid=0xa8f in
Object.wait() [0x8b4fa000..0x8b4fb040]
at java.lang.Object.wait(Native Method)
- waiting on <0xae623b98> (a org.apache.mina.util.BlockingQueue)
at java.lang.Object.wait(Object.java:474)
at
org.apache.mina.util.BlockingQueue.waitForNewItem(BlockingQueue.java:55)
- locked <0xae623b98> (a org.apache.mina.util.BlockingQueue)
at org.apache.mina.filter.ThreadPoolFilter
$Worker.fetchBuffer(ThreadPoolFilter.java:447)
- locked <0xae623b98> (a org.apache.mina.util.BlockingQueue)
at org.apache.mina.filter.ThreadPoolFilter
$Worker.run(ThreadPoolFilter.java:422)
"SocketAcceptorIoProcessor-0.0" prio=1 tid=0x08b5b808 nid=0xa8c runnable
[0x8b57b000..0x8b57c0c0]
at sun.nio.ch.FileDispatcher.preClose0(Native Method)
at sun.nio.ch.SocketDispatcher.preClose(SocketDispatcher.java:41)
at
sun.nio.ch.SocketChannelImpl.implCloseSelectableChannel(SocketChannelImpl.java:626)
- locked <0xae6b1418> (a java.lang.Object)
at
java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel(AbstractSelectableChannel.java:201)
at
java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97)
- locked <0xae6b13f0> (a java.lang.Object)
at
org.apache.mina.transport.socket.nio.SocketIoProcessor.doRemove(SocketIoProcessor.java:217)
at org.apache.mina.transport.socket.nio.SocketIoProcessor.access
$600(SocketIoProcessor.java:41)
at org.apache.mina.transport.socket.nio.SocketIoProcessor
$Worker.run(SocketIoProcessor.java:569)
"AnonymousIoService-2-1" daemon prio=1 tid=0x08b5b330 nid=0xa8b in
Object.wait() [0x8b5fc000..0x8b5fd140]
at java.lang.Object.wait(Native Method)
- waiting on <0xae6f2a48> (a java.lang.Object)
at org.apache.mina.filter.ThreadPoolFilter
$Worker.waitForPromotion(ThreadPoolFilter.java:546)
- locked <0xae6f2a48> (a java.lang.Object)
at org.apache.mina.filter.ThreadPoolFilter
$Worker.run(ThreadPoolFilter.java:419)
"DestroyJavaVM" prio=1 tid=0x086293d0 nid=0xa64 waiting on condition
[0x00000000..0xbf831bb0]
"SocketAcceptor-1" prio=1 tid=0x089bb9f0 nid=0xa85 runnable
[0x8b67d000..0x8b67e1c0]
at sun.nio.ch.PollArrayWrapper.poll0(Native Method)
at sun.nio.ch.PollArrayWrapper.poll(PollArrayWrapper.java:100)
at sun.nio.ch.PollSelectorImpl.doSelect(PollSelectorImpl.java:56)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
- locked <0xae676e58> (a sun.nio.ch.Util$1)
- locked <0xae676e48> (a java.util.Collections$UnmodifiableSet)
- locked <0xae676c50> (a sun.nio.ch.PollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:84)
at org.apache.mina.transport.socket.nio.SocketAcceptor
$Worker.run(SocketAcceptor.java:355)
"Timer-1" prio=1 tid=0x08dfc528 nid=0xa84 in Object.wait()
[0x8b6fe000..0x8b6fee40]
at java.lang.Object.wait(Native Method)
- waiting on <0xae6766c0> (a java.util.TaskQueue)
at java.lang.Object.wait(Object.java:474)
at java.util.TimerThread.mainLoop(Timer.java:483)
- locked <0xae6766c0> (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:462)
"SocketAcceptor-0" prio=1 tid=0x0902ac68 nid=0xa83 runnable
[0x8b8fe000..0x8b8feec0]
at sun.nio.ch.PollArrayWrapper.poll0(Native Method)
at sun.nio.ch.PollArrayWrapper.poll(PollArrayWrapper.java:100)
at sun.nio.ch.PollSelectorImpl.doSelect(PollSelectorImpl.java:56)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
- locked <0xae660a28> (a sun.nio.ch.Util$1)
- locked <0xae660a18> (a java.util.Collections$UnmodifiableSet)
- locked <0xae660668> (a sun.nio.ch.PollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:84)
at org.apache.mina.transport.socket.nio.SocketAcceptor
$Worker.run(SocketAcceptor.java:355)
"Session Manager" prio=1 tid=0x8b781740 nid=0xa82 runnable
[0x8bafe000..0x8bafef40]
at
com.threegscene.arg.gp.session.AbstractSessionSink.closeIoSession(AbstractSessionSink.java:122)
at
com.threegscene.arg.gp.session.DefaultSession.setConnected(DefaultSession.java:286)
at
com.threegscene.arg.gp.session.SessionManager.scan(SessionManager.java:215)
at com.threegscene.arg.gp.session.SessionManager.access
$0(SessionManager.java:172)
at com.threegscene.arg.gp.session.SessionManager
$1.run(SessionManager.java:108)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
"RMI TCP Accept-20702" daemon prio=1 tid=0x8c1d5720 nid=0xa7f runnable
[0x8bd0b000..0x8bd0c040]
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked <0x919c3140> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.rmi.transport.tcp.TCPTransport.run(TCPTransport.java:340)
at java.lang.Thread.run(Thread.java:595)
"RMI TCP Accept-0" daemon prio=1 tid=0x8c1d08f0 nid=0xa7e runnable
[0x8bd8c000..0x8bd8d0c0]
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked <0x919c30c8> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.rmi.transport.tcp.TCPTransport.run(TCPTransport.java:340)
at java.lang.Thread.run(Thread.java:595)
"Timer-0" daemon prio=1 tid=0x8c1ce8f8 nid=0xa7d in Object.wait()
[0x8be0d000..0x8be0e140]
at java.lang.Object.wait(Native Method)
- waiting on <0x919c31b8> (a java.util.TaskQueue)
at java.lang.Object.wait(Object.java:474)
at java.util.TimerThread.mainLoop(Timer.java:483)
- locked <0x919c31b8> (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:462)
"Low Memory Detector" daemon prio=1 tid=0x086e6f28 nid=0xa7c runnable
[0x00000000..0x00000000]
"CompilerThread1" daemon prio=1 tid=0x086e59a0 nid=0xa7b waiting on
condition [0x00000000..0x8cee2068]
"CompilerThread0" daemon prio=1 tid=0x086e4840 nid=0xa7a waiting on
condition [0x00000000..0x8cf63028]
"AdapterThread" daemon prio=1 tid=0x086e32a8 nid=0xa79 waiting on
condition [0x00000000..0x00000000]
"Signal Dispatcher" daemon prio=1 tid=0x086e1c38 nid=0xa78 waiting on
condition [0x00000000..0x00000000]
"JDWP Command Reader" daemon prio=1 tid=0x086e01d8 nid=0xa73 runnable
[0x00000000..0x00000000]
"JDWP Event Helper Thread" daemon prio=1 tid=0x086df158 nid=0xa72
runnable [0x00000000..0x00000000]
"JDWP Transport Listener: dt_socket" daemon prio=1 tid=0x086dd668
nid=0xa71 runnable [0x00000000..0x8d1e8e80]
"Finalizer" daemon prio=1 tid=0x086cceb0 nid=0xa6e in Object.wait()
[0x8d46a000..0x8d46a1c0]
at java.lang.Object.wait(Native Method)
- waiting on <0x9195c2e8> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
- locked <0x9195c2e8> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=1 tid=0x086cc918 nid=0xa6d in
Object.wait() [0x8d4ea000..0x8d4eae40]
at java.lang.Object.wait(Native Method)
- waiting on <0x91970bb0> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:474)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x91970bb0> (a java.lang.ref.Reference$Lock)
"VM Thread" prio=1 tid=0x086ca488 nid=0xa6c runnable
"GC task thread#0 (ParallelGC)" prio=1 tid=0x086431e0 nid=0xa6a
runnable
"GC task thread#1 (ParallelGC)" prio=1 tid=0x08643e30 nid=0xa6b
runnable
"VM Periodic Task Thread" prio=1 tid=0x8c1d99d8 nid=0xa80 waiting on
condition
--
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: Issue with disconnection and ioSession.close().join()
Posted by Trustin Lee <tr...@gmail.com>.
Hi Frederic,
On 8/9/06, Frederic Soulier <fr...@3g-scene.com> wrote:
>
> When a mobile phone is used as a client and is connected to the
> SocketAcceptor on the server we can send some messages and all seems
> fine.
> If the battery of the phone is removed (hence terminating the client
> application), we have a process that scans for sessions without activity
> for more than 30 seconds. If such a session is found we call:
> ioSession.close().join();
>
> At that point the socketAcceptor doesn't accept any connections at all.
> Our only way to get it back is to kill it and restart it.
This is weird because SocketAcceptor thread doesn't take care of closing a
session. SocketIoProcessor does it instead. That is, SocketAcceptor thread
shouldn't get affected by any I/O after acceptance of a channel. Could you
post a full thread dump for us?
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