Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Counter function bug or documentation issue ? #2571

Closed
asfimport opened this issue Sep 30, 2011 · 7 comments
Closed

Counter function bug or documentation issue ? #2571

asfimport opened this issue Sep 30, 2011 · 7 comments

Comments

@asfimport
Copy link
Collaborator

@pmouawad (Bug 51923):
Hello,
Issue seen by deepak.
Per the documentation:
"The counter generates a new number each time it is called, starting with 1
and incrementing by +1 each time."

However
ThreadGroup
+${__counter(TRUE,ref)}HTTPSampler1
+DebugSampler
+${__counter(TRUE,ref)}HTTPSampler2
+DebugSampler
+View Results tree

Generates the number 1 in both cases.

Created attachment BUG_COUNTER.jmx: Test Plan that reproduces the issue

Severity: trivial
OS: All

@asfimport
Copy link
Collaborator Author

@pmouawad (migrated from Bugzilla):
Hello,
I confirm this issue on 2.5 and 2.5.1.

Analyzing it, issue is due to the fact that if you have 2 __counter with same ref, you will have 2 instances of CounterConfig.

As perTheadNumber is not static, 2 counters will be incremented separately.

So either it's a feature then documentation should be fixed
Either it's a real issue, but fix can impact existing scenarios that excpect this behaviour.

Regards
Philippe

@asfimport
Copy link
Collaborator Author

@pmouawad (migrated from Bugzilla):
(In reply to comment 1)

Hello,
I confirm this issue on 2.5 and 2.5.1.

Analyzing it, issue is due to the fact that if you have 2 __counter with same
ref, you will have 2 instances of CounterConfig.

Error : 2 instances of IterationCounter

As perTheadNumber is not static, 2 counters will be incremented separately.

But making it static is not the fix.

So either it's a feature then documentation should be fixed
Either it's a real issue, but fix can impact existing scenarios that excpect
this behaviour.

I think it's a feature

Regards
Philippe

@asfimport
Copy link
Collaborator Author

@pmouawad (migrated from Bugzilla):
Created attachment ISSUE_51923.patch: Patch to function documentation

ISSUE_51923.patch
Index: xdocs/usermanual/functions.xml
===================================================================
--- xdocs/usermanual/functions.xml	(revision 1177692)
+++ xdocs/usermanual/functions.xml	(working copy)
@@ -303,7 +303,7 @@
 
 <component index="&sect-num;.5.2" name="__counter">
 <description><p>The counter generates a new number each time it is called, starting with 1
-and incrementing by +1 each time.  The counter can be configured to keep each simulated user's values
+and incrementing by +1 each time, note that multiple __counter calls in same iteration won't increment value.  The counter can be configured to keep each simulated user's values
 separate, or to use the same counter for all users.  If each user's values is incremented separately,
 that is like counting the number of iterations through the test plan.  A global counter is like
 counting how many times that request was run.

@asfimport
Copy link
Collaborator Author

Sebb (migrated from Bugzilla):
The docn already says:

>>
The counter function instances are now completely independent. [JMeter 2.1.1 and earlier used a fixed thread variable to keep track of the per-user count, so multiple counter functions operated on the same value.] The global counter - "FALSE" - is separately maintained by each counter instance.
<<<

If anything needs to be clarified, it is that paragraph.

@asfimport
Copy link
Collaborator Author

@pmouawad (migrated from Bugzilla):
Created attachment ISSUE_51923.patch: Patch to documentation

ISSUE_51923.patch
Index: xdocs/usermanual/functions.xml
===================================================================
--- xdocs/usermanual/functions.xml	(revision 1177692)
+++ xdocs/usermanual/functions.xml	(working copy)
@@ -313,6 +313,7 @@
 [JMeter 2.1.1 and earlier used a fixed thread variable to keep track of the per-user count, 
 so multiple counter functions operated on the same value.] 
 The global counter - "FALSE" - is separately maintained by each counter instance.
+So multiple __counter calls in same iteration won't increment value.
 </p>
 </description>
 <properties>

@asfimport
Copy link
Collaborator Author

Sebb (migrated from Bugzilla):
Here is a simplified test case using Java samplers instead of HTTP.

Also included is a PreProcessor that updates the COUNT variable for every sample in the thread

Created attachment Bug_51923.jmx: Simplified test case

@asfimport
Copy link
Collaborator Author

Sebb (migrated from Bugzilla):
URL: http://svn.apache.org/viewvc?rev=1178883&view=rev
Log:
#2571 - Counter function bug or documentation issue ? (fixed docs)

Modified:
jakarta/jmeter/trunk/xdocs/changes.xml
jakarta/jmeter/trunk/xdocs/usermanual/functions.xml

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant