It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,496
×10,572

question asked: Oct 12 '09, 9:30 a.m.
question was seen: 5,369 times
last updated: Oct 12 '09, 9:30 a.m.

Related questions

FAQ - How this Forum works

Selector number error using JBE

0
Michele Pegoraro (1.8k●12●114●102) | asked Oct 12 '09, 9:30 a.m.
Hi,
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

Most liked answers ↓|Newest answers|Oldest answers

0
permanent link
Michele Pegoraro (1.8k●12●114●102) | 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.
0
permanent link
Nick Edgar (6.5k●7●11) | answered Oct 14 '09, 1:06 p.m.
JAZZ DEVELOPER
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.
0
permanent link
Michele Pegoraro (1.8k●12●114●102) | 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.