On Fri, Mar 7, 2008 at 4:45 PM, Aaron Crow <[EMAIL PROTECTED]> wrote: > Hi John,
Howdy! > So as far as server app code dealing with a forced shutdown, may I ask what > you recommend for situations where there's some task running that really > should be allowed to complete? For example, would you have the concept of an > internal registry, where tasks are registered, and a shutdown signal means > "no new tasks allowed, and wait for running tasks to finish"? Perhaps. I haven't personally tried that approach with Reslet-based solutions (yet?). Partly because as you add more complexity to "solve" these sorts of gracefulness / robustness problems you add other areas where more problems can crop up. For example, what's happening to the client requests while the server is in that zombie state? Now you're having to have multiple servers and some way to dispatch to them -- which helps some things, adds other problems (you now have a SPOF with the dispatcher or devolve yet again and have to add more complexity at that level....), and you still have the original global failure mode (i.e., what happens when your entire cluster / data center / etc. goes dead) that you'll have to deal with one way or another anyways if you're really serious about the whole robustness thing. I.e., if you're requirements are not really that serious then why bother? It's more costly to actually deal with these problems well. Partly because for most web-based applications, if a request fails, the rich client can be (and the user is already) trained to just retry the action in those fairly rare cases (from the perspective of any given user) where their request gets hosed. In fact, for a "pure" REST approach, that's nominally trivial since that's the point of REST. And for systems with complex workflows you already have to be able to gracefully deal with interrupted "transactions", multiply submitted "transactions", etc. (well, okay, only if you care about correctness :-). Also, depending on the nature of the actual business domain involved there can also be legislated / contractual / conventional business level process to reconcile those various potential problems. For example, the check clearing system. So, the solution space your system has to live within definitely matters when deciding these kinds of things. Hope this helps (somehow :-). Have a great weekend, John
