Troubleshooting timeout errors when committing to a VDFS slave repository

Applies to: VisualSVN Server 3.0 and later

This article provides a resolution for an error that may occur on a Subversion client during a large commit to VDFS slave repository.

Symptoms

The following error message is displayed on a Subversion client during a large commit to VDFS slave repository:

Сommitting transaction...
svn: E175012: Connection timed out

You may as well see additional errors:

svn: E200042: Additional errors:
svn: E175002: Unexpected server error 500 'Internal Server Error' on 'svn/MyRepo/!svn/txn/1-1'

The problem is also indicated by several errors on the server that hosts the VDFS slave repository. On that server, you may see the following errors in the VisualSVN Server log:

Cannot abort transaction '1-1', because it is still being processed. [500, #160032]
[client 192.168.1.2]
could not abort transaction. [500, #160032]
[client 192.168.1.2]
Could not DELETE /svn/MyRepo/!svn/txn/1-1. [500, #0]
[client 192.168.1.2]
Tip
You can find the VisualSVN Server log under the Applications and Services Logs node in the Windows Event Viewer. Read the KB28: Where VisualSVN Server logs are stored article for more information.

Cause

When committing to a slave repository, a new transaction is first created on that slave repository. After the Subversion client populates the created transaction with new contents, the VDFS service begins replicating data to a master repository. The Subversion client has to wait until the replication process is complete and until it receives a confirmation of successful commit both to the master and to the slave repository. If the confirmation is not received within the configured client-side HTTP timeout (600 seconds by default), the Subversion client will disconnect from the server and display the error.

Please note that the replication process still continues in the background, even after the Subversion client disconnects from the server. Upon the completion, the commit will appear on both the master and the slave repository.

Resolution

If large commits are common in your multisite environment, consider increasing the bandwidth of the network connection used for replication between master and slave servers.

Alternatively, you may increase the value of the http-timeout runtime configuration option or set it to zero to disable the timeout. Subversion clients use this value to determine the amount of time to wait for a server response. Use one of the two methods below to edit this option.

Note
The http-timeout is a client-side option. Thus, changes to this option should be applied to every client that experiences timeouts during large commits to VDFS slave repositories.

Edit the timeout using the servers configuration file

Follow the instructions below to edit the http-timeout runtime configuration option for the current user in the servers configuration file:

  1. Navigate to the Subversion runtime configuration area.
    • On Windows systems, navigate to a Subversion directory, inside the Application Data location (%APPDATA%\Subversion).
    • On Unix-like systems, navigate to a .subversion directory in the user’s home directory ($HOME/.subversion).
  2. Open the servers file.
  3. Edit the value of the http-timeout option under the [global] section of the file. Set it to a sufficient amount of time, in seconds, or use the value 0 to disable the timeout.

The Subversion clients will now use the configured HTTP timeout value.

Edit the timeout using Windows registry

Follow the instructions below to edit the http-timeout runtime configuration option for the current user via Windows registry:

  1. Start regedit.
  2. If not present already, create the following registry key:
  3. [HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Servers\global]
          
  4. Under that key, edit or create a string value named http-timeout. Set it to a sufficient amount of time, in seconds, or use the value 0 to disable the timeout.

The Subversion clients will now use the configured HTTP timeout value.

Tip
In an Active Directory environment use Windows Registry and Windows Group Policy to force configuration changes in a centralized and unattended fashion.
Last Modified: