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 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: module development,clean handling of configuration reload

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 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: module development, clean handling of configuration reload

> > 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.
This was my original idea. It is just unclear to me, wenn the reload is invoked. In other words, can I be sure that request processing completed? Otherwise, destroying the reslist would trigger an abort() if any resources are still in use. Hmm... just thinking loud... it would obviously be wrong to kill the server_recs when request processing still takes place.

> There's another reason not to use the configuration pool: you should
> never allocate from it in request processing. But that's different.
Can you point this out, please? Does this mean, that acquiring from a reslist whose (constructors allocate from the configuration pool) is evil? And if so, why?

Of course it's clear to me, that frequent allocation from the configuration pool in requests would consume all memory without cleanup. That's what the request pool is for. :)

> Using the child pool could be OK, but risks a memory leak.
That's clear to me, thanks to your book. :-)

> > 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.
Ah okay, this makes sense. I'll look at mod_proxy_balancer. Enabling multiple backends shouldn't be of interest to me.


Thank you!

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See 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