subversion-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Zhakov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SVN-4626) Deadlock-like behaviour of svnserve in multithreaded mode (-T)
Date Tue, 12 Apr 2016 16:01:25 GMT

    [ https://issues.apache.org/jira/browse/SVN-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237440#comment-15237440
] 

Ivan Zhakov commented on SVN-4626:
----------------------------------

What exact command line do you use to run svnserve?

Also please note that Subversion project uses buddy policy for issue tracker. Please report
your problem to users {at} subversion.apache.org first:
http://subversion.apache.org/reporting-issues.html

> 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)

Mime
View raw message