Hi again, Ivan. Sorry, it took me while to get back to this issue, but it's still on. Today, I encountered it again even after update to most recent binaries available.
What do you mean by the network dump? I tried to collect all relevant information for my environment that is now uploaded to https://drive.google.com/drive/folders/0B-yalijSzAIUdVA3Rm5hQW1pLTg threaddump - Polarion 2.txt - thread dump from our Java app threaddumps - svnserve 2.txt - thread dumps from svnserve processes server logs.txt - particular snippets from Polarion and svnserve logs TPCview.txt - export of TCPview monitor I'm kindly asking for suggestions how can we help you to analyze this issue further. I checked with my developers and they told me that SVN connection timeout is set to 60 s, so if the thread is being stuck in this frozen mode for about 10 minutes it indicates that the connection was established, but server is not returning any data. Read timeout for svn connection is set to 3600 s, but the communication recovers prior reaching this timeout. Thank you, Radek Krotil -----Original Message----- From: Ivan Zhakov [mailto:i...@visualsvn.com] Sent: Tuesday, May 31, 2016 4:39 PM To: Radek Krotil Cc: dev@subversion.apache.org Subject: Re: Deadlock-like behaviour of svnserve in multi-threaded mode (-T) On 31 May 2016 at 17:19, Radek Krotil <radek.kro...@polarion.com> wrote: > Polarion is our application and it uses SvnKit (http://svnkit.com/) as > a connector to SVN. We use SVNKit version 1.8.12. > > Dump from our application also shows that the threads are waiting for > data from network. Could it be an issue in Windows itself? Anyway, we > have seen this behavior both in Windows and Linux environment and > never seen it with Subversion 1.8 and earlier, so we suspect it's a > regression in Subversion. > I suggest to check network dump prior deadlock. -- Ivan Zhakov
