Mantis - Resin
Viewing Issue Advanced Details
2870 minor always 08-26-08 08:30 09-04-08 14:09
ferg  
ferg  
normal  
closed 3.2.1  
fixed  
none    
none 3.2.1  
0002870: comet w/o skip
(rep by David Peterson)


Not sure if this is a bug or a feature-request, so
thought I'd start with the support channel.

I'm looking into different ways to delay processing
of a servlet request without tying up Resin's worker
threads. The comet/server-push additions seem
tantalizingly close to something we could use but
there is a one big show-stopper.

It appears that after CometServlet.service() is
called and after each call to CometServlet.resume()
(and at least one other time that I'm not sure
about) the server calls
AbstractHttpResponse.finish(), which in turn calls
AbstractHttpRequest.skip(). And the "skip" part is
the real problem for us.

We want to defer processing of the entire request -
we could use service() to figure out when to handle
the request and then schedule a later call to
resume(). But to do so with the current
implementation we would have to read the entire
request body prior to exiting servce() or else we
lose any posted data. We'd like to just leave the
request body buffered "on the wire" and pull the
data off when the request is serviced.

The attached servlet has a bare-bones example of
what I'm talking about. If a "delay" parameter is
passed to the request then when resume() is called
there is no data to be read off the wire. I have
been using curl to post the data like this:

curl --data-binary @random -H
Content-Type:application/octet-stream

http://localhost:8080/resin-doc/examples/servlet-comet/delayed-comet?delay=10 [^]

where "random" is just a local file filled with
garbage binary data (dd if=/dev/urandom of=random
bs=1M count=1)


Would it be possible (without breaking something
else) to check the connection and/or controller
status in finish() and not call skip()?

 AbstractHttpRequest.patch [^] (1,048 bytes) 08-26-08 09:56

Notes
(0003360)
david-peterson   
08-26-08 09:57   
I made the change in the attached patch, and things seem to work in my limited testing, but who knows what I may have broken.
(0003387)
ferg   
09-04-08 14:09   
server/1l60