It's all about the answers!

Ask a question

Selector number error using JBE

Michele Pegoraro (1.8k12114102) | asked Oct 12 '09, 9:30 a.m.
as I've reported on another topic (here), it seems that JBE has some problems with selector ids.

Now I'm running some performance test on my compiler machine with the following configuration:
3 different build engine that run on the same machine
3 different project area with a specific build definition that could run on all previous 3 build engine

I create a build request for each project area at the same time.
Running my build (that contains check-in, association and delivery steps) I've find out this problem:
two different build has made a check-in at the same time and scm checkin command returns to me the SAME change-set selector id (1066). After this, when I try to associate the change-set to a work-item, one of these builds run correctly and the other one fails beacause it is not able to find the selector. I'm entered into my private repository and I have run scm status command and then I've seen that the correct id was not 1066 but 1067.

So it seems to me that there is a mismatch on what scm checkin returns and what it is saved into repository. Is it possible this behaviour??

3 answers

permanent link
Michele Pegoraro (1.8k12114102) | answered Oct 15 '09, 8:53 a.m.
Yes, each build definitions had its own workspace. But now, thanks to your help on the other topic, I think to have resolved the problem.

permanent link
Nick Edgar (6.5k711) | answered Oct 14 '09, 1:06 p.m.
I'm assuming you've defined 3 different build definitions for the different project areas. Do they all share the same build workspace? If so, you won't have the necessary isolation between builds. For example, if build 1 checks in a change with selector 123 then build 2 schecks in a change with selector 456, then status from build 1 may show 456 instead of 123.

Each build definition should have its own build workspace.

Note that the selector ids shown by the SCM tool are just a client-side artifact. I'm not sure how it comes up with these ids, but they are not stored server-side.

permanent link
Michele Pegoraro (1.8k12114102) | answered Oct 13 '09, 5:47 a.m.
I have some other hints on this problem. In the following lines I perform a "smc chechin" and after an "scm status". The example is in italian but you can see as the selector of the change-set is different beetween chackin and status (it changes from 1098 to 1104). This happens only launching more than one compilation at the same time.

[exec] Eseguo check-in di D:\CCM_BP\BuildDirs\MKTA3_CompORDWS/TAL_bin

[exec] Esecuzione del commit in corso...
[exec] Spazio di lavoro: (1044) "MKTA3_CompORDWS" <-> (1045) "MKTA3_Collaudo"
[exec] Componente: (1049) "MKTA3_Bin"
[exec] In uscita:
[exec] Serie di modifiche:
[exec] (1098) --@ <Nessun>
[exec] *********************
[exec] Spazio di lavoro: (1044) "MKTA3_CompORDWS" <-> (1045) "MKTA3_Collaudo"
[exec] Componente: (1046) "MKTA3_Src"
[exec] Baseline: (1047) 2 "MKTA3_CompORD_20091012-1357"
[exec] In uscita:
[exec] Serie di modifiche:
[exec] (1104) --@ <Nessun>
[exec] Baseline:
[exec] (1103) 26 "MKTA3_CompORD_20091013-1050"

Your answer

Register or to post your answer.