You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by ef...@email.de on 2009/10/22 09:50:37 UTC

[users@httpd] module development, clean handling of configuration reload

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.
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?

I tried the following steps to find the information myself:
- searched google
- checked tutorials on the net
- checked the apr and apr-util documentiation
- bought and considered The Apache Modules Book by Nick Kew

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?

Oh and by the way:
I'm developing for Apache 2.2(.14 currently) with the worker-mpm.

I hope you can help me out with my questions. Any help will be greatly appreciated.

Regards,
Edgar

---------------------------------------------------------------------
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@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] module development, clean handling of configuration reload

Posted by Nick Kew <ni...@webthing.com>.
On 22 Oct 2009, at 08:50, ef-lists@email.de 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@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org