Hello, Pierangelo Masarati <[EMAIL PROTECTED]> writes:
> Dieter Kluenter wrote: >> "Dieter Kluenter" <[EMAIL PROTECTED]> writes: >>> Mavric Domen <[EMAIL PROTECTED]> writes: >>> >>>> Hi, >>>> >>>> I'm facing a similar issue, but I've noticed that this only happens if >>>> one of the master "consumer" servers is restarted. Up to that time it >>>> seems the synchronization works perfectly. I had no chance to >>>> investigate this in details, but it might help to discover a reason >>>> for the problem. [...] >> initial contextCSN on localhost >> contextCSN: 20081022151212.263032Z#000000#000#000000 >> initial contextCSN on remote peer >> contextCSN: 20081022151212.263032Z#000000#000#000000 >> after a modification on localhost >> entryCSN: 20081022151026.029523Z#000000#000#000000 >> on remote peer >> contextCSN: 20081022151212.263032Z#000000#000#000000 >> I just wonder wether this is a new bug or is it silly me. > > AFAIK, the SID in each contextCSN should be anything but "000" (it > should be the serverID of the server that received the write and > propagated the modification). OK, than I presume that is a bug, unless I get other comments I will file an ITS. -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E
