Bug 50134

Created attachment 26198 [details]
JMX Plan showing issue

Created attachment 26199 [details]
JSP for test case

Put this JSP in standard Tomcat 6 inside folder:
examples/jsp/test

Created attachment 26200 [details]
Patch to the bug

This patch corrects the issue.

Hello,
I submitted the patch, hope you can take it into account soon.

Thank you 
Regards
Philippe M.
http://www.ubik-ingenierie.com

Would it be possible to provide a simpler test case using just Java Request samplers?

Created attachment 26201 [details]
Simpler Test plan

Here is a simpler test based on java samplers.

Philippe M.
http://www.ubik-ingenierie.com

Created attachment 26202 [details]
Screenshot showing bug with new Java Sampler JMX

Sorry, but the test plan is still quite difficult to follow, as it has disabled entries and assertions, several thread groups etc.

I've no idea which parts of the plan are relevant.
Time spent fixing the test plan is time that cannot be spent fixing the bug.

Please can you provide the simplest possible plan that shows the problem?

Sorry sebb, You can remove all disabled objects, thé scénario to use is S5.
You run it and in résults you Will see that scénario 5 has wrong response Time it cumulates all its inner response Time even when on transactioncontroller contains another one.
I Can upload new jmx within tomorrow if you really need it.

I submitted thé patch to bug and tested it successfully.

Thank you

Created attachment 26203 [details]
Cleaned up JMX

Sorry It seems I messed up with my JMX, this one is the good one.
Thank you again for your time.

Regards

Comment on attachment 26200 [details]
Patch to the bug

Patch is not working.
There is some other case it does not solve.

Created attachment 26245 [details]
Patch to issue

Hello,
I analyzed a bit more what was happening.
I think I understood where the issue comes from.

As the plan is built, here is how sampleOccured in TransactionController is called:
SampleOccured :s4-1-s1 in :s4-chapeau
SampleOccured :s4-1-s1 in :scenario5
SampleOccured :s4-1-s2 in :s4-chapeau
SampleOccured :s4-1-s2 in :scenario5
SampleOccured :s4-chapeau in :scenario5

This is because scenario5 and s4-chapeau are both registered as listeners for each sample, this end up in the upper most parent recording twice things and mixing up pause time.


In my analysis there are 2 types of SampleEvent:
- One that is initiated by a real Sample
- One that is initiated "artificially" by TransactionController#next2, this one should not be used in computations


So my idea was to distinguish them by an additional attribute called isTransactionSampleEvent.
I use this attribute setting it to true in next2() to build the SampleEvent
and use it in sampleOccured() to use it in computation or not.


I tested with the existing test plan and the one that is a bit more complicated and it works.
But I think you have the big picture to validate this modification.

By the way you will notice some changes in SampleEvent because I made some refactoring in the constructor to make them use each others instead of copy/paste.


Thank you for your time and great product and hope you will have some time to take this patch into account.

Regards
Philippe M.
http://www.ubik-ingenierie.com

Yes, I think your analysis is correct, and the patch approach is reasonable.

Applied the fix to SVN with some minor changes:
- dropped unnecessary setTransactionSampleEvent and made boolean final
- made new ctor private, as not used externally
- simplified nested conditional block.
- replaced tabs with spaces, and removed spurious blank lines


URL: http://svn.apache.org/viewvc?rev=1029746&view=rev
Log:
Bug 50134 - TransactionController : Reports bad response time when it contains other TransactionControllers

Modified:
   jakarta/jmeter/trunk/src/core/org/apache/jmeter/control/TransactionController.java
   jakarta/jmeter/trunk/src/core/org/apache/jmeter/samplers/SampleEvent.java
   jakarta/jmeter/trunk/xdocs/changes.xml

This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/2415