subversion intermittently hangs (stalls) on commit

Question

Whenever any of our SVN users try to commit to the repository after the server has been idle for a while (e.g., first commit of the day), the Commit dialog hangs for precisely one minute, regardless of the size of the commit. When the commit finishes, the status message displays something like “5 kBytes transferred in 1 minute(s) and 0 second(s)”. Subsequent commits proceed without any delay. I read on another forum a suggestion that it might have to do with LDAP caching, but I don’t know how one might investigate that. Can you explain what might be causing this?

UPDATE: I am using SVN on a locally owned server, installed by SubversionEdge from CollabNet (v5.2.2), along with TortoiseSVN 1.10. The backend is ActiveDirectory (maintained on a separate corporate server). The LDAP is configured through SubversionEdge. I have access to the settings page, but they are all greek to me (I don't have any LDAP expertise).

UDPATE #2: I suspect this problem may be related to the one described by Gerald, here. However, that one was resolved by adjusting LDAPConnectionPoolTTL, but that setting is not available on the Authentications page for my SVN/LDAP settings, so I do not know how to adjust it.

Answer 1

Thanks to GeraldSchneider's detailed description of a similar issue I was able to identify that the problem had to do with an LDAP authentication setting known as LDAPConnectionPoolTTL. The challenge was to find out how to adjust that setting within the CollabNet administration portal. It is not on the Authentication page. Rather, you must navigate to "Server Settings", then click the "Advanced Settings" link, and at the bottom of that page there are these two fields:

Connection Pool TTL (default: -1 -- attempt to reuse connections indefinitely)

and,

Timeout (default: 60 seconds; this corresponds to the LDAP response time)

I am not exactly sure what the optimal settings for those fields are. I have found numerous suggestions on various forums:

• Gerald's post suggested setting the Pool TTL to 0, disabling the reuse of existing connections, but it is unclear to me what performance hit this might incur.
• One forum suggested 60 seconds on Pool TTL
• Two other forums suggested 900 on the Pool and 10 for the Timeout (along with some additional changes to the httpd.conf file).
• Atlassian recommends 30 seconds on the Pool TTL, and IBM recommends 10.

Personally, I have decided to experiment with a setting of 899 for the Pool TTL and reducing the LDAP response timeout to 10.