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

["Jakub Stroleny (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SVN-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jakub Stroleny updated SVN-4626:
--------------------------------
    Attachment: repo-client-1.0-SNAPSHOT-sources.jar

> 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
>            Priority: Major
>         Attachments: repo-client-1.0-SNAPSHOT-sources.jar, repo-client-1.0-SNAPSHOT.zip
>
>
> 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
(v7.6.3#76005)