RE: Deadlock-like behaviour of svnserve in multi-threaded mode (-T)

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:ivan_at_visualsvn.com]
Sent: Tuesday, May 31, 2016 4:39 PM
To: Radek Krotil
Cc: dev_at_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.krotil_at_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