Re: [jetty-users] Re: How to check if the client dropped the connection

[Julio Viegas <julioviegas@xxxxxxxxxxxxxxx>]

Hi Andrea,

   I think I asked the same thing before, but no success...

   Link to the thread I started(in list archives):
   http://archive.codehaus.org/lists/org.codehaus.jetty.user/msg/df60861f0812121314g22c4c59bq62dde245a57bc6a9@xxxxxxxxxxxxxx

   Again, any tip on how to achieve this will be very very much appreciated!

Rgrds,
JV -- julioviegas.com

On Thu, Sep 24, 2009 at 17:42, Andrea Aime <andrea.aime@xxxxxxxxx> wrote:
> Andrea Aime ha scritto:
>>
>> Hi,
>
> ...
>>
>> If there is no solution that can be applied at the general servlet
>> api level, do you know of any Jetty specific approach one could use?
>> e.g., casting the HttpServletResponse to some Jetty specific class
>> and get some connection information status there. I've looked a bit
>> but did not find anything.
>
> I also had an interesting chat with mgorovoy on the #jetty IRC
> channel. I figured the answers to his questions could be of interest
> of anyone responding to this mail
>
> ----------------------------------------------------------------------
>
> (22:25:40) mgorovoy: aaime: the simple approach would be to use a thread
> pool to process requests and have the servlet threads wait for the thread
> pool to complete processing
> (22:26:08) aaime: the question is, how do I get to know the client dropped
> the connection
> (22:26:10) mgorovoy: you could when store the session ID as parameter of the
> thread
> (22:26:22) aaime: I have the machinery to stop the processing
> (22:26:35) aaime: but I can't find a way to determine when (if) the client
> dropped the connection
> (22:26:35) mgorovoy: and every new request should check if there's already a
> thread that processes on the same session
> (22:26:45) aaime: two issues there
> (22:26:53) aaime: the protocol is completely session-less
> (22:26:57) mgorovoy: you are trying to catch connection close, much easier
> to detect new request
> (22:26:59) aaime: and clients will make up to 6 requests in parallel
> (22:27:01) aaime: (firefox)
> (22:27:10) mgorovoy: 6 requests???
> (22:27:11) mgorovoy: wowh
> (22:27:12) aaime: yes
> (22:27:21) aaime: think google maps
> (22:27:32) mgorovoy: but these requests different in parameters, right?
> (22:27:43) aaime: right, each uses different parameters
> (22:27:52) aaime: and I have no session
> (22:27:55) mgorovoy: so you can store the parameters of request as members
> of thread object
> (22:27:57) aaime: the protocol is stateless
> (22:28:21) aaime: I'm never getting the same request twice, too
> (22:28:23) mgorovoy: and compare these to figure out if the current request
> is a replacement for the request that is being processed
> (22:28:31) aaime: as the user zooms/pans around the requests do change
> (22:28:43) aaime: there is no request replacement concept
> (22:28:58) aaime: the client is free to ask as much as it wants, in whatever
> location and quantity it wants
> (22:29:08) aaime: requests are unrelated to each otehr
> (22:29:11) mgorovoy: hmmm
> (22:29:24) aaime: that's why I want to get the connection status
> (22:29:30) mgorovoy: i see what you mean... they split requests...
> (22:29:30) aaime: all I can work against is the current request
> (22:29:34) mgorovoy: into subs
> (22:29:44) mgorovoy: and when you zoom/pan they send new ones
> (22:29:49) aaime: and when the user zoom in the old requests still in
> progress are dropped
> (22:29:54) aaime: and new ones are made
> (22:30:17) aaime: if the user scrolls or zoom fast enough I've checked that
> I can get up to 50 requests working in parallel
> (22:30:26) mgorovoy: blah!
> (22:30:31) aaime: but only the last 6 ones are actually still wanted by the
> client
> (22:30:33) mgorovoy: that's not cool
> (22:30:39) aaime: and that is with firefox
> (22:30:48) aaime: a custom client can be programmed to make as many as it
> wants
> (22:30:58) aaime: not cool at all
> (22:31:12) aaime: apache + cgi is smart enough to kill the cgi process when
> the client connection is dropped
> (22:31:21) aaime: now, I understand the container cannot kill the thread
> (22:31:37) aaime: but give some hints that the request is dead and done for
> would be very appreciated
> (22:31:53) mgorovoy: back to thread pool model, if you do fifo stack for
> each client (that you could detect by IP+outgoing port combo), could you
> just push out the requests that are overlows?
> (22:32:14) mgorovoy: i.e. if you detect firefox, and it does 6 requests, you
> only process last 6 for that client?
> (22:32:30) aaime: firefox does 6 because it's usually configured to do 6
> (22:32:38) aaime: install the fasterfox extension and it will do more
> (22:32:51) mgorovoy: that's a pain
> (22:33:04) aaime: a wms desktop client won't have any rule I can follow,
> either
> (22:33:13) mgorovoy: mmmk
> (22:33:24) aaime: the pain imho is that the servlet spec is badly designed
> for this case
> (22:33:28) sbordet ha abbandonato il canale (quit: "Quitting...").
> (22:33:41) aaime: works fine only for services that can stream out responses
> right away
> (22:33:49) mgorovoy: you should ping gregw when he comes online in a couple
> of hours... maybe he can think of something.
> (22:34:04) aaime: I've sent a mail to the users list
> (22:34:09) aaime: it's 22.34 here
> (22:34:09) mgorovoy: okay, that
> (22:34:12) aaime: (Italy)
> (22:34:14) mgorovoy: is a good idea
> (22:34:52) mgorovoy: good night then ;)
> (22:35:00) aaime: do you mind if I follow up my initial mail with a copy of
> the above chat?
> (22:35:14) mgorovoy: no problem
> (22:35:15) aaime: gregw will probably make some of the same questions you
> did
> (22:35:31) mgorovoy: it was a good brainstorming session
> (22:36:47) mgorovoy: there might be a way to check the state of the
> connector...
> (22:37:02) mgorovoy: or to have a listener do something special...
> (22:37:02) aaime: I surely hope so
> (22:37:21) aaime: thought it would be a container specific solution, it's
> better than no solution
> (22:37:32) mgorovoy: absolutely true...
> (22:37:46) mgorovoy: actually, here's another thought...
> (22:37:58) mgorovoy: can the image generation be made progressive?
> (22:38:05) mgorovoy: so that it can be spit out in chunks
> (22:38:09) aaime: nope
> (22:38:21) mgorovoy: that's bad...
> (22:38:22) aaime: the WMS spec allows the client to specify the output in
> various formats
> (22:38:44) aaime: PNG, GIF, JPEG just to cite the raster image ones
> (22:39:09) mgorovoy: yeah, but any of these formats can be sent out chunked,
> the question is can it be produced chunked...
> (22:39:53) aaime: maybe I'm not following you. Chunked is just taking the
> image and splitting it into blocks of bytes to send out, yeah?
> (22:40:03) mgorovoy: right
> (22:40:22) aaime: nope, all compressions work on the image as a whole
> (22:40:31) mgorovoy: ahh, it has to be compressed
> (22:40:41) aaime: there is no "inner tiling" as we call it (some formats,
> like TIFF, allow for inner tiling)
> (22:41:18) mgorovoy: it seems like this protocol is too restrictive ;)
> (22:41:41) aaime: works fine with apache, probably who designed it did not
> have j2ee containers in mind
> (22:42:07) mgorovoy: yeah, apache does detect dropped connections with cgi
> (22:42:18) aaime: right, and it kills the cgi right away
>
> -----------------------------------------------------------------------
> _______________________________________________
> jetty-users mailing list
> jetty-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>