Just found a fun interaction between these two fixes:

• #1549 (Project usage is not saved across qmaster restarts)
• #1551 (Spool not flushed at qmaster exit)

Project usage *does* sometimes make it into the project spool object ready for a qmaster restart - when the spool is flushed at qmaster exit for one.

This means that these fixes together mean the project usage is doubled across an ordinary qmaster restart, instead of zeroed.

We could:

1 Revert #1549 (but then project usage will be lost if the qmaster crashes). 2 Revert #1549 and periodically flush project objects to disk, like it does for user objects. 3 Not to flush project usage at qmaster exit (but there might be other ways it ends up in there, e.g. modification of project definition). 4 Stop storing usage in the project spool objects completely.

Sorry for this pain.

Hi,

A restart of the qmaster throws away sharetree project usage. This is because project usage is stored in the spool by user objects and not project objects.

The attached patch initialises project usage by walking through the user objects.

It's only been tested against 8.1.5, but this patch has been prepared against 8.1.8 (and checked that it compiles ok).

Cheers,

Mark

Fix attached. From the commit:

Fix xxx spool project sharetree usage while qmaster running

The qmaster only writes out sharetree usage data periodically. Some tidying in a commit designated RD-2008-02-26-0 introduced faulty logic, meaning that usage was not spooled to projects in some situations.

• If there were jobs running, usage would be spooled to user objects but not to project objects.
• If no jobs were running, usage would be spoooled to project objects.

This commit reverts to the original logic.

Commit prepared against 8.1.9

Note that usage stored in the spool can still end up considerably out of date due to #1554.