when v1.1.0 was patched to v1.1.1 to remove order from the watermark, there was a change introduced that was not related to the defect fix.
the recent change was to only read the watermark file on startup, and then maintain it's state in memory.
conversation with Sam Weeks, we learned that it is desirable to have a many:one relationship between signatory services and the watermark file. where many signatory instances all use the same watermark file, either located on a network drive, or a cloud database.
the in-memory watermark does not work for the scenario of many signatory services backed by the same watermark file. for this scenario to work, signatory must consult the watermark file on every request, not on startup only.
priority: lower than any changes for Oxford's Adaptive Issuance
when v1.1.0 was patched to v1.1.1 to remove order from the watermark, there was a change introduced that was not related to the defect fix.
the recent change was to only read the watermark file on startup, and then maintain it's state in memory.
conversation with Sam Weeks, we learned that it is desirable to have a many:one relationship between signatory services and the watermark file. where many signatory instances all use the same watermark file, either located on a network drive, or a cloud database.
the in-memory watermark does not work for the scenario of many signatory services backed by the same watermark file. for this scenario to work, signatory must consult the watermark file on every request, not on startup only.
priority: lower than any changes for Oxford's Adaptive Issuance