View Revisions: Issue #1026
| Summary | 0001026: Handle out-of-sync CUPS cache | ||
|---|---|---|---|
| Revision | 2019-01-23 20:39 by rijkr | ||
| Description | IST: When CUPS cache is cleared (rm -f /var/cache/cups/*), or SavaPage is moved to another server, the CUPS cache will most likely be out-of-sync with the CUPS job id's persisted in the SavaPage database. Note: By clearing the CUPS cache, the CUPS job id offset is reset to zero (0). So, the next job id's issued are 1, 2, 3, 4, etc. An out-of-sync CUPS cache may result in newly issued CUPS job id's that are already present in the SavaPage PrintOut Log, resulting in same job id's being present multiple times in the Log. This situation is not foreseen by SavaPage: it assumes that job id's are unique. So, when SavaPage tries to read a unique PrintOut Log belonging to a job id, it fails, as shown by javax.persistence.NonUniqueResultException instances in the /opt/savapage/server/logs/service.log file. The exception breaks the job status monitoring process, which explains why CUPS job status notifications are not handled anymore, and print jobs keep showing "Processing" status in SavaPage, while CUPS shows them as "completed". SOLL-1: When retrieving the PrintOut belonging to a CUPS job id, force a unique result by getting the most recent one that has NOT reached end-state status. Note: status UNKNOWN is considered end-state. SOLL-2: When a CUPS job id from a pending/processing PrintOut can't be retrieved from CUPS (via IPP), then set PrintOut print status to UNKNOWN and set timeCompleted to current time. |
||
| Revision | 2019-01-25 21:08 by rijkr | ||
| Description | IST: When CUPS cache is cleared (rm -f /var/cache/cups/*), or SavaPage is moved to another server, the CUPS cache will most likely be out-of-sync with the CUPS job id's persisted in the SavaPage database. Note: By clearing the CUPS cache, the CUPS job id offset is reset to zero (0). So, the next job id's issued are 1, 2, 3, 4, etc. An out-of-sync CUPS cache may result in newly issued CUPS job id's that are already present in the SavaPage PrintOut Log, resulting in same job id's being present multiple times in the Log. This situation is not foreseen by SavaPage: it assumes that job id's are unique. So, when SavaPage tries to read a unique PrintOut Log belonging to a job id, it fails, as shown by javax.persistence.NonUniqueResultException instances in the /opt/savapage/server/logs/service.log file. The exception breaks the job status monitoring process, which explains why CUPS job status notifications are not handled anymore, and print jobs keep showing "Processing" status in SavaPage, while CUPS shows them as "completed". SOLL-1: When retrieving the PrintOut belonging to a CUPS job id, force a unique result by getting the most recent one that has NOT reached end-state status. Note: status UNKNOWN is considered end-state. SOLL-2: When a CUPS job id from a pending/processing PrintOut can't be retrieved from CUPS (via IPP), then set PrintOut print status to UNKNOWN and set timeCompleted to current time. SOLL-3: Add configuration item "system.startup.cups.sync-print-jobs.enable" = Y (default) | N, to enable/disable CUPS job status synchronization at startup. |
||
