Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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 not
scheduled 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 like
meta-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.


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@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





--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Back to the top