rickilama54 / gwt-comet

Automatically exported from code.google.com/p/gwt-comet
0 stars 0 forks source link

No callback on browser close (1.1.4) #6

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?

I have an application that needs to more or less simulate a low-level
socket using comet (It's used for a game). When the client connect it
connects to a backend system (much like the examples with the
InstantMessagingServlet). The backend will continously push messages to the
client.

However if I close the browser window I get a WARN log message and a big
stacktrace:

   [WARN] Error writing messages
org.mortbay.jetty.EofException
    at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:760)
    at
org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:566)
    at org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:911)
    at
net.zschech.gwt.comet.server.deflate.DeflaterOutputStream.flush(DeflaterOutputSt
ream.java:100)
    at
net.zschech.gwt.comet.server.impl.CountOutputStream.flush(CountOutputStream.java
:64)
    at sun.nio.cs.StreamEncoder.implFlush(Unknown Source)
    at sun.nio.cs.StreamEncoder.flush(Unknown Source)
    at java.io.OutputStreamWriter.flush(Unknown Source)
    at
net.zschech.gwt.comet.server.impl.CometServletResponseImpl.flush(CometServletRes
ponseImpl.java:364)
    at
net.zschech.gwt.comet.server.impl.CometServletResponseImpl.write(CometServletRes
ponseImpl.java:328)
    at
net.zschech.gwt.comet.server.impl.ManagedStreamCometServletResponseImpl.write(Ma
nagedStreamCometServletResponseImpl.java:88)
    at
net.zschech.gwt.comet.server.impl.CometServletResponseImpl.writeSessionQueue(Com
etServletResponseImpl.java:474)
    at
net.zschech.gwt.comet.server.impl.BlockingAsyncServlet.suspend(BlockingAsyncServ
let.java:89)
    at
net.zschech.gwt.comet.server.impl.CometServletResponseImpl.suspend(CometServletR
esponseImpl.java:267)
    at
net.zschech.gwt.comet.server.CometServlet.doCometImpl(CometServlet.java:145)
    at net.zschech.gwt.comet.server.CometServlet.doGet(CometServlet.java:103)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

At this point the messages that were queued are lost, and when i once again
open the browser to resume the session the client will never see these
messages.

I checked the code and in BlockingAsyncServlet line 98 an IOException is
caught and the above log is printed. I would like to somehow get notified
in the server code of this happening so that i can try to resend these
messages once(if) the client opens the browser again (and the HTTPSession
is still valid).

If you don't want to dirty the API, perhaps there could be an option to
register an optional listener to this event or something.

Or maybe I'm not understanding how to work with the API.. i just started
testing this after all :)

What version of the product are you using? On what operating system?

1.1.4 on both Windows XP and Redhat linux

Original issue reported on code.google.com by magnus.o...@gmail.com on 5 May 2010 at 5:32

GoogleCodeExporter commented 9 years ago
This is working as designed.

Depending on the server, the server can only detect the clients disconnection 
by failing to sending data or a 
heartbeat to the client.

gwt-comet does not guarantee message delivery. If you require that you have to 
build it at a higher level. I 
would suggest using a WindowCloseListener to logout the client and invalidate 
the CometSession so server 
initiates the clean disconnection. You can also determine what you want to do 
with the undelivered queued 
messages in the CometSession. A WindowCloseListener of course is not guaranteed 
to be run for example if 
the browser crashes.

You can be notified of the individual comet responses getting terminated by 
extending CometServlet and 
overriding the cometTerminated(CometServletResponse cometResponse, boolean 
serverInitiated) method. If 
serverInitiated is false then you know it was the client disconnecting 
unexpectedly.

http://code.google.com/p/gwt-
comet/source/browse/trunk/src/net/zschech/gwt/comet/server/CometServlet.java#168

Original comment by rich...@zschech.net on 5 May 2010 at 1:13

GoogleCodeExporter commented 9 years ago
Hi,

Thanks for the reply. I have now worked out a solution that fits my needs for 
the
time being (involves invalidating the session on the client side so that the 
backend
will start a new session when the browser is opened again).

However just a question - if it works as intended and is not a bug, why does it 
log a
WARN message and prints a big stacktrace. This is just annoying if there is 
nothing
you can do about it..  IMHO.

BR

Magnus

Original comment by magnus.o...@gmail.com on 7 May 2010 at 1:37