What is "round" when replicating components
https://jazz.net/library/article/535/
Smaller components are no problem. However we also have a component with quite a large change set history. Numerous attempts to accept this component into a workspace have failed with various errors, including Out of memory, and some mysterious "Deferred operation failed" errors.
I am mainly interested in a way of telling that we are actually making progress with this. The progress window shows the following message:
Message from https://jazz001.hursley.ibm.com:9443/ccm: Requesting replication data for round 887 from https://jazza03.hursley.ibm.com:9443/ccm/
and stays at 22-23% - Accepting Change sets
Usually when the process fails, on a restart it will fly up to whichever round it failed on and continue. I assumed from this that "round" was an indicator of progress, and that progress was continued from where it failed. What exactly is round? Are these assumptions correct?
Another question would be whether we should expect this process to be as long as it has been. So far we have been attempting re-runs for 4-5 days.
Accepted answer
I'm a little fuzzy on the exact details, but the general idea is that server1 will ask server2 for a set of items (ie change sets or baselines it wants to accept) and server2 will send over those items. This is one round.
At the end of a round N, server1 may find that the items it received refer to other items that it does not have. (ex:, ChangeSets refer to Components and Changes, Changes have files/folders, files will have content, Components have a history of other ChangeSets, etc). Server1 will request those missing items from server2, and this will be round N+1.
I don't really have a feel for how much data would be involved in a single round, and whether or not 887 would be considered unusually high for a large component.
Comments
Are we saying that for sure that we have no way of knowing how much needs to be replicated up front (ie. this is architecturally impossible to construct)... or would it be a worthy enhancement request to provide better feedback to the user on the progress of replication given that can be very long running?
Certainly given that rounds seems to be a rather meaningless measure, I wonder why we bother to feed it back to the user at all?
We have no way of knowing up front what exactly needs to be replicated. The algorithm used here admittedly works better when the two servers involved are relatively in sync with each other.
Here we have the degenerate case where one server has nothing and everything needs to be sent. An enhancement would be to try and identify when the two servers are completely out of sync and find a better algorithm for this case.
Even though the rounds are somewhat meaningless, they do provide feedback to the user that work is being done. It would not be good to have the client side progress bar stuck at 23% with no additional feedback for a long time while the servers on the back end replicate data between themselves. If progress was stuck for more than a few minutes, the user might cancel/kill the operation thinking something was wrong.
2 other answers