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