Thank very much for your feedback!

Warren Young:

> Which is it?

With the random appearance of the delay, and the long duration of 60
seconds, I eventually gave up on "bisecting".

But with a more systematic approach, I've now got:

Last good: [06507038]
First bad: [947081aa]

> If the problem first appeared with [76800769] ...

Backing out [76800769] (and the dependent [d216ea9a]) does not fix the delay.

> Also, does this behavior happen on only one machine?

I can also see it on a Windows 7 (32-bit) VM.

Here's what I've found out in the meantime:

Waiting for 60 seconds for the delay to time out, until the default
/timeline web page is loaded in the browser, instead of terminating
the server with Ctrl+C, will cause another 60 seconds delay for any
links clicked in the web ui.

Reloading the delayed /timeline web page with F5, before the 60
seconds have elapsed, gives a speedy refresh, with no delay, so
multiple requests within the 60 seconds period are not delayed.

Waiting for 60 seconds before running `fossil ui' after the last
server was terminated, causes the delay to always happen.

The observed delay of 60 seconds seems somehow related to:

[5544931c] src/backoffice.c:59
#define BKOFCE_LEASE_TIME 60 /* Length of lease validity */

On Windows, the DbgView utility is useful to trace messages from
OutputDebugStringA(), handy if there's no attached console, and easier
than attaching WinDbg to spawned sub-processes:

By adding calls to OutputDebugStringA() before and after the following
line of source code, I found that one of the fossil.exe processes
seems to be stuck here during the delay:

[5544931c] src/backoffice.c:240
sqlite3_sleep(1000*(x.tmCurrent - tmNow + 1));

This code path is only entered if the delay becomes manifest.

I don't understand all the details of the backoffice processing code,
yet, in particular not the condition to trigger the sleep. But the
sleep seems to block the web ui, somehow?

fossil-users mailing list

Reply via email to