search

yrift / jwebsocket

Automatically exported from code.google.com/p/jwebsocket
0 stars 0 forks source link

Netty causing packet loss if client close the connection first. #34

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
If you send lots of tokens to the server (e.g. by painting fast in the 
“Canvas” demo) and immediately close the web page (i.e. before all answers 
are received by the client), the Netty engine also produces a series of 
exceptions, probably because the browser already closed the connection and the 
remaining packets can not be sent anymore

What is the expected output? What do you see instead?

It should not crash or throw errors and handle the remaining packet gracefully

Original issue reported on code.google.com by mailtopu...@gmail.com on 8 Aug 2010 at 6:35

GoogleCodeExporter commented 8 years ago 
this is fixed, there was a bug in NettyConnector where it was not checking for 
channel connection status as well as engine isAlive flag before sending packets

Original comment by mailtopu...@gmail.com on 10 Aug 2010 at 6:46

GoogleCodeExporter commented 8 years ago

Original comment by mailtopu...@gmail.com on 10 Aug 2010 at 6:46

GoogleCodeExporter commented 8 years ago 
This does not yet seem to be fixed - so I re-opened it. If you e.g. run the 
Canvas Demo, draw something very quickly and immediately leave the page e.g. by 
clicking another demo you'll get:

2010-08-10 10:31:18,112 DEBUG - SystemPlugIn: Broadcasting disconnect...
java.nio.channels.ClosedChannelException
        at org.jboss.netty.channel.socket.nio.NioWorker.cleanUpWriteBuffer(NioWorker.java:644)
        at org.jboss.netty.channel.socket.nio.NioWorker.close(NioWorker.java:601)
        at org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:119)
        at org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:76)
        at org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:60)
        at org.jboss.netty.channel.Channels.close(Channels.java:720)
        at org.jboss.netty.channel.AbstractChannel.close(AbstractChannel.java:178)
        at org.jwebsocket.netty.connectors.NettyConnector.stopConnector(NettyConnector.java:82)
        at org.jwebsocket.plugins.system.SystemPlugIn.close(SystemPlugIn.java:450)
2010-08-10 10:31:18,111 DEBUG - JWebSocketCustomListenerSample: Client 
'f0c6b1203e08bb9d4326648e16727071' disconnected.
        at org.jwebsocket.plugins.system.SystemPlugIn.processToken(SystemPlugIn.java:92)
2010-08-10 10:31:18,112 DEBUG - TokenServer: Broadcasting token 
'{type=event,name=disconnect,sourceId=50977,clientCount=0} to all token based 
connectors...
2010-08-10 10:31:18,113 DEBUG - SystemFilter: Checking outgoing token from 
50977 to [not given]: 
{type=event,name=disconnect,sourceId=50977,clientCount=0}...
2010-08-10 10:31:18,113 DEBUG - JWebSocketTokenListenerSample: Client 
'0b7969fddfa7adc7291198e7dbaa85a9' disconnected.
        at org.jwebsocket.plugins.TokenPlugInChain.processToken(TokenPlugInChain.java:52)
2010-08-10 10:31:18,113 DEBUG - CustomServer: Processing connector stopped...
        at org.jwebsocket.server.TokenServer.processToken(TokenServer.java:198)
2010-08-10 10:31:18,135 DEBUG - BasePlugInChain: Notifying plug-ins that 
connector '50977' stopped (CLIENT)...

Original comment by fivefeetfurther@gmail.com on 10 Aug 2010 at 8:34

GoogleCodeExporter commented 8 years ago 
This should be fixed now.. there was a left over code which was dumping stack 
trace on channel close operation

Original comment by mailtopu...@gmail.com on 19 Aug 2010 at 8:09