Re: [fossil-users] Delay with `fossil ui' (related to backoffice processing?)
On 7/22/18, Florian Balmer wrote: > > Just a thought: would it make sense to have --nodelay as a global > option recognized by all commands, and maybe also through an > environment variable, and a CGI control option? So that any backoffice > processing could be temporarily disabled? Everything is in flux right now. Let's iron out these details once I get everything actually working. There is a lot more to be done before we reach that point. -- 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] Delay with `fossil ui' (related to backoffice processing?)
Richard Hipp: > Please test the latest trunk version and let me know if you are still > seeing issues. Thank you very much for the fix! I see no more delays with "fossil ui" on Windows. Just a thought: would it make sense to have --nodelay as a global option recognized by all commands, and maybe also through an environment variable, and a CGI control option? So that any backoffice processing could be temporarily disabled? This would probably require an explicit "backoffice" command, which could then also be set up to run as a task or cron job every few hours. This may be handy for fatal incidents that require "repository surgery", or restoring from backups, where you don't want any notifications to be sent before things are fixed. But maybe this is overengineering. --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] Delay with `fossil ui' (related to backoffice processing?)
On 7/21/18, Florian Balmer wrote: > > I see random delays for the `fossil ui' command, Please test the latest trunk version and let me know if you are still seeing issues. Anybody who has the capability, please also verify that "fossil server --scgi" is now working again. I do not have a SCGI webserver set up on windows with which to test that command so I implemented the fixes there without actually checking them. -- 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] Delay with `fossil ui' (related to backoffice processing?)
Richard Hipp: > Hence, if the subprocess gets involves in backoffice work, that can > delay the return of content to the user. > The only comes up on Windows. I do not yet have a good work-around. I see, thank you very much for the detailed explanations. I only have the obvious (inefficient?) ideas, like using a command-line switch to direct the "HTTP renderer" to offload backoffice processing to another separate process, and exit immediately once the HTTP response is ready. Looking forward to see what will be your solution. I can always learn a lot of interesting things from the Fossil source code. --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] Delay with `fossil ui' (related to backoffice processing?)
On 7/22/18, Florian Balmer wrote: > > The Windows HTTP server (and thus `fossil ui') works by spawning > sub-processes for each individual HTTP request, right? This results in > multiple sub-processes per web page (one for the HTML page, one for > CSS, another one for JavaScript, etc.)? > Every Fossil webpage is generated by a separate subprocess. This is true for Windows, Mac, Linux, BSD, whatever. And it is true regardless of how Fossil is launched. The backoffice is a facility to do background processing - things like sending email notifications, syncing with peers, maybe doing aggressive compaction of the repository - anything that is not directly interacting with the user. Backoffice runs after a webpage is generated, in the same subprocess. Once the entire webpage has been generated, Fossil closes the socket or file into which the webpage is being written, and then attempts to do backoffice processing. There can only be one backoffice process at a time, and another backoffice that is "on deck" - ready to run when the current one finishes. In most systems, the webserver returns results back to the user as soon as the output socket closes. So the user does not realize that the process that generated the webpage continues running for up to 60 seconds of backoffice work. But on Windows for "fossil ui" and "fossil server", the webpage is not returned to the user until the subprocess actually terminates. Hence, if the subprocess gets involves in backoffice work, that can delay the return of content to the user. The only comes up on Windows. I do not yet have a good work-around. -- 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] Delay with `fossil ui' (related to backoffice processing?)
> ... writing to a FILE* pointing to NULL may have exactly the same > effect as writing to a FILE* pointing to "/dev/null"? Well, unless there's a directory named "dev" in the root of the current drive, which would result in creation (due to the passed "wb" mode) of a file named "null", on Windows. --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] Delay with `fossil ui' (related to backoffice processing?)
On Jul 22, 2018, at 1:18 AM, Florian Balmer wrote: > > [5544931c] src/backoffice.c:240 That’s brand new code, less than a week old. It’s not surprising it’s not rock-solid yet. I expect drh is now on the case. :) ___ 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] Delay with `fossil ui' (related to backoffice processing?)
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: https://live.sysinternals.com/Dbgview.exe 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? --Florian ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users