It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,857
×11,987

question asked: Feb 27 '13, 5:17 a.m.
question was seen: 5,109 times
last updated: Mar 01 '13, 11:46 a.m.

Related questions

What is "round" when replicating components

0
James Hodgson (3●1●2) | asked Feb 27 '13, 5:17 a.m.
edited Feb 27 '13, 5:23 a.m.
We are attempting a few tests before our team moves to Jazz 4 to ensure our teams' processes will work. To do this we need a copy of some components to work with from a different repository. I followed the instructions found here:

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

0
permanent link
Andrew Niefer (713●5) | answered Feb 27 '13, 5:35 p.m.
JAZZ DEVELOPER
The Accepting Changeset progress will remain at the same level until all required data has been replicated between the servers.  The "round" is an indication of progress during replication between servers.  I don't believe we know up front how many rounds will be required.

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.
James Hodgson selected this answer as the correct answer
Comments
Nigel Lawrence commented Mar 01 '13, 10:02 a.m.
JAZZ DEVELOPER

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?

Andrew Niefer commented Mar 01 '13, 11:46 a.m.
JAZZ DEVELOPER

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

Most liked answers ↑|Newest answers|Oldest answers

1
permanent link
Tim Mok (6.6k●3●8) | answered Feb 27 '13, 11:54 a.m.
JAZZ DEVELOPER
It sounds like there might be a problem with replicating the change sets to the other server. This might be a bug. I believe the rounds are a rough form of progress. You can definitely resume the replication and it will continue replicating. The change sets that have been replicated won't be replicated again.
0
permanent link
James Hodgson (3●1●2) | answered Mar 01 '13, 5:12 a.m.
Thanks for the reply

Eventually it worked, finished up at about round 900, so it was just a case of taking a very long time. Didn't help that our repositories aren't the highest spec. Good to have an idea what round is for the future though.

Cheers

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.