Hello, I am trying to fix a bug on Saros/I where the consistency watchdog claims wrongly that the client entered an inconsistent state after a file was moved or deleted.
It seems we only mark a checksum as dirty if the content of the corresponding file is modified. If the file is moved/deleted, but at the time the consistency server recalculates the checksums a client still has it opened in an editor, the server will broadcast the old checksum of the deleted file, which is inconsistent with the expected state of the clients. This is very likely to happen on Saros/I if the host rename a file for example. The dialog will prevent the checksum calculation to run as long as it is not closed. The checksum calculation will then be run immediately after the file has been renamed, and potentially before the client had the time to notify the host that there is no editor linked to the old path. I would like some help to understand how Saros/E manage to handle this case properly. More generally, is there a specific reason behind the consistency watchdog? I am wondering why we can't assume that everything is well until we fail to process an activity, and then trigger a recovery? Regards, Etienne ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ DPP-Devel mailing list DPP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel
