Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Duplicate
-
Affects Version/s: 3.x
-
Fix Version/s: 3.9.5
-
Component/s: Core
-
Labels:None
-
Environment:HideIBM J9 VM (build 2.6, JRE 1.7.0 Windows 7 amd64-64 Compressed References 2013061
7_152572 (JIT enabled, AOT enabled)
J9VM - R26_Java726_SR5_20130617_1436_B152572
JIT - r11.b04_20130528_38954ifx1
GC - R26_Java726_SR5_20130617_1436_B152572_CMPRSS
J9CL - 20130617_152572)
JCL - 20130616_01 based on Oracle 7u25-b12ShowIBM J9 VM (build 2.6, JRE 1.7.0 Windows 7 amd64-64 Compressed References 2013061 7_152572 (JIT enabled, AOT enabled) J9VM - R26_Java726_SR5_20130617_1436_B152572 JIT - r11.b04_20130528_38954ifx1 GC - R26_Java726_SR5_20130617_1436_B152572_CMPRSS J9CL - 20130617_152572) JCL - 20130616_01 based on Oracle 7u25-b12
-
Number of attachments :
Description
I run several stories in parallel using the default multi-threaded Embedder.executorService and configure it with EmbedderControls.threads > 1
Sometimes the JBEHAVE ends and no scenario (but before- and after- scenario) of my stories was even started. It is not repeatable, sometims it goes good.
I founded out, that the method StoryManager.waitUntilAllDoneOrFailed fails, if there are ONLY stories, which are already SUBMITTED, but not yet really STARTED. The method StoryManager.waitUntilAllDoneOrFailed doesn't consider them while is defining, whether all stories are done or not. However waitUntilAllDoneOrFailed cancells them later.
The success or failure of stories depend therefore on the race condition of starting the stories and waitUntilAllDoneOrFailed.
Activity
Duplicate of JBEHAVE-1046.
Mauro Talevi
added a comment - Duplicate of JBEHAVE-1046 . Mauro Talevi
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Resolution | Duplicate [ 3 ] | |
| Fix Version/s | 3.9.5 [ 20598 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
Hey guys, I just saw this fix for 4.0-beta-11. I have a suggestion to make.
This was happening because the thread that changes the value of the isStarted flag to true doesnt have time to execute before the StoryMangar passes trhough it.
To fix that, I simple change the code to call the tickTock before the execution, and not after. Then everything worked fine.
I belive that this is more elegant than create another flag.
Rodrigo Machado
added a comment - Hey guys, I just saw this fix for 4.0-beta-11. I have a suggestion to make.
This was happening because the thread that changes the value of the isStarted flag to true doesnt have time to execute before the StoryMangar passes trhough it.
To fix that, I simple change the code to call the tickTock before the execution, and not after. Then everything worked fine.
I belive that this is more elegant than create another flag. You mean before the loop over the RunningStory collection, and not after?
You think that 100ms would make such a difference?
Mauro Talevi
added a comment - You mean before the loop over the RunningStory collection, and not after?
You think that 100ms would make such a difference? 
With this patch I could solve this problem. I didn't refactor the "if (true)" in order to show the real change.
diff --git a/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryManager.java b/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryManager.java
index 2414cf7..ad70587 100644
— a/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryManager.java
+++ b/jbehave-core/src/main/java/org/jbehave/core/embedder/StoryManager.java
@@ -143,7 +143,7 @@
while (!allDone) {
allDone = true;
for (RunningStory runningStory : runningStories.values()) {
+ if ( true ){
Story story = runningStory.getStory();
Future<ThrowableStory> future = runningStory.getFuture();
if (!future.isDone()) {