Sending Responses Later
danii opened this issue · 6 comments
Whenever a function is called to handle a request, it is required to return a response, and as such there is no way to send a response at a different point in time without use of some sleep method.
Hmm, the nature of HTTP is very request-response oriented. clastic is often used with other concurrency/parallelism frameworks (e.g., gevent), but what you say stays true: A request handler (endpoint function) must return a response.
What about long polling systems? Where a request is made, and the response comes either before a typical browser's response timeout, or when new data is available?
Ah, well, long-polling fits into the HTTP request/response cycle via the mechanism you described (sleeping/checking/sleeping). Note that long-polling has become less popular these days as either short-polling often works fine, and WebSockets often work better for the remaining cases. (Note that clastic doesn't support WebSockets, yet.)
Isn't sleeping / checking / sleeping blocking? If so does clastic support multi-threading?
Clastic definitely supports multithreading, though if you're expecting each worker process to field a lot of connections, you may want to use greenthreads or similar. I've written about our high-scale clastic usage here: https://medium.com/paypal-engineering/introducing-support-98945f023a8e
(Note that the port from WordPress to Medium messed with the formatting, but hopefully it's still comprehensible. :) )
Alright, thank you!