|Re: [jetty-users] Re: How to check if the client dropped the connection|
Jan Bartel ha scritto:
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.
What about a non NIO approach, plain streams? Is it still doable? Web GIS request are heavy, no one is really looking to serve many users with a single server, the approach to scale up is to create load balanced clusters instead (which is easy since the protocols are stateless).
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 imageand a message to the client with the image would be a nicer async solution.
Unfortunately I'm not in control of the protocol, which is specified in an international standard (here, if you're curious http://portal.opengeospatial.org/files/?artifact_id=1058) and does not allow for any asynchronicity. The server has to be put up, online, and any kind of client talking the same protocol can connect. There is simply no way to have any control over the client behavior. Cheers Andrea
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@xxxxxxxxxxxxxxAgain, 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 threadpool to process requests and have the servlet threads wait for the threadpool to complete processing(22:26:08) aaime: the question is, how do I get to know the client droppedthe connection(22:26:10) mgorovoy: you could when store the session ID as parameter of thethread (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 clientdropped the connection(22:26:35) mgorovoy: and every new request should check if there's already athread 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 easierto 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 membersof 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 requestis 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 whateverlocation 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 thatI 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 theclient (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 itwants (22:30:58) aaime: not cool at all(22:31:12) aaime: apache + cgi is smart enough to kill the cgi process whenthe 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 forwould 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, youonly 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 designedfor 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 responsesright away(22:33:49) mgorovoy: you should ping gregw when he comes online in a coupleof 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 ofthe above chat? (22:35:14) mgorovoy: no problem(22:35:15) aaime: gregw will probably make some of the same questions youdid (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'sbetter 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 invarious 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 theimage 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 nothave 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
-- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers.
Back to the top