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.