Re: [fossil-users] Delay with `fossil ui' (related to backoffice processing?)

2018-07-21 Thread Warren Young
On Jul 21, 2018, at 11:48 AM, Florian Balmer  wrote:
> 
> I've noticed something with the current tip version of Fossil…

> I tried to find a "last good" version by means of "bisecting", but…the delay 
> never appears with Fossil 2.6.

I can see only two ways for those two sentences to be true at once, but it’s 
unclear which is the case from the way you phrased it:

1. The tip of trunk and *only* the tip of trunk exhibits the problem behavior.

2. Every checkin after 2.6 exhibits it.

Which is it?

If the problem first appeared with [76800769], the fix drh checked in to clean 
up the dangling journal files you were reporting, then I wonder if the delay is 
waiting out some SQLite lock.

Windows’ native locking behavior is much more restrictive than the default on 
pretty much every other platform, so I wonder if the new shutdown code path 
created a temporary deadlock that gets broken by a SQLite timeout.

Try backing that checkin out to see if the prior problem (dangling journal 
files) reappears, while the delay also goes away:

fossil up trunk # back out from the bisect
fossil revert   # just to be sure
fossil merge --backout 76800769

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


[fossil-users] Delay with `fossil ui' (related to backoffice processing?)

2018-07-21 Thread Florian Balmer
I've noticed something with the current tip version of Fossil (on Windows):

I see random delays for the `fossil ui' command, i.e. the web browser
is opened at once, but is displaying the loading/busy indicator and a
blank page for some time, before the default web page finally appears:

http://localhost:8080/timeline?c=current

When repeatedly entering `fossil ui' from the command prompt, followed
by immediately closing the web browser as soon as the /timeline web
page is displayed, then hitting Ctrl+C to stop the Fossil web server,
and restarting the cycle by running `fossil ui' again, the delay seems
to appear with every 5th to 10th cycle.

During the delay, I can see two fossil.exe processes with `tasklist |
findstr fossil', whereas with `fossil ui' without the delay, there's
only one fossil.exe process.

The %TEMP% directory has 3 or more files appearing instantaneously at
the beginning of the delay, named fossil_server_P8080_0N_xxx.txt,
with N being low numbers, and xxx being 'in', 'out', and 'cmd',
containing the HTTP request and response, and a file/IP address list.

When terminating the delayed `fossil ui' server (responds to Ctrl+C)
and immediately relaunching it, it is as fast as usual, without any
delay. The delay takes approximately 60 seconds, and after that the
HTTP request completes normally with the display of the /timeline web
page, and the temporary files are cleared.

I tried to find a "last good" version by means of "bisecting", but
unfortunately no success, so far. All I can say is that the delay
never appears with Fossil version 2.6 [9718f3b078] 2018-05-04 12:56:42
UTC, the binary for Windows downloaded from the Fossil web site.

My tests were on Windows 10.0.17134.167 (64-bit), with MSVC
19.14.26430 (32-bit).

--Florian
___
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] Backup traffic

2018-07-21 Thread Florian Balmer
Richard Hipp:

> I think this problem has been addressed in a more general way
> on the latest trunk. Please let me know if you find otherwise.

This works fine (tested only on Windows, so far), thank you very much!

--Florian
___
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] Backup traffic

2018-07-21 Thread Richard Hipp
On 7/21/18, Florian Balmer  wrote:
>
> The current tip version of Fossil still
> exhibits the behavior summarized here:
>
> https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg27269.html
>

I think this problem has been addressed in a more general way on the
latest trunk.  Please let me know if you find otherwise.
-- 
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


Re: [fossil-users] Backup traffic

2018-07-21 Thread Florian Balmer
> There's been some changes to fossil_exit() in the meantime, I'll check
> these, and report back here.

I was wrong, the changes were to fossil_fatal() and fossil_panic(),
and not to fossil_exit(). The current tip version of Fossil still
exhibits the behavior summarized here:

https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg27269.html

--Florian
___
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] Backup traffic

2018-07-21 Thread Florian Balmer
Warren Young:

> Quantify “a lot.”

I have some rarely committed-to but frequently web-accessed
repositories (with login), and I see daily backups of the modified
repository database, even though I'm sure I haven't committed
anything. It's like "hey, what's going on there with my babies?"
everytime, but I need to get used to it.

> I’d find out why the DB client is dying early and fix that, so that
> the WAL ends up being deleted entirely upon a clean DB shutdown.

I think I found it:

https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg27269.html

There's a call to fossil_exit() from within a
db_step()...db_finalize() block, and calling fossil_exit() only after
db_finalize() fixed it.

There's been some changes to fossil_exit() in the meantime, I'll check
these, and report back here.

> I find it odd that some people get so itchy over DB concurrency and
> such with Fossil when highly active projects might have 40 or so
> commits per day.

I'm not worried by this. Stephan just wondered if a shared cookie
database may be prone to locks contention, if I got him right.

I'd assume the main bottleneck to be high-frequency, read-only,
no-login web access (for a renowned project), in which case the cookie
database doesn't even need to be attached, and not the frequency of
commits.

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