Capturing is the automatic replication of changes made to a web application. As changes are made, they are captured and marked for replication.
It is important to note that ping backs and secondary events may occur during regular replication queuing and capturing. A ping back is when the same event type is sent back to the source. For instance, when an inbound list add event results in an outbound list add/update event for the same list.
It is expected behavior to see occasional ping backs in normal replication operation. These pings backs are not destructive as they are simply returning the same content back to the source.
The reason you may see occasional ping backs is because replicator is unable to determine if the event was caused by replicator applying an event, or caused by an end user. In this case we err on the side of caution and allow the event to ping back so we don't inadvertently stop a user generated event.
Secondary events are different event types being triggered by an inbound event. For instance, an inbound list add event could trigger outbound view update events, site navigation update events and webfile update events. We try to associate the secondary events to the inbound event and stop their replication, but if we can't associate the events to an inbound event we let it replicate as it may have been triggered by a valid user action.
The replication mode determines how servers in this group send and receive replication packages from each other.
Direct replication mode uses only one path between any two web applications in the Replication Network.
© ALL RIGHTS RESERVED. 이용 약관 개인정보 보호정책 Cookie Preference Center