I am fixing a couple of bugs which turn out to have the same cause - the
internal plugin init call was moved to after the proxy port init for 3.2. This
causes crashes in both of these cases. I reverting the ordering to what it was
in 3.0 but I would like to keep the functionality desired by the original move.
If you look at TS-1487 you can see the original sketch of what was to be done.
I have most of that implemented and now just need to add the plugin lifecycle
hook logic. The current view is that we should create another hook API call
that is for these hooks (TSPluginHookAdd), rather than use TSHttpHookAdd
because the latter implies an HTTP transaction event, which is completely
different from this type of hook. Currently I plan to support only 2 events
(because of the time pressure), HTTP_PROXY_READY and CACHE_READY. I consider it
likely more will be added but these should be enough for 3.4. The SPDY plugin
can then hook on HTTP_PROXY_READY and do its additional initialization at that
point.
* Having wrestled with the logic, I don't think it's important to have a hook
between plugin init and literally opening the sockets. As far as I can tell,
the SPDY logic depends only on initializing the proxy port related data
structures, not the sockets themselves, and moving the socket open code up to
that level would be much more disruptive. Instead I have arranged it so all of
the data needed is computed, the plugin hook HTTP_PROXY_READY is called, then
the sockets are opened and accept threads started. This also makes it easy to
implement Ming Zym's request, delaying accepts until after cache ready. In that
case not opening the sockets until just before the listen/accept is a feature.
So -
plugin init
proxy port data structure init
HTTP_PROXY_READY hook.
socket open / listen / accept
CACHE_READY
If that works, I'll add a config value that skips socket o/l/a until the cache
is ready. I'm hoping to wrap this up in a day or two.
