[
https://issues.apache.org/jira/browse/SVN-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15241454#comment-15241454
]
Radek Krotil commented on SVN-4626:
-----------------------------------
On Windows 10, I run svnserve as a service using the following command:
"C:\Polarion\bundled\svn\bin\svnserve.exe" --service -R -r
C:\Polarion\data\svn\repo --listen-host 127.0.0.1 --log-file
C:\Polarion\data\logs\svnserve.log
Submitted the issue also to dev mailing list. We are quite sure this is an
issue in Subversion as we already spent significant effort on analysis.
> 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)
