It's all about the answers!

Ask a question

new Jenkins team concert plugin performance issue: very long fetching files time


Jun He (334) | asked Nov 18 '13, 12:27 a.m.
 I'm evaluating new Jenkins Team Concert Plugin as it has better RTC integration. But I found the performance is terrible. As an example, it took 42m37s to fetching files in one of build (see screen shot below) even there is no changes. The old Jenkins plugin takes less than 1 min in updating sandbox! 

One possible explanation is the new plugin using replace component to update build workspace,  from the FAQ (https://jazz.net/wiki/bin/view/Main/BuildFAQ#How_should_my_source_code_be_loa), it says 
When JBE updates the build workspace, it does so using a multi-component replace, not a regular accept, so discarded changes are properly removed, and there can be no conflicts. It also creates a snapshot after this to capture the state that will be built (except for personal builds). You can think of JBE as another developer that just brings his workspace up to date with what's in the stream (using replace, not accept). This provides the necessary isolation of the build from ongoing changes in the stream (the replace is done atomically).

Can anybody explain what is the difference between replace and accept? My understanding is that if a dedicated work space is used for continuous build and no changes will be made directly in that work space, there should be no much difference between accept and replace? Why the huge performance difference? Can anyone explain why it works in this way? and how to improve it. 


Activity Label
Start Time
Activity Duration
Queueing build in Hudson/Jenkins
00:00:00
0 s
Jazz Source Control setup
00:00:07
43 m 04 s
Accepting changes
00:00:08
25 s
Fetching files
00:00:34
42 m 37 s

Be the first one to answer this question!


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.