On 22 Oct 2009, at 08:50, ef-lists@xxxxxxxx wrote:
Hi folks,I've got some questions regarding module development and the possible situation that apache reloads its configuration.My module holds a reslist of connected sockets which are acquired and released/invalidated on each request. These connections are persistent and keeping them alive is a must (so there's no workaround for the reslist). The connections are themselves stateless - they're just for gathering some bits of information.I've got a handful of questions regarding this situation. When the configuration is reloaded (the socket endpoint is configured via the config), the configuration pool is destroyed. So it is obviously the wrong choice for allocating my reslist? I currently allocate them from the child pool in child_init.
Why is that wrong? When the configuration is reloaded, your module might be loaded or unloaded, configured or unconfigured. So any resources it uses
should be closed down and re-initialised. There's another reason not to use the configuration pool: you should never allocate from it in request processing. But that's different. Using the child pool could be OK, but risks a memory leak.
I thought about allocating the connections from the config pool (respectively a subpool of it), if and only if the reload happens when apache isn't currently handling any requests. Otherwise the reslist cleanup would abort() when any resource is still acquired, according to the documentation. I couldn't find any documentation when the config reload is exactly invoked, so it's really not clear to me if this would be the right way. Besides I think using the config pool wouldn't be thread safe?Just another question, to point things out for me: Each worker has its own copy of the (same) server_rec, right? And following, each server_rec in each worker has its own module configuration?
Since you've read the book and are identifying real issues (there's no simple way to get your task right), my best suggestion would be to look at modules
that do similar things: mod_dbd and mod_proxy_balancer spring to mind. Then move to the modules list if you have further questions, or even the dev list if you're unclear/unhappy about how these modules work.
Besides, I took a deeper look at mod_dbd, which does a similar job and it wasn't really clear to me. I guess the "groups" are there for handling a config change? As the connections are stateful, I'm unsure that this concept (if it works as I suspect) is a little bit overpowered for me?
Heh, you're ahead of my advice!mod_dbd was originally limited to one backend per virtualhost. Groups are about enabling multiple backends. I guess the proxy might be a better example.
-- Nick Kew --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|