Lawrence Oluyede wrote: > On Tue, Mar 3, 2009 at 9:57 PM, kmw <[email protected]> wrote: >> When I get the request I add the item to a synchronized queue (which >> the processing thread blocks on) and return a HTTP 201 Accepted to the >> client. The processing thread picks up tasks from the queue and they >> are completed in the order received. The 201 response also has an >> additional Location header to poll the status of the task. > > Just to clarify a thing: 201 is CREATED, 202 is ACCEPTED. > Don't send 201 instead of 202 because they have different meanings: > <http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html> > > About the matter at hand: we spawn some process in that kind of > situation. Not threads. > If you have scalability issues you can think about using the ampq > protocol with an implementation such as rabbitmq > I'm +1 about using 202 ACCEPTED :-) >
I meant to say 202 Accepted not 201, that's what you get for trying to remember HTTP status codes. I am also leaning towards using processes instead of threads (using the multiprocessing module) but to play devil's advocate for moment why do you prefer processes to threads? Secondly, and this is pertinent when spawning processes, how do you hook into the pylons shutdown process to get the external process to stop? Cheers, - Kochhar --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
