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