[jira] [Created] (SVN-4626) Deadlock-like behaviour of svnserve in multithreaded mode (-T)

["Roman Kratochvil (JIRA)" <ji...@apache.org>]

Roman Kratochvil created SVN-4626:
-------------------------------------

             Summary: Deadlock-like behaviour of svnserve in multithreaded mode (-T)
                 Key: SVN-4626
                 URL: https://issues.apache.org/jira/browse/SVN-4626
             Project: Subversion
          Issue Type: Bug
          Components: svnserve
    Affects Versions: 1.9.3
         Environment: Windows 10, CentOS 6.6
            Reporter: Roman Kratochvil


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' behaviour: at some point all the requests are blocked in svnserve and wait there for a few minutes (3 to 5 minutes, no CPU activity), after which they continue to work. This is making our application significantly slower. We observed this behaviour on both Windows 10 and CentOS 6.6.
The workaround is to run svnserve without -T switch, i.e. not using multithreaded 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.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)