|Re: [jetty-users] Re: How to check if the client dropped the connection|
I think this is going to be difficult to achieve due to the java io api. Basically, unless there is a read or a write scheduled, you simply don't get notification that the socket has closed. You can't trust endpoint.isOpen() if a read or write is notscheduled because the underlying java.nio.channels.Channel object does not correctly reflect the state of the socket.
If Andrea's processing can be done asynchronously then perhaps he can modify his client to make repeated requests (using something likemeta-refresh) until the image is ready to be returned. Something like return a place-holder image on the first and all subsequent requests until the image is ready. You'd need some kind of sweeper to clean up the server-side images that are never re-requested.
Using cometd to send a message to the server to request/cancel the image and a message to the client with the image would be a nicer async solution. cheers Jan Julio Viegas wrote:
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_______________________________________________ jetty-users mailing list jetty-users@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/jetty-users
-- Jan Bartel, Webtide LLC | janb@xxxxxxxxxxx | http://www.webtide.com
Back to the top