Re: [fossil-users] It would be nice if sync collisions failed more gracefully

[Matt Welland]

On Wed, Dec 7, 2011 at 10:38 PM, Nolan Darilek wrote:

>  Maybe Fossil could recommend a WAL rebuild command in these instances?
> Then at least the user has some direction in which to go. At the very least
> it could output that for relaying to the server administrator.
>

I wasn't clear in my message, these are being served directly by file
access, not http and via NFS from multiple hosts. I don't think wal is a
safe option.


> On 12/07/2011 07:48 PM, Richard Hipp wrote:
>
>
>
> On Wed, Dec 7, 2011 at 7:15 PM, Matt Welland  wrote:
>
>> This is on NFS and with a large check in so it is worst case scenario but
>> still I'm seeing this error when people simultaneously do certain heavy
>> weight actions.
>>
>>
>>  Are there any settings that would help here? I've dug though the docs
>> and not seen anything yet. I'll dig though the code tonight but pointers
>> from the experts would be appreciated.
>>
>
> Setting WAL mode on the database will help a lot.  However, WAL might not
> work on NFS.  Are all server instances running on the same machine?  If so,
> then you might be able to get WAL to work.  I suppose you could try.
>
> Do this:
>
>fossil rebuild -wal -pagesize 8192 REPO
>
> Then see if that helps.
>
> FWIW, the Fossil and SQLite repositories take a pretty heavy load without
> problems and they are both running on the same 1/24th slice VM.  They do
> both use WAL.  But they also both use a local disk, not NFS.
>
>

>
>>
>>  FYI, I think these are probably unnecessary failures, however I grant
>> that is may be tough to differentiate from real issues such as db not
>> readable. I think fossil could possibly do a couple things here:
>>
>>
>>  1. Interleave sync actions
>>
>> 2. On failure in sync tell the user that the db is probably busy and try
>> again in a few minutes.
>>
>>
>>  [830] > fossil update
>>
>> Autosync:  file:///blah/blah.fossil
>>
>> Bytes  Cards  Artifacts Deltas
>>
>> Sent:6945146  0  0
>>
>> Error: Database error: database is locked
>>
>> DELETE FROM unclustered WHERE rid IN (SELECT rid FROM private)
>>
>> Received: 118  1  0  0
>>
>> Total network traffic: 3842 bytes sent, 871 bytes received
>>
>> fossil: Autosync failed
>>
>> --
>>
>> updated-to:   9012cff7d15010018d2fdd73375d198b27116844 2011-10-18
>> 22:33:49 UTC
>>
>> tags: trunk
>>
>> comment:  initial empty check-in (user: blah)
>>
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>>
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
>
> ___
> fossil-users mailing 
> listfossil-users@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] It would be nice if sync collisions failed more gracefully

[Nolan Darilek]

Maybe Fossil could recommend a WAL rebuild command in these instances? 
Then at least the user has some direction in which to go. At the very 
least it could output that for relaying to the server administrator.



On 12/07/2011 07:48 PM, Richard Hipp wrote:



On Wed, Dec 7, 2011 at 7:15 PM, Matt Welland > wrote:


This is on NFS and with a large check in so it is worst case
scenario but still I'm seeing this error when people
simultaneously do certain heavy weight actions.


Are there any settings that would help here? I've dug though the
docs and not seen anything yet. I'll dig though the code tonight
but pointers from the experts would be appreciated.


Setting WAL mode on the database will help a lot.  However, WAL might 
not work on NFS.  Are all server instances running on the same 
machine?  If so, then you might be able to get WAL to work.  I suppose 
you could try.


Do this:

   fossil rebuild -wal -pagesize 8192 REPO

Then see if that helps.

FWIW, the Fossil and SQLite repositories take a pretty heavy load 
without problems and they are both running on the same 1/24th slice 
VM.  They do both use WAL.  But they also both use a local disk, not NFS.



FYI, I think these are probably unnecessary failures, however I
grant that is may be tough to differentiate from real issues such
as db not readable. I think fossil could possibly do a couple
things here:


1. Interleave sync actions

2. On failure in sync tell the user that the db is probably busy
and try again in a few minutes.


[830] > fossil update

Autosync: file:///blah/blah.fossil

Bytes  Cards  Artifacts Deltas

Sent:6945146  0  0

Error: Database error: database is locked

DELETE FROM unclustered WHERE rid IN (SELECT rid FROM private)

Received: 118  1  0  0

Total network traffic: 3842 bytes sent, 871 bytes received

fossil: Autosync failed

--

updated-to:   9012cff7d15010018d2fdd73375d198b27116844 2011-10-18
22:33:49 UTC

tags: trunk

comment:  initial empty check-in (user: blah)


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org

http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




--
D. Richard Hipp
d...@sqlite.org 


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] It would be nice if sync collisions failed more gracefully

[Richard Hipp]

On Wed, Dec 7, 2011 at 7:15 PM, Matt Welland  wrote:

> This is on NFS and with a large check in so it is worst case scenario but
> still I'm seeing this error when people simultaneously do certain heavy
> weight actions.
>
>
> Are there any settings that would help here? I've dug though the docs and
> not seen anything yet. I'll dig though the code tonight but pointers from
> the experts would be appreciated.
>

Setting WAL mode on the database will help a lot.  However, WAL might not
work on NFS.  Are all server instances running on the same machine?  If so,
then you might be able to get WAL to work.  I suppose you could try.

Do this:

   fossil rebuild -wal -pagesize 8192 REPO

Then see if that helps.

FWIW, the Fossil and SQLite repositories take a pretty heavy load without
problems and they are both running on the same 1/24th slice VM.  They do
both use WAL.  But they also both use a local disk, not NFS.



>
> FYI, I think these are probably unnecessary failures, however I grant that
> is may be tough to differentiate from real issues such as db not readable.
> I think fossil could possibly do a couple things here:
>
>
> 1. Interleave sync actions
>
> 2. On failure in sync tell the user that the db is probably busy and try
> again in a few minutes.
>
>
> [830] > fossil update
>
> Autosync:  file:///blah/blah.fossil
>
> Bytes  Cards  Artifacts Deltas
>
> Sent:6945146  0  0
>
> Error: Database error: database is locked
>
> DELETE FROM unclustered WHERE rid IN (SELECT rid FROM private)
>
> Received: 118  1  0  0
>
> Total network traffic: 3842 bytes sent, 871 bytes received
>
> fossil: Autosync failed
>
> --
>
> updated-to:   9012cff7d15010018d2fdd73375d198b27116844 2011-10-18 22:33:49
> UTC
>
> tags: trunk
>
> comment:  initial empty check-in (user: blah)
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] It would be nice if sync collisions failed more gracefully

[Matt Welland]

This is on NFS and with a large check in so it is worst case scenario but
still I'm seeing this error when people simultaneously do certain heavy
weight actions.


Are there any settings that would help here? I've dug though the docs and
not seen anything yet. I'll dig though the code tonight but pointers from
the experts would be appreciated.


FYI, I think these are probably unnecessary failures, however I grant that
is may be tough to differentiate from real issues such as db not readable.
I think fossil could possibly do a couple things here:


1. Interleave sync actions

2. On failure in sync tell the user that the db is probably busy and try
again in a few minutes.


[830] > fossil update

Autosync:  file:///blah/blah.fossil

Bytes  Cards  Artifacts Deltas

Sent:6945146  0  0

Error: Database error: database is locked

DELETE FROM unclustered WHERE rid IN (SELECT rid FROM private)

Received: 118  1  0  0

Total network traffic: 3842 bytes sent, 871 bytes received

fossil: Autosync failed

--

updated-to:   9012cff7d15010018d2fdd73375d198b27116844 2011-10-18 22:33:49
UTC

tags: trunk

comment:  initial empty check-in (user: blah)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users