On 5/16/17, Martin Vahi <martin.v...@softf1.com> wrote: > > > I'm not totally sure, what the issue in my case is, but > I suspect that the issue might be that the hosting provider > has some time-to-live limit for every operating > system process that is started for serving a request and > if the Fossil takes "too long" to process the request, > then it gets killed by the hosting provider's watchdog > before the Fossil process completes the commit operation. > > Are there any "heart-beat" options available, where > a cron job might call something like > > fossil --heartbeat --max-duration=10s > > and during that "maximum duration" time period a small > chunk of the work gets done?
What operation is it trying to do that takes more than 10 seconds? Usually Fossil runs for more like 10 milliseconds. Building big ZIP archives or tarballs takes long. (FWIW, I have profiled those operations, and Fossil is spending most of its time inside of zlib, doing the requirement compression.) Big "annotates" can also take some time if you have a long history. Do you know what operations are timing out? Most operations are read-only. So breaking them up into separate transactions won't really help anything. Write operations (receiving a push) are usually very quick. -- 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
