[Okay, thanks to a judiciously gracious slap upside my head, I found
the original post to reply to...]
On Thursday 2009-02-25 14:02:15 PST, Luis Saenz wrote:
[...]
> Is there any way for the restlet application (server-side) to
> detect that the HTTP request (client-side) has terminated
> prematurely? (For example, either due to the client aborting or
> timing out.)
Without doing anything? No. You're struck waiting for the various
lower level timeouts on the socket and/or in the container to trigger
and then, depending on the container('s settings), how/when it might
propagate that information up to your code.
> Here is the scenario -- imagine a restlet application that exposes a
> resource that supports POST. This resource allows a lengthy
> representation to be sent from the client in the POST request body.
> For example, lets say the resource models a "container" and the POST
> method allows clients to load a (potentially large) dataset into
> this "container".
What do you mean by "large"? If you're talking on the order of a few
hundred KB then ignore it as a problem. :-) If you're talking about
ten's of megabytes then I think that's a separate design problem that
should be directly addressed.
> Now imagine that the resource implementation uses a relational data
> store to persist records that are POSTed, but persistence is a non-
> trivial operation that includes validation and various side-effects.
> Therefore, it might take 5 minutes to complete a POST operation for
> a dataset with half a million records. However, lets say that the
> implementation uses application server memory and batching
> techniques, so that only 10% of the total time (30 seconds) is used
> to send the actual POST body over the wire from client to server.
> The rest of the time, the client waits for a response while the
> server processes the request (the data persistence operation).
And what about issues like the same data being POSTed concurrently,
what about conflicting updates to subsets of the data, what about
failures in the client so it doesn't understand the success/failure,
what about pathological network behavior, etc.? I.e., it's not just
the problem of the single connection potentially having problem.
On Thursday 2009.02.26, at 09:45 , Luis Saenz wrote:
[...]
> By the way, I think you’re right -- I meant “synchronous” as in
> “blocking” and “asynchronous” as in “non-blocking.” And I mean this
> from the perspective of the server API. In other words, using the
> “post/redirect/get” pattern is “non-blocking” in terms of receiving
> output (the “processing report”) -- the client has to make a second
> API call to get the output, and it may not be ready right away. So
> it’s like a future -- the processing happens asynchronously from the
> initial submission of the data set, and the submission (the POST) is
> non-blocking in terms of it not having to wait for the output.
> Anyway, just wanted to clear up my meaning; I am probably not using
> the best terms.
In terms of the server, it's a separate implementation detail whether
it's blocking or not (w.r.t. to processing that request).
The separation of the client with the post/redirect/get pattern just
changes the *client* to a non-blocking 'future'-ish model. I.e., if
you use a thread pool model with a thread dedicated to processing the
entire set of checks and behaviors to handle the POSTed data vs. if
that's split out ala a SEDA approach, for example.
> I’m still curious if anyone has any ideas for detecting and handling
> a client-side “Control-C” gracefully, or any practical tips for
> implementing long-running and transactional POST operations.
Hmm... "Gracefully" is a whole 'nother question. What does that mean
for you? Are you wanting to try and detect the client hitting the
stop button and somehow abort the transaction that's already in
flight? Or something else?
As in most discussions of long-running "transactions"... Don't. Split
things out into a series of transactional steps. Think "workflows",
"proposals", and "compensations" rather than one single big-bang
transaction.
Take care,
John
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1234208
