httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <steve....@uk.radan.com>
Subject Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
Date Thu, 29 Mar 2007 10:03:01 GMT
Randy Kobes wrote:
> On Thu, 22 Mar 2007, Steve Hay wrote:
> 
>> Randy Kobes wrote:
>>> On Wed, 14 Mar 2007, Steve Hay wrote:
>>>
>>>> I tried your patch with the current svn version (revision 518242), 
>>>> but I'm still seeing intermittent failures (usually in tests 15, 16 
>>>> and/or 20) either when I run "nmake test" from the top-level,
> [ ... ]
>>>
>>> Perhaps just to narrow things down, could you try the
>>> attached C file (a VC++ Makefile is also attached)?
> [ ... ]
>> I ran each program with an argument of 500 for good measure.  All four 
>> programs successfully create and then delete a large number 
>> (presumably 500, I didn't count 'em!) of apreq* temp files.
>>
>> apr_temp and apr_temp_sh both deleted all those files about as quickly 
>> as they were made (i.e. very quickly), while apr_temp_nc and 
>> apr_temp_nc_sh both output loads of CLEANUP messages in the console 
>> quickly but then seemed to hang for nearly a minute, during which time 
>> loads of apreq* files were visible in the temp directory, and then 
>> eventually exited and all the files disappeared.
> 
> On my system (Windows XP, VC++ 6, Apache/2.2.2), there's
> essentially no difference in speed between the four
> programs in cleaning things up, and like you, all temp
> files are gone at the end. I'm afraid I'm stuck ...
> Since for you apr_temp/apr_temp_sh (fast) and
> apr_temp_nc/apr_temp_nc_sh (hangs a minute) pairwise
> behave similarly, that suggests APR_SHARELOCK isn't
> relevant (which is supported by it's apparent lack of
> relevance to this problem in the Apache sources). APR_FILE_NOCLEANUP 
> does seem to make a (negative)
> difference in speed, but perhaps
>    http://marc.info/?l=apr-dev&m=117448738223552&w=2
> is relevant here. In any case, the above results suggests
> that having APR_FILE_NOCLEANUP and APR_SHARELOCK both
> undefined would be better, which makes sense, but
> both apparently help in the Perl glue on Win32. Sigh ...
> 
> I'm wondering the following ... The failed upload
> tests (15, 16, and/or 20), for me, involve uploading
> the perl.exe binary. Is that the same for you? Might
> there be a problem with uploading a file which is
> a program that might be in use at the time? Does the
> attached patches against
>    apreq/library/util.c
> which removes the
>    flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK
> line, and
>    apreq/glue/perl/t/apreq/upload.t
> which skips using perl.exe (and httpd.exe) for
> the upload tests on Win32 work for you?

I've tried running both "nmake test" and just the upload.t test many 
times over each and haven't yet seen either one fail with those two 
changes in place :-)

If I just apply the util.c change (i.e. drop the NOCLEANUP and SHARELOCK 
flags, but continue using perl.exe and httpd.exe for the upload tests) 
then all the tests still seem to pass anyway, but I do then see some 
stray "apreqXXXXXX" files left over in my temp directory from time to 
time (mostly when running "nmake test" rather than just the upload.t 
test), which didn't happen with the upload.t change applied as well.

That's really weird. I'm not sure I understand what's going on, but I 
think you might have cracked it at last!

-- 

Mime
View raw message