View Revisions: Issue #1167
| Summary | 0001167: Enforce time sequence on print-in documents | ||
|---|---|---|---|
| Revision | 2021-02-15 14:24 by rijkr | ||
| Description | IST: 100% lastModified accuracy is crucial for the detection and handling of newly print-in converted PDF files in a user context. If a newly print-in PDF file has an older lastModified time then the previous printed-in PDF, it will not be detected as newly added PDF. Even worse, SavaPage will mistakingly identify an already printed-in PDF with the most recent lastModified as newly added (again). This inconsistency inevitably leads to misinterpretation and processing errors. When print-in files are offered right after each other or in one go, like Web Print with multiple file selection (?), print-in processing is continuous or might even be concurrent. In this case, there is a risk that even a minor inaccuracy (only a few milliseconds will do) of the implicitly assigned lastModified time of a print-in converted PDF will disrupt the assumption that the real-time sequence of PDF transfer to the user's SafePages inbox is in line with the lastModified time of each PDF involved. Also, from File.lastModified() javadoc: "While the unit of time of the return value is milliseconds, the granularity of the value depends on the underlying file system and may be larger. For example, some file systems use time stamps in units of seconds." So, different file systems have different lastModified precision: XFS and EXT3 (1 second), EXT4 (1 millisecond). SOLL-1: Enforce best-effort time sequencing by explicitly setting lastModified time with System.currentTimeMillis(). SOLL-2: Do not depend on lastModified time to detect newly added PDF files. Consider all inbox PDF files and handle all files that were not previously detected. |
||
| Revision | 2021-02-15 14:23 by rijkr | ||
| Description | IST: 100% lastModified accuracy is crucial for the detection and handling of newly print-in converted PDF files in a user context. If a newly print-in PDF file has an older lastModified time then the previous printed-in PDF, it will not be detected as newly added PDF. Even worse, SavaPage will mistakingly identify an already printed-in PDF with the most recent lastModified as newly added (again). This inconsistency inevitably leads to misinterpretation and processing errors. When print-in files are offered right after each other or in one go, like Web Print with multiple file selection (?), print-in processing is continuous or might even be concurrent. In this case, there is a risk that even a minor inaccuracy (only a few milliseconds will do) of the implicitly assigned lastModified time of a print-in converted PDF will disrupt the assumption that the real-time sequence of PDF transfer to the user's SafePages inbox is in line with the lastModified time of each PDF involved. Also, from File.lastModified() javadoc: "While the unit of time of the return value is milliseconds, the granularity of the value depends on the underlying file system and may be larger. For example, some file systems use time stamps in units of seconds." sO, different file systems have different lastModified precision: XFS and EXT3 (1 second), EXT4 (1 millisecond). SOLL-1: Enforce best-effort time sequencing by explicitly setting lastModified time with System.currentTimeMillis(). SOLL-2: Do not depend on lastModified time to detect newly added PDF files. Consider all inbox PDF files and handle all files that were not previously detected. |
||
| Revision | 2021-02-14 21:14 by rijkr | ||
| Description | IST: 100% lastModified accuracy is crucial for the detection and handling of newly print-in converted PDF files in a user context. If a newly print-in PDF file has an older lastModified time then the previous printed-in PDF, it will not be detected as newly added PDF. Even worse, SavaPage will mistakingly identify an already printed-in PDF with the most recent lastModified as newly added (again). This inconsistency inevitably leads to misinterpretation and processing errors. When print-in files are offered right after each other or in one go, like Web Print with multiple file selection (?), print-in processing is continuous or might even be concurrent. In this case, there is a risk that even a minor inaccuracy (only a few milliseconds will do) of the implicitly assigned lastModified time of a print-in converted PDF will disrupt the assumption that the real-time sequence of PDF transfer to the user's SafePages inbox is in line with the lastModified time of each PDF involved. SOLL: Enforce correct time sequencing and work around possible lastModified precision issues by explicitly setting lastModified time with System.currentTimeMillis() in a synchronized code block. Note that the synchronized scope is global and not per user. Since setting lastModified time is a minor action this will not cause any performance bottleneck. |
||
