| Summary: | Regex Extractor uses old values when extending variable in template | ||
|---|---|---|---|
| Product: | JMeter - Now in Github | Reporter: | Jason Kershaw <jkershaw3> |
| Component: | Main | Assignee: | JMeter issues mailing list <issues> |
| Status: | NEW --- | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | 5.4.1 | ||
| Target Milestone: | JMETER_5.5 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | A jmx that demonstrates the bug. | ||
Yes, that is the current behaviour. Only those variables get reset, that are given explicitly by using a elements such as User Defined Variables.
The switch "Same user on each iteration" is (currently) used by the HTTP-HC4 client only.
If we were to change this behaviour, we might break other scripts, that rely on this, therefore we would at least have to add another switch to enable this.
It might be easier, if you add a JSR223-sampler at the end of the loop, that clears your variables for you. A simple on could use the following Groovy script:
vars.entrySet()
.collect { it.key }
.findAll { it =~ /_g\d*$/ }
.forEach { vars.remove(it) }
That script will remove all variables that end on '_g' or '_g[DIGITS]'.
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/5541 |
Created attachment 37874 [details] A jmx that demonstrates the bug. Using a regex extractor post processor to extend a string on multiple consecutive http requests overwrite retains the value from the first cycle. Example jmx attached. This extracts a nonce value from the www.google.com page. And uses the regex extractor template to extend the variable by using eg $1$,${varName} into variable varName. With a single user the first cycle works fine, any further cycles use the variable value from the first cycle. eg 4 requests and extractions x.y x=cycle y=request/extraction 1.1 sr=Qpbt+0uVejJl85n00CiV1g==, 1.2 sr=kUmkC/WPIV4mTvP80A63Gw==,Qpbt+0uVejJl85n00CiV1g==, 1.3 sr=HL7tYTCY2GqGI8YSqRpd2Q==,kUmkC/WPIV4mTvP80A63Gw==,Qpbt+0uVejJl85n00CiV1g==, 1.4 sr=EGv3EuOu8HSeWx/dOwfAiw==,HL7tYTCY2GqGI8YSqRpd2Q==,kUmkC/WPIV4mTvP80A63Gw==,Qpbt+0uVejJl85n00CiV1g==, 2.1 sr=v5leXa60bmYOQbpI/ioi0g==, 2.2 expected sr=X0aaX9AxdZ7G9McEo/vXTg==,v5leXa60bmYOQbpI/ioi0g==, 2.2 actual sr=X0aaX9AxdZ7G9McEo/vXTg==,Qpbt+0uVejJl85n00CiV1g==, (The actual contains the first value extracted from the first cycle.) 2.3 expected sr=07jOJApf8MzXAlm/haarQw==,X0aaX9AxdZ7G9McEo/vXTg==,v5leXa60bmYOQbpI/ioi0g==, 2.3 actual sr=07jOJApf8MzXAlm/haarQw==,kUmkC/WPIV4mTvP80A63Gw==,Qpbt+0uVejJl85n00CiV1g==, 2.4 expected sr=Oy0acoIlBYVcRK5XNgElUg==,07jOJApf8MzXAlm/haarQw==,X0aaX9AxdZ7G9McEo/vXTg==,v5leXa60bmYOQbpI/ioi0g==, 2.4 actual sr=Oy0acoIlBYVcRK5XNgElUg==,HL7tYTCY2GqGI8YSqRpd2Q==,kUmkC/WPIV4mTvP80A63Gw==,Qpbt+0uVejJl85n00CiV1g==, (3 of these values are from the 1st cycle) 3.1 sr=71fUCP7haV72SdVTHnPfZg==, 3.2 expected sr=TGzD17A0JiXpDV46xX0ulg==,71fUCP7haV72SdVTHnPfZg==, 3.2 actual sr=TGzD17A0JiXpDV46xX0ulg==,Qpbt+0uVejJl85n00CiV1g==, 3.3 expected sr=jQ/DLNeG2W8RxhN/FN4UXQ==,TGzD17A0JiXpDV46xX0ulg==,71fUCP7haV72SdVTHnPfZg==, 3.3 actual sr=jQ/DLNeG2W8RxhN/FN4UXQ==,kUmkC/WPIV4mTvP80A63Gw==,Qpbt+0uVejJl85n00CiV1g==, 3.4 expected sr=OTqG6f79QKYEPowC971sog==,jQ/DLNeG2W8RxhN/FN4UXQ==,TGzD17A0JiXpDV46xX0ulg==,71fUCP7haV72SdVTHnPfZg==, 3.4 actual sr=OTqG6f79QKYEPowC971sog==,HL7tYTCY2GqGI8YSqRpd2Q==,kUmkC/WPIV4mTvP80A63Gw==,Qpbt+0uVejJl85n00CiV1g==, (again 3 of the values are from the 1st cycle) Attached is a BUGSample.jmx which can be loaded and run to see the problem in the debug samplers wrapping the individual requests and the extractors.