Details
Improvement
Resolved
Major
Description
See attached test case to reproduce
Activity
The statistics collector is currently not thread safe. To do so, the member variables need to be held in ThreadLocal.
Alternatively, the PerformableTree structure introduced in 4.x branch has the potential of a much cleaner and powerful reporting.
Either way, contributions are most welcome.
Mauro Talevi
added a comment - The statistics collector is currently not thread safe. To do so, the member variables need to be held in ThreadLocal.
Alternatively, the PerformableTree structure introduced in 4.x branch has the potential of a much cleaner and powerful reporting.
Either way, contributions are most welcome. Having looked a bit more, I think this is happening because ConcurrentStoryReporter is deferring execution of the StoryReporters until after the story has executed.
I have a couple of ideas:
- Implement timing of stories in a similar way to CrossReference's durationInMillis for invidual steps: make PerformableStory save a StoryResults object that would be serialised by CrossReference
- Provide a way deferring execution of only some StoryReporters. Then make PostStoryStatisticsCollector thread safe as you suggested
Any further thoughts?
James Shaw
added a comment - - edited Having looked a bit more, I think this is happening because ConcurrentStoryReporter is deferring execution of the StoryReporters until after the story has executed.
I have a couple of ideas:
Implement timing of stories in a similar way to CrossReference's durationInMillis for invidual steps: make PerformableStory save a StoryResults object that would be serialised by CrossReference
Provide a way deferring execution of only some StoryReporters. Then make PostStoryStatisticsCollector thread safe as you suggested
Any further thoughts? Mauro Talevi
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Summary | PostStoryStatisticsCollector does not measure story duration when EmbedderControls.threads > 1 | Add timings to serialisable data of PerformableStory |
| Issue Type | Bug [ 1 ] | Improvement [ 4 ] |
| Fix Version/s | 4.0 [ 18486 ] |
I agree with your suggestion 1, and I have changed the issue accordingly.
Option 2 is just too messy and would create more problems than it would solve. This is precisely one of the use cases for the 4.x refactor.
Mauro Talevi
added a comment - I agree with your suggestion 1, and I have changed the issue accordingly.
Option 2 is just too messy and would create more problems than it would solve. This is precisely one of the use cases for the 4.x refactor. I've had a stab at implementing suggestion 1: https://github.com/jbehave/jbehave-core/pull/33
James Shaw
added a comment - I've had a stab at implementing suggestion 1: https://github.com/jbehave/jbehave-core/pull/33 Thanks James. I've reworked it slightly to make the timing class reusable at different levels, not just story.
Added a test in ConcurrencyBehaviour to verify that timing is recorded for stories run in multi-threading.
If you can test latest snapshot, we release a beta for your use.
Mauro Talevi
added a comment - Thanks James. I've reworked it slightly to make the timing class reusable at different levels, not just story.
Added a test in ConcurrencyBehaviour to verify that timing is recorded for stories run in multi-threading.
If you can test latest snapshot, we release a beta for your use. Latest snapshot is working for me, thanks Mauro.
James Shaw
added a comment - Latest snapshot is working for me, thanks Mauro. Nice, 4.0-beta-1 is cut and should be synched to central in next few hours.
Mauro Talevi
added a comment - Nice, 4.0-beta-1 is cut and should be synched to central in next few hours. Mauro Talevi
made changes -
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Assignee | Mauro Talevi [ maurotalevi ] | |
| Resolution | Fixed [ 1 ] |
Having the same problem in 3.7-SNAPSHOT (39a3f6558aa90a168bfc39ec5ee4dfb5d2145aba)