Nabble - APR Dev (Apache Portable Runtime)

Re: apr_memcache 1.3.X sending unnecessary QUIT to memcached server

2008-10-07T15:08:49Z

On Fri, Oct 3, 2008 at 3:48 AM, Ruediger Pluem <rpluem@...> wrote:

> I guess the documentation is wrong. This behaviour was changed a while
> ago to the behaviour you describe: If a resource is expired it will not
> be handed out any longer but it will be closed. This is needed / useful
> e.g. for database connections that become faulty after some time because
> the database server closes them after some time of inactivity or a firewall
> in between breaks the connection after some time. It is also very useful
> when pooling persistent http connections and you know the keepalive
> timeout settings of your backend.

With the current revision of apr_util (apr_memcache) we were
encountering a memory leak issue and sub-optimal behavior in the
following scenario:

A massively parallel application (several hundred processing threads),
each needing (during message processing) to make several memcache
queries every second. A patch was applied recently that effectively
handles memory leaks in the apr_memcache module by calling free on the
APR Pool from the Resource List destructor every TTL microseconds.
This put users of the memcache module in some what of a bind, they are
forced to choose between:
- Setting the TTL to a high value and leaking memory under high load
circumstances (the TTL is never hit because each socket is being used
frequently)
As a side note we considered modifying the socket selection algorithm
to incrementally move through the socket list (currently it selects
the first available socket), this would allow us to set a large TTL
(reduce TCP connection overhead) but necessitates a large minimum
number of connections to the memcache server
- Setting the TTL to a low value (hundreds or thousands of
microseconds) and having to reconnect to the memcache server for each
request

What we are trying to accomplish is having a large number (50-100) of
persistent connections to the memcache server(s). This is not
currently possible without leaking large amounts of memory.

The reason the current stable revision of apr_memcache is leaking
memory is due to its use of a Bucket Brigade structure inside the
socket/conn structure, it copies the data off of the socket buffer
into this Bucket Brigade and then copies onto the APR Pool specified
in the apr_memcache_getp function call. The data stays in the Bucket
Brigade until the TTL expires on the socket/conn in which case both
the socket is torn down and the Bucket Brigade is cleared.
Our fix simply removes this extra step and bypasses the Bucket
Brigade, instead copying the data directly to the pool specified in
the apr_memcache_getp function call.

This has worked great for us, no more memory leaks and very few TCP
reconnections (TTL at 120 second, 120,000,000 micro seconds),
hopefully it works well for everyone else in the community :)

Credits for this patch go to:
Tavis Paquette (tavis at galaxytelecom dot net)
Peter Baer (pbaer at galaxytelecom dot net)

[apr-util-1.3.4.patch]

--- apr-util-1.3.4.old/memcache/apr_memcache.c 2008-08-12 18:47:05.000000000 +0000 +++ apr-util-1.3.4/memcache/apr_memcache.c 2008-10-06 20:00:40.000000000 +0000 @@ -797,39 +797,26 @@ apr_memcache_getp(apr_memcache_t *mc, *baton = NULL; } else { - apr_bucket_brigade *bbb; - apr_bucket *e; - - /* eat the trailing \r\n */ - rv = apr_brigade_partition(conn->bb, len+2, &e); - + rv = get_server_line(conn); if (rv != APR_SUCCESS) { ms_bad_conn(ms, conn); apr_memcache_disable_server(mc, ms); return rv; } - - bbb = apr_brigade_split(conn->bb, e); - - rv = apr_brigade_pflatten(conn->bb, baton, &len, p); - - if (rv != APR_SUCCESS) { + if (len > conn->blen) { ms_bad_conn(ms, conn); apr_memcache_disable_server(mc, ms); - return rv; + return APR_EGENERAL; } - - rv = apr_brigade_destroy(conn->bb); - if (rv != APR_SUCCESS) { + *baton = apr_palloc(p, len+1); + if (*baton == NULL) { ms_bad_conn(ms, conn); apr_memcache_disable_server(mc, ms); - return rv; + return APR_ENOMEM; } - - conn->bb = bbb; - - *new_length = len - 2; - (*baton)[*new_length] = '\0'; + memcpy(*baton, conn->buffer, len); + (*baton)[len] = '\0'; + *new_length = len; } rv = get_server_line(conn);

Bug report for APR [2008/10/05]

2008-10-05T23:08:45Z

+---------------------------------------------------------------------------+
| Bugzilla Bug ID |
| +---------------------------------------------------------------------+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned |
| | OPN=Reopened VER=Verified (Skipped Closed/Resolved) |
| | +-----------------------------------------------------------------+
| | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major |
| | | MIN=Minor NOR=Normal ENH=Enhancement TRV=Trivial |
| | | +-------------------------------------------------------------+
| | | | Date Posted |
| | | | +--------------------------------------------------+
| | | | | Description |
| | | | | |
|16056|Inf|Enh|2003-01-14|Shared memory & mutex ownership not correctly esta|
|20382|New|Nor|2003-05-31|Poor performance on W2000 AS |
|28453|New|Enh|2004-04-18|apr_uri should parse relative to a base URI |
|33188|Inf|Nor|2005-01-21|libtool linking failure on Suse |
|33490|Inf|Nor|2005-02-10|APR does not compile with Borland C++ |
|38410|New|Nor|2006-01-27|apr/win32 misinterpreted the meaning of WAIT_ABAND|
|39289|New|Enh|2006-04-12|test suite additions for trylock functions |
|39853|Inf|Nor|2006-06-21|apr_strtoi64 does not build on WinCE due to lack o|
|39895|New|Enh|2006-06-23|apr_os_strerror on WinCE needs to xlate unicode->u|
|39896|New|Enh|2006-06-23|Output test status to OutputDebugString in additio|
|40020|New|Enh|2006-07-11|Add support for apr_uint8_t and apr_int8_t types |
|40193|Inf|Nor|2006-08-06|Patches to support different compiler than EMX on |
|40622|New|Enh|2006-09-27|enhance apr temp files on NT to be more secure |
|40758|Ver|Maj|2006-10-15|WIN64, apr_vformatter(..) cannot handle 64bit poin|
|40939|New|Enh|2006-11-09|pool minimal allocation size should be configurabl|
|41099|New|Enh|2006-12-03|Manually block apr_queue_pop(), apr_queue_push(), |
|41192|Inf|Trv|2006-12-17|Add the expat libtool file to the LT_LDFLAGS varia|
|41254|New|Enh|2006-12-28|apr_queue_t enhancements |
|41351|Ass|Enh|2007-01-11|Tivoli LDAP SDK support in aprutil |
|41352|Ass|Min|2007-01-11|openldap and per-connection client certificates in|
|41807|New|Enh|2007-03-10|dbd driver registration function |
|41916|Inf|Nor|2007-03-21|MinGW support |
|42365|New|Enh|2007-05-09|Suppress console for apr_proc_create() created pro|
|42728|New|Nor|2007-06-23|mod_ssl thread detaching not releasing handles |
|42848|New|Enh|2007-07-10|add IP TOS support to apr_socket_opt_set() |
|43000|Ass|Blk|2007-07-30|./testall always freeze on testsockets |
|43035|New|Enh|2007-08-04|Add ability to wrap ssl around pre-existing socket|
|43066|New|Nor|2007-08-08|get_password on Windows is kludgy |
|43152|Inf|Nor|2007-08-16|apr_socket_opt_get doesn't work with APR_SO_SNDBUF|
|43172|Ass|Nor|2007-08-20|apr-util don't want to find mozldap-6.x |
|43217|New|Min|2007-08-26|All-ones IPv6 subnet mask not accepted |
|43244|New|Enh|2007-08-29|apr_socket_t missing dup, dup2 and setaside |
|43302|New|Nor|2007-09-04|apr_bucket_socket doesn't work with non-connected |
|43309|New|Enh|2007-09-05|add apr_socket_sendtov support |
|43375|Ass|Nor|2007-09-13|Pool integrity check fails for apr threads |
|43499|New|Nor|2007-09-27|apr_global_mutex_create returns error "Access deni|
|43507|New|Enh|2007-09-28|configure flag for SHELL_PATH |
|43508|New|Enh|2007-09-28|Please be available whether atomics use thread mut|
|43793|New|Enh|2007-11-04|builtin atomics on Windows |
|44127|New|Enh|2007-12-21|File Extended Attributes Support |
|44128|New|Enh|2007-12-21|apr_os_file_put() does not register a cleanup hand|
|44129|New|Enh|2007-12-21|apr_os_dir_put() does not allocate an entry buffer|
|44186|New|Nor|2008-01-08|[PATCH] Add memcached 1.2.4 features to apr_memcac|
|44230|New|Enh|2008-01-14|Add Ark Linux support to config.layout |
|44432|New|Enh|2008-02-15|patch - proposal for application function hooks |
|44550|Inf|Maj|2008-03-06|Solaris sendfilev() handling - EINTR appears to ha|
|44684|Inf|Nor|2008-03-26|32 libexpat used instead of 64 bit |
|44761|Inf|Nor|2008-04-06|apr_uri_parse doesn't set path to "/" for 'http://|
|45232|Ass|Nor|2008-06-18|Empty APU_MODULES makes sh syntax error |
|45256|New|Maj|2008-06-23|lack of object check for null value cause expectio|
|45276|Opn|Nor|2008-06-25|Little issue with srclib/apr-util/Makefile |
|45291|New|Nor|2008-06-26|apr_thread_t is leaking |
|45298|New|Nor|2008-06-27|apr_os_thread_get() differs between windows and un|
|45321|New|Min|2008-07-01|Handling IPV6_V6ONLY on NT 5.x |
|45389|New|Nor|2008-07-13|testrand fails 5 tests (55%) - "line 62: randomnes|
|45455|New|Nor|2008-07-22|rwlock sometimes allows a writer to take the lock |
|45496|New|Enh|2008-07-29|[patch] adding directory matching [dir/**/conf.d/*|
|45615|Inf|Nor|2008-08-11|"Large Files not supported" with 64-bit build |
|45650|New|Min|2008-08-19|Application reports "The entry point freeaddrinfo |
|45679|New|Nor|2008-08-23|SHA1 passwords starting with {SHA} don't work and |
|45700|New|Nor|2008-08-27|incorrect sort order of apr_strnatcmp with non-ASC|
|45800|New|Nor|2008-09-13|nonsensical code in srclib/apr/locks/beos/thread_c|
|45857|New|Trv|2008-09-21|Possible mistake in doc for APR_DECLARE_DATA docum|
|45930|New|Nor|2008-10-01|httpd.worker MPM fails to reset signal mask before|
+-----+---+---+----------+--------------------------------------------------+
| Total 64 bugs |
+---------------------------------------------------------------------------+

Re: Corrected: global_mutex on Solaris 10, does it actually work?

2008-10-05T17:33:28Z

Jim Jagielski wrote:
> All this gets back to a pet enhancement of mine: the way to set, at
> runtime, the mutex-type used for APR_LOCK_DEFAULT... Sometimes the
> compile-type selection is non-optimal, and it would be great
> to be able to adjust this for each specific impl, regardless
> of how built.

Leads straight into the obvious question, where do we store 'apr
performance and behavior characteristics'?

It came up 6 or 7 years ago or so, and because the need wasn't that
pressing, it wasn't resolved.

On win32, one would think the registry makes good sense. On unix,
an /ect/apr.conf file makes good sense. Other suggestions, ideas
and exceptional cases?

Re: Corrected: global_mutex on Solaris 10, does it actually work?

2008-10-05T07:03:21Z

All this gets back to a pet enhancement of mine: the way to set, at
runtime, the mutex-type used for APR_LOCK_DEFAULT... Sometimes the
compile-type selection is non-optimal, and it would be great
to be able to adjust this for each specific impl, regardless
of how built.

comments?

Static build of iconv CCS / CES under windows platfrom - Link problem

2008-10-05T03:28:43Z

To whom it may concern.

I think there is a problem with the build of apr-iconv ccs/ces on windows when linked with static libs.

On the modules.mk.win file, There is a line for every build which sentence for the linker which libs to use (ex. Line: 21)

But under every debug static build of any platform (Lines: 50, 92, 134 and 176), the line says

“APR_LIB = … “

Instead of

“API_LIBS = …”

Correcting it, fix the static build.

To reproduce the problem, one should use the following build command:

NMAKE /nologo /f Makefile.win BUILD_MODE="Win32 Debug" BIND_MODE=static

Affected version: libiconv 1.12

Please, do tell me if I got it all wrong.

Thanks,

Assaf.

Re: Maybe global_mutex breakage isn't a problem

2008-10-04T16:18:48Z

On Sat, Oct 4, 2008 at 12:52 PM, Tim Bray <Tim.Bray@...> wrote:
> Um, maybe I'm an idiot. There is after apr_file_lock(), which seems made to
> order. Just because I was thinking "mutex" didn't mean I actually needed
> one.

Yup, plus apr_file_lock() has the benefit of anything else on the OS
doing file locking will also fail - with a 'global' mutex, in order
for it to work, it requires a process/thread-level relationship.
(APR, by default, will use SysV semaphores with IPC_PRIVATE, so they
aren't shared across two independent processes.) -- justin

Maybe global_mutex breakage isn't a problem

2008-10-04T12:52:56Z

On Oct 3, 2008, at 1:55 PM, Tim Bray wrote:

> Good question. Let me present the problem at a high level. There's
> a file that is regularly refreshed, and I only want one request
> handler rebuilding it at a time, because otherwise there are lots of
> horrible race conditions. I don't know whether I'm in worker or
> prefork mode. So I simply want to serialize update of this file,
> and I thought apr_global_mutex_* was a good way to do this. Is
> there a better way? -Tim

Um, maybe I'm an idiot. There is after apr_file_lock(), which seems
made to order. Just because I was thinking "mutex" didn't mean I
actually needed one.

-Tim

Re: apr_file_* weirdness on Mac OS X

2008-10-04T01:46:13Z

On Fri, 2008-10-03 at 08:50 -0700, Tim Bray wrote:

> Um, I know that. But apr_file_mktemp doesn't let you control where
> the temp file goes, right?

If you give it full pathname in the template, doesn't that allow you to
put it where you want it?

--
Bojan

Re: Corrected: global_mutex on Solaris 10, does it actually work?

2008-10-03T23:28:09Z

On Oct 3, 2008, at 1:03 PM, William A. Rowe, Jr. wrote:

> If we compare this to apr_shm_create / apr_shm_attach, it's pretty
> clear we
> are just missing the mechanics to solve this. apr_proc|
> global_mutex_attach
> is missing, and this should just be mopped up for apr 1.4.0, and
> absolutely
> before 2.0.0.
>
> The other solutions that come to mind are all very, very crufty
> hacks against
> specific solutions, e.g. an apr_os_proc_mutex_put sort of solution.
> It really
> is the API that needs repair.

Assuming Bill's right and this is actually a missing API, let me add
some urgency with a use case.

What I'm doing is implementing PUT, for the AtomPub protocol, against
a file-backed store. Since it's file-backed, it fits very nicely in
with httpd's default code paths.

For PUT, I want to be able to support conditional update with ETags
and If-Match headers; done correctly, this can guarantee against lost
updates. But this totally obviously needs a critical section. After
you've done map_to_storage to find the file your r->uri maps to, you
*really* need to grab a global_mutex against that file while you
compute the ETag and compare it to the If-Match value, and either
reject or accept-and-implement the PUT.

Summary: you can't implement PUT correctly inside httpd unless you can
create and attach to arbitrary mutexes at runtime.

I've actually figured out a way to kludge around this, but it's kinda
gross.

-Tim

Re: Corrected: global_mutex on Solaris 10, does it actually work?

2008-10-03T14:47:17Z

On 10/03/2008 10:55 PM, Tim Bray wrote:

> On Oct 3, 2008, at 1:16 PM, Ruediger Pluem wrote:
>
>> This maybe because the default locking mechanism on OS X is different
>> from the
>> one on Solaris. AFAICR Solaris has fcntl as default mechanism.
>> The question is: Why do you create this file beforehand? If a file
>> needs to be
>> created apr_global_mutex_create will do this for you.
>
> Good question. Let me present the problem at a high level. There's a
> file that is regularly refreshed, and I only want one request handler
> rebuilding it at a time, because otherwise there are lots of horrible
> race conditions. I don't know whether I'm in worker or prefork mode.
> So I simply want to serialize update of this file, and I thought
> apr_global_mutex_* was a good way to do this. Is there a better way? -Tim

It seems that you have found the correct way. It is just that the file
you want to refresh from one request handler and the file that is eventually
used for locking are two different things. Using the default method it is not
even clear if the filename is used depending on the platform you use. So consider
the filename as some sort of abstract name for your lock that needs to be
known to use the same lock in a different process. But I am no expert on this
and as Bill mentioned in the other mail the APR API might lack the needed operations,
if there is no parent / child relationship between them.
As you seem to work inside httpd I think you should use the post_config hook to create
the global mutex and the child_init hook to reattach to this lock in each
child via

apr_global_mutex_child_init

Regards

Rüdiger

Re: Corrected: global_mutex on Solaris 10, does it actually work?

2008-10-03T13:55:47Z

On Oct 3, 2008, at 1:16 PM, Ruediger Pluem wrote:

> This maybe because the default locking mechanism on OS X is
> different from the
> one on Solaris. AFAICR Solaris has fcntl as default mechanism.
> The question is: Why do you create this file beforehand? If a file
> needs to be
> created apr_global_mutex_create will do this for you.

Good question. Let me present the problem at a high level. There's a
file that is regularly refreshed, and I only want one request handler
rebuilding it at a time, because otherwise there are lots of horrible
race conditions. I don't know whether I'm in worker or prefork
mode. So I simply want to serialize update of this file, and I
thought apr_global_mutex_* was a good way to do this. Is there a
better way? -Tim

Re: Corrected: global_mutex on Solaris 10, does it actually work?

2008-10-03T13:16:41Z

On 10/03/2008 09:39 PM, Tim Bray wrote:

> Correcting two errors in my original post, why don't I just copy & paste?
>
> So, there's this file I want to update, suppose its name is in the
> variable "filename", so I go
>
> status = apr_global_mutex_create(&mutex, filename, APR_LOCK_DEFAULT,
> pool);
>
> And on Solaris 10, this fails with EEXIST, i.e. strerror says "File
> exists". (This doesn't happen on OS X). Well, yeah, it exists, I

This maybe because the default locking mechanism on OS X is different from the
one on Solaris. AFAICR Solaris has fcntl as default mechanism.
The question is: Why do you create this file beforehand? If a file needs to be
created apr_global_mutex_create will do this for you.

Regards

Rüdiger

Re: apr_file_* weirdness on Mac OS X

2008-10-03T13:10:52Z

On 10/03/2008 05:50 PM, Tim Bray wrote:

> Um, I know that. But apr_file_mktemp doesn't let you control where the
> temp file goes, right? And now that I think of it, the file can be

No, of course you can control where the file goes. Just fill the templ
parameter appropriately:

http://apr.apache.org/docs/apr/1.3/group__apr__file__io.html#gc34981f9ff41f85e4377a6dde185fe52

Regards

Rüdiger

Re: Corrected: global_mutex on Solaris 10, does it actually work?

2008-10-03T13:03:18Z

Tim Bray wrote:
> Correcting two errors in my original post, why don't I just copy & paste?
>
> So, there's this file I want to update, suppose its name is in the
> variable "filename", so I go
>
> status = apr_global_mutex_create(&mutex, filename, APR_LOCK_DEFAULT,
> pool);

Create says exactly that.

I was thinking apr_global_mutex_child_init but that clearly isn't it, because
it expects an initialized lock.

If we compare this to apr_shm_create / apr_shm_attach, it's pretty clear we
are just missing the mechanics to solve this. apr_proc|global_mutex_attach
is missing, and this should just be mopped up for apr 1.4.0, and absolutely
before 2.0.0.

The other solutions that come to mind are all very, very crufty hacks against
specific solutions, e.g. an apr_os_proc_mutex_put sort of solution. It really
is the API that needs repair.

Bill

Corrected: global_mutex on Solaris 10, does it actually work?

2008-10-03T12:39:07Z

Correcting two errors in my original post, why don't I just copy &
paste?

So, there's this file I want to update, suppose its name is in the
variable "filename", so I go

status = apr_global_mutex_create(&mutex, filename,
APR_LOCK_DEFAULT,
pool);

And on Solaris 10, this fails with EEXIST, i.e. strerror says "File
exists". (This doesn't happen on OS X). Well, yeah, it exists, I
want to update it, that's what the mutex is for, sigh. So I created
another filename called

mutex_file = apr_pstrcat(pool, filename, ".mutex", NULL);

and locked that, which worked until the first time another process
wanted to wait on the mutex, and it couldn't create the mutex to wait
on it because the file existed. So, I'm confused... how can I get an
apr_global_mutex_t to wait on in this scenario?

Pardon the stupidity. -T

global_mutex on Solaris 10, does it actually work?

2008-10-03T11:50:25Z

So, there's this file I want to update, suppose its name is in the
variable "filename", so I go

status = apr_global_mutex_create(&mutex, mutex_file,
APR_LOCK_DEFAULT,
pool);

And on Solaris 10, this fails with EEXIST, i.e. strerror says "File
exists". (This doesn't happen on OS X). Well, yeah, it exists, I
want to update it, that's what the mutex is for, sigh. So I created
another filename called

mutex_file = apr_pstrcat(pool, filename, ".mutex");

and locked that, which worked until the first time another process
wanted to wait on the mutex, and it couldn't create the mutex to wait
on it because the file existed. So, I'm confused... how can I get an
apr_global_mutex_t to wait on in this scenario?

Pardon the stupidity. -T

Re: apr_file_* weirdness on Mac OS X

2008-10-03T08:50:50Z

On Oct 3, 2008, at 8:41 AM, Erik Huelsmann wrote:

>

>> Well, this isn't actually a temp file. Once it's written and
>> closed, I
>> want to move it into its final location as quickly as possible, so
>> I thought
>> it would be good to have it in the same directory where it's going
>> to end up
>> and avoid doing a copy. But if this kind of thing is going to
>> happen, you
>> probably have a point. -Tim
>>
> You don't need it in the same directory, you need it on the same
> volume to avoid the copy.

Um, I know that. But apr_file_mktemp doesn't let you control where
the temp file goes, right? And now that I think of it, the file can
be fairly large. Grmph. If it is OS X, this seems like an
*egregious* violation of unix filesystem semantics. -T

Re: apr_file_* weirdness on Mac OS X

2008-10-03T08:41:10Z

On Fri, Oct 3, 2008 at 5:15 PM, Tim Bray <Tim.Bray@...> wrote:

> On Oct 3, 2008, at 6:22 AM, Bojan Smojver wrote:
>
>> On Fri, 2008-10-03 at 01:13 -0700, Tim Bray wrote:
>>
>>> i.e. a randomized name in the same directory.
>>
>> Have you tried using apr_file_mktemp()?
>
> Well, this isn't actually a temp file. Once it's written and closed, I
> want to move it into its final location as quickly as possible, so I thought
> it would be good to have it in the same directory where it's going to end up
> and avoid doing a copy. But if this kind of thing is going to happen, you
> probably have a point. -Tim
>

You don't need it in the same directory, you need it on the same
volume to avoid the copy.

Bye,

Erik.

Re: apr_file_* weirdness on Mac OS X

2008-10-03T08:15:28Z

On Oct 3, 2008, at 6:22 AM, Bojan Smojver wrote:

> On Fri, 2008-10-03 at 01:13 -0700, Tim Bray wrote:
>
>> i.e. a randomized name in the same directory.
>
> Have you tried using apr_file_mktemp()?

Well, this isn't actually a temp file. Once it's written and closed,
I want to move it into its final location as quickly as possible, so I
thought it would be good to have it in the same directory where it's
going to end up and avoid doing a copy. But if this kind of thing is
going to happen, you probably have a point. -Tim

Re: apr_file_* weirdness on Mac OS X

2008-10-03T07:24:17Z

On 2008-10-03, at 02:40, Tim Bray wrote:

> I'm developing a module which accepts a large number of POST
> requests, receives the request bodies, and persists them into
> ordinary files in the filesystem. On OS X, there are occasions
> where the file is (rarely) transiently not there. The idiom looks
> like this
>
> Same code running in -X single-threaded mode, no problem. Same code
> on Solaris, no problem. (Well, yes, there are other weird Solaris
> problems with mutexes, but we'll get to those).

Sounds like a race. I'd suggest you replace this:

> status = apr_file_open(&fp, tempname, APR_FOPEN_WRITE |
> APR_FOPEN_CREATE,
> PERMS, pool);

with

apr_status_t status;
do {
... generate random filename ...
status = apr_file_open(..., APR_FOPEN_WRITE|APR_FOPEN_CREATE|
APR_FOPEN_EXCL, ...);
} while (APR_IS_EEXIST(status));

in order to hedge against another thread operating on the same
filename concurrently. apr_file_mktemp will handle this detail
transparently for you.

— Gordon

Re: apr_file_* weirdness on Mac OS X

2008-10-03T06:22:30Z

On Fri, 2008-10-03 at 01:13 -0700, Tim Bray wrote:

> i.e. a randomized name in the same directory.

Have you tried using apr_file_mktemp()?

--
Bojan

Re: apr_memcache 1.3.X sending unnecessary QUIT to memcached server

2008-10-03T03:48:17Z

On 10/03/2008 06:08 AM, peter baer wrote:

> Also, if you look at the apr_reslist_create() documentation, it states
> that the ttl "if non-zero, sets the maximum amount of time a resource
> may be available while exceeding the soft limit. ". Why then is the
> destructor being called for all resources that expire, even those
> below the "min"?

I guess the documentation is wrong. This behaviour was changed a while
ago to the behaviour you describe: If a resource is expired it will not
be handed out any longer but it will be closed. This is needed / useful
e.g. for database connections that become faulty after some time because
the database server closes them after some time of inactivity or a firewall
in between breaks the connection after some time. It is also very useful
when pooling persistent http connections and you know the keepalive
timeout settings of your backend.

Regards

Rüdiger

Re: apr_file_* weirdness on Mac OS X

2008-10-03T01:13:28Z

On Oct 2, 2008, at 11:58 PM, Bojan Smojver wrote:

> On Thu, 2008-10-02 at 23:40 -0700, Tim Bray wrote:
>
>> status = apr_file_open(&fp, tempname, APR_FOPEN_WRITE |
>> APR_FOPEN_CREATE, PERMS, pool);
>
> Where does the tempname come from?

static char * dir_of(apr_pool_t * pool, char * path) {
char * s;
s = apr_pstrdup(pool, path);
*(rindex(s, '/')) = 0;
return s;
}

/* make a temp filename for 'filename' */
static char * temp_filename(apr_pool_t * pool, char * filename) {
char * tempname = dir_of(pool, filename);
return apr_psprintf(pool, "%s/%s%ld-%ld", tempname,
TEMP_PREFIX, arandom(), arandom());
}

i.e. a randomized name in the same directory.
Here's an example: filename is /wf1/data/m-a/a/pub/e/entries/
collection.atom and tempname is /wf1/data/m-a/a/pub/e/entries/T.
493459176-1261197826

-Tim

Re: apr_file_* weirdness on Mac OS X

2008-10-02T23:58:28Z

On Thu, 2008-10-02 at 23:40 -0700, Tim Bray wrote:

> status = apr_file_open(&fp, tempname, APR_FOPEN_WRITE |
> APR_FOPEN_CREATE, PERMS, pool);

Where does the tempname come from?

--
Bojan

apr_file_* weirdness on Mac OS X

2008-10-02T23:40:28Z

I'm developing a module which accepts a large number of POST requests,
receives the request bodies, and persists them into ordinary files in
the filesystem. On OS X, there are occasions where the file is
(rarely) transiently not there. The idiom looks like this

status = apr_file_open(&fp, tempname, APR_FOPEN_WRITE |
APR_FOPEN_CREATE,
PERMS, pool);

/* ... do lots of writing ... */

apr_file_flush(fp);
apr_file_close(fp);

status = apr_file_rename(tempname, filename, pool); /* filename
is in the same directory as tempname */
BOOM! strerror() says "no such file or directory"

Then if I go and look, what do you know, the tempfile actually is
there. If I process 500 requests in a big hurry, 100 each from 5
concurrent clients, this will happen maybe half a dozen times, in an
unpredictable order. There are ways to work around this, but still,
it's kinda disturbing. It's either, in decreasing order of
probability (a) me doing something stupid, (b) OS X filesystem
weirdness, (c) an APR bug. apr_file_write_full() doesn't seem to make
a difference.

Same code running in -X single-threaded mode, no problem. Same code
on Solaris, no problem. (Well, yes, there are other weird Solaris
problems with mutexes, but we'll get to those).

-T

Re: random functions tutorial?

2008-10-02T21:50:57Z

On Oct 2, 2008, at 8:11 PM, Paul Querna wrote:

> Tim Bray wrote:
>> I stupidly used random() and srandom() in my module to generate
>> "random" filenames at high volume and, well, sigh. Anyhow, the
>> page at http://apr.apache.org/docs/apr/1.3/group__apr__random.html
>> lacks tutorial value. Anyone written up the *right* way to use
>> these? -T
>
> Ignore all of them except apr_generate_random_bytes.

Exactly what I needed to know. Thank you. -Tim

Re: apr_memcache 1.3.X sending unnecessary QUIT to memcached server

2008-10-02T21:34:20Z

On Thu, 2008-10-02 at 21:08 -0700, peter baer wrote:

> Also, if you look at the apr_reslist_create() documentation, it states
> that the ttl "if non-zero, sets the maximum amount of time a resource
> may be available while exceeding the soft limit. ". Why then is the
> destructor being called for all resources that expire, even those
> below the "min"?

>From memory, wasn't it being called on 32 of them, which were above min
(i.e. total was 64 if I recall correctly)?

--
Bojan

Re: apr_memcache 1.3.X sending unnecessary QUIT to memcached server

2008-10-02T21:08:50Z

Hi Bojan,

First, I'd like to say thank you for the quick response. The ttl is in
fact in microseconds. The documentation seems to be incorrect:
apr_memcache_server_create() ttl - time to live in seconds of a client
connection.

Also, if you look at the apr_reslist_create() documentation, it states
that the ttl "if non-zero, sets the maximum amount of time a resource
may be available while exceeding the soft limit. ". Why then is the
destructor being called for all resources that expire, even those
below the "min"?

Thanks,
Peter Baer

Re: random functions tutorial?

2008-10-02T20:11:59Z

Tim Bray wrote:
> I stupidly used random() and srandom() in my module to generate "random"
> filenames at high volume and, well, sigh. Anyhow, the page at
> http://apr.apache.org/docs/apr/1.3/group__apr__random.html lacks
> tutorial value. Anyone written up the *right* way to use these? -T

Ignore all of them except apr_generate_random_bytes.

For making temp files, also consider apr_file_mktemp, with or without
the APR_DELONCLOSE.

random functions tutorial?

2008-10-02T17:06:12Z

I stupidly used random() and srandom() in my module to generate
"random" filenames at high volume and, well, sigh. Anyhow, the page
at http://apr.apache.org/docs/apr/1.3/group__apr__random.html lacks
tutorial value. Anyone written up the *right* way to use these? -T

Re: apr pools & memory leaks

2008-10-02T07:25:34Z

Ben Collins-Sussman wrote:

> On Thu, Oct 2, 2008 at 2:44 AM, Mladen Turk <mturk@...> wrote:
>> Ben Collins-Sussman wrote:
>>> Our solution:
>>> Over at Google, we simply hacked APR to *never* hold on to blocks for
>>> recycling. Essentially, this makes apr_pool_destroy() always free()
>>> the block, and makes apr_pool_create() always call malloc() malloc.
>>> Poof, all the memory leak went away instantly.
>>>
>> Why not creating allocator for each of those subpools.
>> On pool_destroy it'll destroy allocator and call free()
>> consuming the global pool only for allocating subpools
>> which are constant in size, thus no fragmentation can
>> occur.
>
> The subversion libraries wrap all apr_pool_create and apr_pool_destroy
> calls in svn_pool_create and svn_pool_destroy functions. I suppose we
> could make every svn_pool_create call use a new allocator, but I think
> a better solution is within APR itself -- perhaps a simple
> compile-time option which triggers this behavior in apr_pool_create.
>

Within APR 1.3+ there is apr_pool_create_unmanaged that creates
allocator as well as part of the call.
However it needs to be explicitly destroyed, cause it doesn't
touch the global pool nor registers to any parent.
If you need that you can register a standard callback that will
destroy that pool explicitly on global or any parent destroy.

Regards
--
^(TM)

Re: apr pools & memory leaks

2008-10-02T06:47:01Z

On Thu, Oct 2, 2008 at 2:44 AM, Mladen Turk <mturk@...> wrote:

> Ben Collins-Sussman wrote:
>> Our solution:
>> Over at Google, we simply hacked APR to *never* hold on to blocks for
>> recycling. Essentially, this makes apr_pool_destroy() always free()
>> the block, and makes apr_pool_create() always call malloc() malloc.
>> Poof, all the memory leak went away instantly.
>>
>
> Why not creating allocator for each of those subpools.
> On pool_destroy it'll destroy allocator and call free()
> consuming the global pool only for allocating subpools
> which are constant in size, thus no fragmentation can
> occur.

The subversion libraries wrap all apr_pool_create and apr_pool_destroy
calls in svn_pool_create and svn_pool_destroy functions. I suppose we
could make every svn_pool_create call use a new allocator, but I think
a better solution is within APR itself -- perhaps a simple
compile-time option which triggers this behavior in apr_pool_create.

Re: apr pools & memory leaks

2008-10-02T00:44:33Z

Ben Collins-Sussman wrote:
> Our solution:
> Over at Google, we simply hacked APR to *never* hold on to blocks for
> recycling. Essentially, this makes apr_pool_destroy() always free()
> the block, and makes apr_pool_create() always call malloc() malloc.
> Poof, all the memory leak went away instantly.
>

Why not creating allocator for each of those subpools.
On pool_destroy it'll destroy allocator and call free()
consuming the global pool only for allocating subpools
which are constant in size, thus no fragmentation can
occur.

Regards
--
^(TM)

Re: apr pools & memory leaks

2008-10-02T00:22:04Z

On Wed, Oct 1, 2008 at 11:11 AM, Ben Collins-Sussman
<sussman@...> wrote:
> In the long term, I think we need to question the utility of having
> APR do memory recycling at all. Back in the early 90's, malloc() was
> insanely slow and worth avoiding. In 2008, now that we're running
> apache with nothing but malloc/free, we're unable measure any
> performance hit. The whole pool interface is really nice, but I
> wonder if pool recycling may just be unnecessary on modern hardware
> and OSes.

If you are using a specialized malloc implementation (like Google's
TCmalloc), then it will almost certainly be doing recycling underneath
for you in some fashion. These packages are largely optional, and I'm
not aware of any OS that has these functionalities enabled by
*default*. (Solaris and Mac OS X have them available, but need to be
turned on by environment variables or other linker tricks, IIRC.)
However, yes, there are more smarter malloc implementations than there
were 10 years ago...but I don't think it's prevalent enough where APR
should just assume that malloc()/free() is inherently cheap unless it
were to bundle one of those libraries directly. (Google's TCmalloc is
C++, but there are others that are likely reasonably portable too.)

BTW, implicit in the reason why there is not a noticeable performance
hit with malloc/free off for you is that you probably *are* using
TCmalloc or some special Google library that handles the memory
recycling already. =) -- justin

Re: apr pools & memory leaks

2008-10-01T11:53:05Z

Ben Collins-Sussman wrote:
> On Wed, Oct 1, 2008 at 1:31 PM, Mark Phippard <markphip@...> wrote:
>
>> 3) Any reason more Windows users would see this than Linux? Maybe
>> more Windows SVN users use Apache 2.2 than on Linux?
>
> As Erik said, on Windows only the threaded mode is available, thus
> explaining why they're seeing this problem more than anyone else.

Also, most distributions shipped prefork as the default mpm back in 2.0
and now ship worker as the default with 2.2. winnt mpm looks much more
like worker, of course.