ashrafiucse opened a new pull request, #6759:
URL: https://github.com/apache/jmeter/pull/6759
## Description
`RegexExtractor` now parses its internal group-count and match-count
variables (`<refname>_g`, `<refname>_matchNr`) without relying on exceptions,
via a small `parseIntOrDefault` helper. Values that are present but not numbers
still log the same warning as before; absent variables yield the previous
default values, so behavior is unchanged.
## Motivation and Context
Fixes #6240
Every failed extraction calls `RegexExtractor#removeGroups`, which parsed
the (still absent) group-count variable with `Integer#parseInt`. Parsing `null`
always throws a `NumberFormatException`, which was caught and silently
discarded:
```java
try {
groups = Integer.parseInt(vars.get(buf.toString())); // null when no
match succeeded yet
} catch (NumberFormatException e) {
groups = 0; // silent
}
```
So each failing extraction paid for creating and discarding an exception. In
failure-heavy test runs (which are exactly the scenario a load test exercises
against a struggling system), failed extractions are the hot path.
I verified this against a locally built distribution with
`-Xlog:exceptions=info` (which reports every thrown exception, including caught
ones): a test plan with a non-matching extractor over 200 iterations produced
**exactly 200 `NumberFormatException`s, all in `RegexExtractor.removeGroups`**
(one per failed extraction, and nothing visible in jmeter.log). A
matching-extractor control run produced zero. With this change the failing run
produces **zero** exceptions.
For scale: the exception costs roughly 0.5 µs per failed extraction, so this
is a modest but free win, and it also removes the pointless churn. The
remaining `parseInt` call inside the helper only triggers for well-formed digit
strings.
## How Has This Been Tested?
- New tests in `TestRegexExtractor`:
- `testNoMatchOnFreshVariablesAppliesDefault`: the previously
exception-throwing path (no match, no prior group variables) applies the
default and leaves no group variables behind
- `testNoMatchCleansUpPreviousGroupVariables`: group variables from an
earlier successful extraction are cleaned up on failure
- `testNoMatchWithTamperedGroupCountVariable`: a corrupted `<refname>_g`
value is handled (warn + default) without breaking the extraction
- `testAllMatchesWithTamperedMatchNumberVariable`: a corrupted
`<refname>_matchNr` value does not break all-matches mode
- All 29 `TestRegexExtractor` tests and the full `:src:components:test`
suite (553 tests) pass
- `./gradlew classes style` passes
- End-to-end check with a locally built distribution as described above: 200
failing iterations → 0 exceptions (previously 200), all samples successful,
extracted/default values unchanged
## Types of changes
- Bug fix (non-breaking change which fixes an issue)
## Checklist:
- [x] My code follows the [code style][style-guide] of this project.
- [x] I have updated the documentation accordingly. (release notes entry
added to `xdocs/changes.xml`)
[style-guide]: https://wiki.apache.org/jmeter/CodeStyleGuidelines
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
