Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: 76.96.30.80 is neither permitted nor
 denied by domain of jim@jagunet.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: memory leak in mod_slotmem_shm
From: Jim Jagielski <jim@jaguNET.com>
In-Reply-To: <201009271919.29125.sf@sfritsch.de>
Date: Mon, 27 Sep 2010 13:56:24 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <DE6B4F99-B7F4-454C-B071-790CA62E9C55@jaguNET.com>
References: <201009261813.27244.sf@sfritsch.de>
 <201009271628.01835.sf@sfritsch.de>
 <D127495D-33AD-4ADA-BE8F-5D8BCF3858ED@jaguNET.com>
 <201009271919.29125.sf@sfritsch.de>
To: dev@httpd.apache.org


On Sep 27, 2010, at 1:19 PM, Stefan Fritsch wrote:

> On Monday 27 September 2010, Jim Jagielski wrote:
>>> BTW, it is not that obvious that the shm is supposed to be
>>> cleaned up  and re-created on graceful restarts. This should be
>>> documented in the code.
>>> 
>>> 
>> 
>> That's an interesting point. I always assumed that it should be,
>> since one use for it would be as a scoreboard-like replacement
>> (and the pain for the scoreboard is that it's a set size)...
>> But I can also see reasons for it to NOT be cleaned/recreated...
>> How best to handle that??
> 
> If it would be used for e.g. storing mod_proxy_balancer's worker 
> configuration/state, one would want the data to survive a graceful 
> restart, wouldn't one? But from a consumer's perspective, it doesn't 
> matter if this achieved by not destroying the shm segment or by saving 
> the data to disk and reloading it after recreating the shm segment.
> So it seems to me that the current functionality is enough.
> 

But it *does* persist the data... it just clears up
the sh mem.