[
https://issues.apache.org/jira/browse/SVN-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15294849#comment-15294849
]
Radek Krotil commented on SVN-4626:
-----------------------------------
Sorry, took me a while to get back to this topic. Recently I ran into this
again and seen similar behavior at one of our enterprise customer environment,
so I kicked it up in priority of my task list.
I've captured all dumps for all threads of svnserve, also thread dump of our
application, and also the memory dump. All can be downloaded in a single zip
file at
https://drive.google.com/file/d/0B-yalijSzAIULWNuRGNGUW9KeWM/view?usp=sharing.
Same link will be sent to Ivan Zhakov.
> 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)
