On 2/1/11 11:53 AM, Blair Zajac wrote:
On 1/26/11 5:24 PM, Blair Zajac wrote:
On 01/26/2011 11:39 AM, Blair Zajac wrote:
On 01/26/2011 11:15 AM, Philip Martin wrote:
Blair Zajac writes:
I'm now thinking of putting the retry in svn_io_file_lock2() instead
of handling a deadlock in libsvn_fs_f
On 1/26/11 5:24 PM, Blair Zajac wrote:
On 01/26/2011 11:39 AM, Blair Zajac wrote:
On 01/26/2011 11:15 AM, Philip Martin wrote:
Blair Zajac writes:
I'm now thinking of putting the retry in svn_io_file_lock2() instead
of handling a deadlock in libsvn_fs_fs itself. It shouldn't hurt any
other us
Blair Zajac writes:
> On 1/27/11 1:35 AM, Philip Martin wrote:
>> Philip Martin writes:
>>
>>> It appears that the kernel deadlock detection sometimes produces false
>>> positives
>>
>> I believe I was mistaken when I assumed that fcntl() would block just
>> the thread making the call; rereading
On 1/27/11 1:35 AM, Philip Martin wrote:
Philip Martin writes:
It appears that the kernel deadlock detection sometimes produces false
positives
I believe I was mistaken when I assumed that fcntl() would block just
the thread making the call; rereading the man page I think it is the
whole pro
Philip Martin writes:
> It appears that the kernel deadlock detection sometimes produces false
> positives
I believe I was mistaken when I assumed that fcntl() would block just
the thread making the call; rereading the man page I think it is the
whole process that blocks. That means this is not
On 01/26/2011 11:39 AM, Blair Zajac wrote:
On 01/26/2011 11:15 AM, Philip Martin wrote:
Blair Zajac writes:
I'm now thinking of putting the retry in svn_io_file_lock2() instead
of handling a deadlock in libsvn_fs_fs itself. It shouldn't hurt any
other use cases and be a general, defensive code
On 01/26/2011 11:15 AM, Philip Martin wrote:
Blair Zajac writes:
I'm now thinking of putting the retry in svn_io_file_lock2() instead
of handling a deadlock in libsvn_fs_fs itself. It shouldn't hurt any
other use cases and be a general, defensive code.
Should retry be conditional on a threa
Blair Zajac writes:
> I'm now thinking of putting the retry in svn_io_file_lock2() instead
> of handling a deadlock in libsvn_fs_fs itself. It shouldn't hurt any
> other use cases and be a general, defensive code.
Should retry be conditional on a threaded build? Can this problem even
occur in
Blair Zajac writes:
>> --- subversion/libsvn_fs_fs/fs_fs.c (revision 1063629)
>> +++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
>> @@ -583,6 +583,14 @@
>> err = body(baton, subpool);
>> }
>>
>> + if (!strcmp(lock_filename, path_txn_current_lock(fs, pool)))
>> +{
>> +
On 01/26/2011 02:56 AM, Stefan Sperling wrote:
On Tue, Jan 25, 2011 at 11:00:31PM -0800, Blair Zajac wrote:
We're seeing deadlocks in our Subversion multithreaded server when
two distinct processes try to fcntl(F_SETLKW) on two fsfs
repositories' db/txn-current-lock, when the processes begin
tra
On 01/26/2011 05:21 AM, Philip Martin wrote:
Philip Martin writes:
Philip Martin writes:
Create two repositories with a pre-commit hook that sleeps for 20
seconds. Start two threaded svnserve processes listening on different
ports.
svnserve -Tdr.
svnserve -Tdr. --listen-port 3691
Commit:
Philip Martin writes:
>>> svn mkdir -mm svn://localhost/repoA/X1
>>> svn mkdir -mm svn://localhost:3691/repoB/X1
>>> svn mkdir -mm svn://localhost/repoB/X2
>>> svn mkdir -mm svn://localhost:3691/repoA/X2
> I start the four commits above, one after the other with a small delay
> between them. Th
Philip Martin writes:
> Philip Martin writes:
>
>> Create two repositories with a pre-commit hook that sleeps for 20
>> seconds. Start two threaded svnserve processes listening on different
>> ports.
>>
>> svnserve -Tdr.
>> svnserve -Tdr. --listen-port 3691
>>
>> Commit:
>>
>> svn mkdir -mm svn
Philip Martin writes:
> Create two repositories with a pre-commit hook that sleeps for 20
> seconds. Start two threaded svnserve processes listening on different
> ports.
>
> svnserve -Tdr.
> svnserve -Tdr. --listen-port 3691
>
> Commit:
>
> svn mkdir -mm svn://localhost/repoA/X1
> svn mkdir -mm
On Tue, Jan 25, 2011 at 11:00:31PM -0800, Blair Zajac wrote:
> We're seeing deadlocks in our Subversion multithreaded server when
> two distinct processes try to fcntl(F_SETLKW) on two fsfs
> repositories' db/txn-current-lock, when the processes begin
> transactions in reverse order.
>
> Process 1
Blair Zajac writes:
> We're seeing deadlocks in our Subversion multithreaded server when two
> distinct processes try to fcntl(F_SETLKW) on two fsfs repositories'
> db/txn-current-lock, when the processes begin transactions in reverse
> order.
>
> Process 1 Process 2
>
We're seeing deadlocks in our Subversion multithreaded server when two distinct
processes try to fcntl(F_SETLKW) on two fsfs repositories' db/txn-current-lock,
when the processes begin transactions in reverse order.
Process 1 Process 2
-
17 matches
Mail list logo
