Hello,
Pierangelo Masarati ando@sys-net.it writes:
Dieter Kluenter wrote:
"Dieter Kluenter" dieter@dkluenter.de writes:
Mavric Domen d.mavric@iskratel.si 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