On Tue, Sep 15, 2015 at 8:04 AM, Eric Covener wrote:
> SInce this is only on restarts, could we use the config generation
> number in the filename?
doh, just saw 1703157
SInce this is only on restarts, could we use the config generation
number in the filename?
On Mon, Sep 14, 2015 at 9:45 AM, Yann Ylavic wrote:
> PR 58024 looks hard(er) to resolve (details there)...
>
> It seems that DeleteFile() always fails when some file mapping exists
> on the file, which also prevents "deletion when the last handle to the
> file is closed".
>
On Mon, Sep 14, 2015 at 10:15 AM, Yann Ylavic wrote:
> So maybe we need a general ap_shm_create() wrapper usable wherever it may
> help?
> At least until a new APR_SHM_DELONCLOSE flag is added to apr_shm_create_ex()?
Sorry I was not too clear. The disk-cache issue is not
On Mon, Sep 14, 2015 at 10:52 AM, Yann Ylavic wrote:
> Oh I see, I guess FILE_FLAG_DELETE_ON_CLOSE is not suitable there
> since files are opened/closed by different processes...
> But if I read DeleteFile() doc correctly, for non-mapped files it
> should work (delayed until
PR 58024 looks hard(er) to resolve (details there)...
It seems that DeleteFile() always fails when some file mapping exists
on the file, which also prevents "deletion when the last handle to the
file is closed".
So currently (mod_slotmem_shm on trunk), the SHM files by generation
leak on the
On Mon, Sep 14, 2015 at 4:42 PM, Eric Covener wrote:
> On Mon, Sep 14, 2015 at 10:15 AM, Yann Ylavic wrote:
>> So maybe we need a general ap_shm_create() wrapper usable wherever it may
>> help?
>> At least until a new APR_SHM_DELONCLOSE flag is added to
On Mon, Sep 14, 2015 at 4:07 PM, Eric Covener wrote:
> On Mon, Sep 14, 2015 at 9:45 AM, Yann Ylavic wrote:
>> PR 58024 looks hard(er) to resolve (details there)...
>>
>> It seems that DeleteFile() always fails when some file mapping exists
>> on the file,
On Mon, Sep 14, 2015 at 4:58 PM, Eric Covener wrote:
> On Mon, Sep 14, 2015 at 10:52 AM, Yann Ylavic wrote:
>> Oh I see, I guess FILE_FLAG_DELETE_ON_CLOSE is not suitable there
>> since files are opened/closed by different processes...
>> But if I read
works for me. Thx!
That looks like a good solution. FWIW, ap_mpm_query(AP_MPMQ_IS_FORKED...
would be another way to express whether we need the config_gen.
On Tue, Sep 8, 2015 at 11:33 AM, Yann Ylavic wrote:
> I didn't reproduce it myself (no Windows machine), but the scenario
> and traces
I didn't reproduce it myself (no Windows machine), but the scenario
and traces in PR 58024 show what happens quite clearly.
On (graceful) restart, if one or more children remain when pconf is
cleared (SHMs are destroyed), apr_file_remove() fails (open file =>
ERROR_ACCESS_DENIED until all the
Instead of changing the default for all OSs, sounds like
some Windows specific changes may need to be done. Has anyone
using Windows actually seen this or confirmed this is
possible??
> On Sep 2, 2015, at 5:08 AM, Yann Ylavic wrote:
>
> Re PR 58024.
>
> AIUI, balancers
Re PR 58024.
AIUI, balancers (and members) SHM slots are destroyed (and the
underlying base file removed) with pconf before restarting and then
re-created after (according to the new configuration, eg. number of
balancers/members, be it the same or not).
Persisted slots are saved in their own
On Wed, Sep 2, 2015 at 11:48 AM, Plüm, Rüdiger, Vodafone Group
wrote:
>
> From: Yann Ylavic [mailto:ylavic@gmail.com]
>>
>> BTW, even on Unixes there is a race on these files between the main
>> process and the children, or the children themselves from different
On Wed, Sep 2, 2015 at 12:32 PM, Yann Ylavic wrote:
>
> How about the generation in the filename? Windows only?
Or maybe an mktemp() based file for each generation (which has also
the advantage to be implicitely DELONCLOSE).
> -Original Message-
> From: Yann Ylavic [mailto:ylavic@gmail.com]
> Sent: Mittwoch, 2. September 2015 11:08
> To: dev@httpd.apache.org
> Subject: Balancers (file based SHMs) and restart issue (Windows only?)
>
> Re PR 58024.
>
> AIUI, balanc
On Wed, Sep 2, 2015 at 12:14 PM, Yann Ylavic wrote:
> On Wed, Sep 2, 2015 at 11:48 AM, Plüm, Rüdiger, Vodafone Group
> wrote:
>>
>> From: Yann Ylavic [mailto:ylavic@gmail.com]
>>>
>>> BTW, even on Unixes there is a race on these files
18 matches
Mail list logo