Hi all. Our application generates lot of concurrent read requests to subversion using svn: protocol. When we tested the multithreaded mode of svnserve after upgrade to 1.9.3, we noticed strange 'deadlock-like' behavior: at some point all the requests are blocked in svnserve and wait there for a few minutes (3 to 15 minutes, no CPU activity), after which they continue to work. This is making our application significantly slower.
Operating system: Windows 10, CentOS 6.6, CentOS 7.2 The release and/or revision of Subversion: 1.9.3 The compiler and configuration options you built Subversion with: WANDisco binaries for CentOS, Apache Haus binaries for Windows The workaround on Linux is to run svnserve without -T switch, i.e. not using multithreaded mode. For Windows, there is no workaround as svnserve only supports the multi-threaded mode. Here is a sample of thread dump of svnserve.exe during the 'deadlock' obtained on Windows 10 using Process Explorer: ntoskrnl.exe!KeSynchronizeExecution+0x3de6 ntoskrnl.exe!KeWaitForMutexObject+0xc7a ntoskrnl.exe!KeWaitForMutexObject+0x709 ntoskrnl.exe!KeWaitForMutexObject+0x375 ntoskrnl.exe!IoThreadToProcess+0xff0 ntoskrnl.exe!KeRemoveQueueEx+0x16ba ntoskrnl.exe!KeWaitForMutexObject+0xe8e ntoskrnl.exe!KeWaitForMutexObject+0x709 ntoskrnl.exe!KeWaitForMutexObject+0x375 ntoskrnl.exe!NtWaitForSingleObject+0xf2 ntoskrnl.exe!setjmpex+0x3963 ntdll.dll!NtWaitForSingleObject+0x14 MSWSOCK.dll!Tcpip6_WSHSetSocketInformation+0x155 MSWSOCK.dll+0x1bf1 WS2_32.dll!WSAAccept+0xce WS2_32.dll!accept+0x12 libapr-1.dll!apr_socket_accept+0x46 svnserve.exe+0xc11c svnserve.exe+0xbae5 svnserve.exe+0xaf6c svnserve.exe+0x13ab KERNEL32.DLL!BaseThreadInitThunk+0x22 ntdll.dll!RtlUserThreadStart+0x34 The similar stack can be seen with other threads too. Radek
