Breaking content generation phase into multiple phases or adding custom events in content phase
Kaustubh Deorukhkar
kaustubh.deo at gmail.com
Wed Jun 17 18:17:06 UTC 2015
Hi,
I am working on a custom module where I need to use a third party library
and make sync/async calls to APIs. I do not have control over what the
library does internally but any async API call on library would call a
callback which indicates that content generation phase continue with
forming response and sending it back to client.
Here is psuedo code:
- content_handler_called
-- some_initializations
-- Call library Async API with callback
-- nginx should continue processing other events
...
-- some point of time the callback is triggered, which should resume the
request say by raising a custom event in nginx event loop so nginx can
process remaining part of request.
As i understand nginx works primarily on events based on sockets but in
this case invocation of this library api cannot generate any socket events.
Question is how do I pause the current request processing so nginx can
continue with other requests and when api callback is trigger, nginx should
be able to resume the request processing.
Looking at some other modules I found
1> mysql module intercepts the socket calls of libmysqlclient
2> we can use additional socket to communicate between API callback and
nginx event loop.
3> I believe openresty lua module should be achieving similar async
behavior for content handler phase.
1 is not possible, 2 is a bit bad due to additional sockets. Anyone can
throw some light how openresty lua module achieves this?
We want to avoid upstream server model if this is already possible with
nginx.
Is there some mechanism to trigger custom events.
Is the nginx event loop thread safe if we have some mechanism to trigger
custom events?
Hoping for inputs. Thanks in advance!!
Kaustubh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20150617/d693aff8/attachment.html>
More information about the nginx-devel
mailing list