sporadic, hanging connections to apache svn (centos 5.4)

Hi,

I've done many subversion installs but never have I seen the following
problem before.

Vanilla Centos 5.4. Subversion 1.6.17 (compiled and packaged by me).
Nothing fancy with the compilation. I use an 'amalgamated' sqlite
3.6.23 when configuring...otherwise no other options to configure. Then
make; make install. The client being used is from the same 1.6.17
package. Apache with prefork MPM (centos 5.4 comes with apache 2.2.3).

The problem: Occasional and (so far) non-deterministic 'hangs'[1] of
subversion requests. It doesn't seem to matter if it's a commit or a
status or a log. Eventually, at some point, a request to the server
will hang. All requests are https.

If I perform an strace on the client and an strace on the Apache child
servicing the client they are both 'poll'ing. I don't see any errors or
warnings in the various apache logs.

During the time this one request 'hangs' other requests are serviced
just fine by the other apache children.

I have read that apr sometimes needs to be compiled to use /dev/urandom.
I am using the apr libs that come with Centos 5.4. This is apparently
apr 1.2.7. Can an apr that uses /dev/random cause the problem I am
describing? I can find no evidence that the apr that comes with Centos
5.4 is compiled to use /dev/urandom, but I'm likely missing something
obvious (I installed the apr-devel package and ran through the options
for apr-1-config, such as --cppflags, and none mentioned a switch for
compiling with /dev/urandom).

If someone has any other ideas for figuring out what is going on I'm all
ears and can do (most) any task. One thing I have not been able to do
is get it to consistently hang. I have to run a request in a loop and
eventually a request will hang. Sometimes it takes 10 minutes,
sometimes 1-2 hours...but eventually one of the requests will hang.

Thanks folks.

[1] it does not hang forever. it simply takes a very long time to
    respond. I've seen as long as 45 minutes for a very simple log request
    that just seconds earlier took about 1-2 seconds to return.

-- 
seth /\ sethdaniel.org