Apparently,
googlejavaformat.java.RemoveUnusedImports
is not able to parse Java 17. I'm not sure if it can be resolved with
bumping googlejavaformat version.
I am leaning towards using openrewrite for that as it's parser is more
robust.
For now, we could temporary disable import order check.
Thank you for the kind words.
>In JMeter 5.6.1 (a patch version) the default encoding for http samplers
has been changed from the OS default one to UTF-8. Here is the pr:
https://github.com/apache/jmeter/pull/6010
Sorry if it sounds like a dumb question, but could you please clarify what
exact
Are there volunteers to contribute to the relevant changes (e.g. thread
group changes, tests)?
Vladimir
>Maybe it won't help on memory side, but it will help on CPU side and
>increase scalability.
Maybe. Maybe not.
You are free to give it a try.
Vladimir
>Now java 21 has integrated Virtual Threads , isn't it the time to use it,
I'm +0 regarding that.
Of course, we might try adding "use virtual threads" property to a Thread
Group and check how it would behave.
However, I would not expect much out of it.
It might produce hype, however, I doubt it
semver suggests always using three components (e.g. see 2.0.0 at semver.org)
WDYT?
Vladimir
Thank you for preparing RC2.
+1
The case with the thread group scheduler is resolved.
Vladimir
Philippe, thanks for catching that.
I've committed a fix for ThreadGroup scheduler fields.
Milamber, would you please prepare RC2?
Vladimir
>can you fix this? (or revert if better to keep these important
>change to the next major version)
I will fix it shortly.
Vladimir
+1 (binding)
Thank you for preparing the release.
> suppose that this sentence can be remove:
>"JTable selection with keyboard (SHIFT + up/down) is totally unusable
>with Java 7 on Mac OSX
I thought behind the same lines, however, we should probably remove it and
the other pre-Java 17 known
Hi,
I think we should be good to go.
I've merged the fix for test element properties, and I've refactored the
existing JUnit3/4 and Spock tests to JUnit 5.
Milamber, do you think you could prepare a release candidate?
Vladimir
Hi,
I've prepared a PR that migrates existing Groovy tests to Kotlin:
https://github.com/apache/jmeter/pull/6212
I admit it might not be convenient for everyone, however, I hope it is a
net positive change.
The tooling for Groovy lags. An automatic code format is not possible,
autocomplete, and
>There are missing bits like adding javadocs, and selecting the class and
method names, however, it would be great if somebody could test if the PR
fixes their workflows/scripts.
Ok, I polished the docs and naming. I am going to merge the PR soon.
Vladimir
I think I figured out the solution for properties, and I like the way it
works now.
I put the description in https://github.com/apache/jmeter/pull/6199, and I
think the solution is more-or-less ready to go.
For instance, BeanShellSamplerGui, OpenModelThreadGroupGui become much
simpler as they no
For reference, I think `clearGui` is not needed for UI elements that
represent TestElement properties.
At the same time, clearGui might be needed to reset UI state which is not
connected to TestElement properties.
For instance, if there's a "tabbed pane", we might want resetting the UI to
its
Hi,
Does anybody know what is the use of
org.apache.jmeter.gui.ClearGui#clearGui?
It looks like clearGui method does not add much value, so I am leaning
towards to removing it eventually.
We currently have "configure(TestElement element)" (update UI from the
values in TestElement) and
I am analyzing the issue "Downloading of embedded resources via HTTP
Request Default not working on v5.6.2" (
https://github.com/apache/jmeter/issues/6076 ),
and it requires fixing the implementation of properties. I think we should
fix it in 5.6.3
I hope to sort it out by Friday.
Vladimir
I've prepared the changelog for 5.6.3:
https://github.com/apache/jmeter/pull/6190
I suggest releasing 5.6.3 and moving to 6.0 development.
Any thoughts?
Vladimir
Hi,
I think 5.6.3 is long overdue, and I would like to cut a release soon.
Does anybody have any objections?
Does anybody know the pressing issues we should fix before releasing 5.6.3?
I will update the changelog to include the relevant changes, known bugs,
and issues fixed in 5.6.3.
Vladimir
Java 21 was released just a couple of months ago, so it might be too early
to require Java 21 for the execution. We should probably support at least
two LTS releases.
Vladimir
Hi,
Previously, we discussed bumping Java requirements to 11, and there were no
complaints.
Now I suggest we consider requiring Java 17 instead.
I think it should not be a problem as Java 17 was released quite a while
ago, and the users should be able to upgrade the runtime.
Many users execute
+1
I tested the release artifacts and the case in
https://github.com/apache/jmeter/issues/6041
Vladimir
Hi,
I suggest using GitHub Actions to prepare and sign release artifacts.
The ASF Security, Infra, and Legal teams have validated the process, so we
should be good.
See https://infra.apache.org/release-signing.html#automated-release-signing,
https://github.com/apache/www-site/pull/235
Note:
>I will watch for abuse.
Thank you for the response.
Technically speaking, first-time contributors would need manual approval
for executing CI anyway,
so we don't need to constantly monitor pull requests for cryptominers and
things like that.
Just wondering: are the others silent because they
+1 (binding)
Thank you for preparing RC2, the release looks good to me.
Vladimir
There's a question on displaying default values in UI:
https://github.com/apache/jmeter/issues/6026
They say it is confusing to see the defaults in "HTTP Request Defaults"
since the user can't tell if it will overwrite HTTP request or not.
I agree it is confusing, and it brings a new question:
Thanks for preparing the release,
+1 (binding)
I checked apache-jmeter-5.6.1.tgz with macos and Java 11: checksums,
pgp, http proxy.
Vladimir
I think we are good to start with 5.6.1 RC1
Vladimir
> So I can start RC1 for 5.6.1 today?
I've merged "utf-8 by default" PR, so the only thing left before preparing
a RC is
updating the changelog: https://github.com/apache/jmeter/pull/6024
If the changelog looks good to me, we can merge PR6024 and start RC1.
> (i think that we have an issue on
>> * improvement on JavaFX missing error message when java 9+?
1) The build now excludes JavaFX-based components unless you opt-in
with -PenableJavaFx
2) I've reduced log severity: info + no stacktrace by default,
debug+stacktrace if logging is in debug mode
Vladimir
Hi,
I suggest we release JMeter 5.6.1 soon as the latest 5.6 has several issues:
* ThreadGroups run forever in non-GUI mode if JMX is saved with 5.6 (fix
merged)
* Java samplers can't be re-enabled after disabling them (fix merged)
I included unicode filename encoding to 5.6, however, it was
> With the -1 from Philippe, we cannot release 5.6rc1 as 5.6...
Why is that?
1) Please review https://www.apache.org/foundation/voting.html#ReleaseVotes
"Releases may not be vetoed"
2) Please review https://www.apache.org/foundation/voting.html#ReleaseVotes
"at least three PMC members must vote
Philippe, thanks for your comments and vote. I'm looking forward to hearing
the reproducer from you.
Milabmer, do you think 5.6 can be released then?
Just in case, I would remind everybody that "Releases may not be vetoed"
(see https://www.apache.org/foundation/voting.html#ReleaseVotes)
>This
> I think there is a behavioural change related to this commit:
> it seems to me we can end up losing
SampleResults
We are stopping the test, and I doubt we can guarantee we will record all
events, including those that happen exactly at the moment of stopping the
test.
The test case I added
> Add a warning in the beginning of the release notes with "A lot of core
> features has been modified, please test your JMeter plugins before
> migrating,"
I do not think that is fair.
JMeter keeps backward compatibility, and all plugins should be compatible as is.
I do not see why should we put
Hi,
I'm going to merge "gradle toolchains" soon: see
https://github.com/apache/jmeter/pull/5989.
It would enable us to separate "JDK for building, JDK for testing, and
target(bytecode) JDK version".
The code would still build Java 1.8-compatible bytecode, however, it would
use Java 17 for build
> Caused by: java.lang.NullPointerException: Cannot invoke
> "javax.swing.JPanel.remove(int)" because "optionPanel" is null
> at
com.blazemeter.jmeter.http2.sampler.gui.HTTP2SamplerPanel.replaceKeepAliveCheckWithHttp1Upgrade(HTTP2SamplerPanel.java:60)
> ~[jmeter-bzm-http2-2.0.2.jar:?]
> at
> Milamber: When I start JMeter 5.6RC1 with java 11 or 17, add a View
Results Tree
> listener, I have this error:
I reproduced it, and as far as I understand, it does not impact the
usability of the View Results Tree.
The issue is that JavaFX is optional even in Java 1.8 distributions, and
the
atch(InvocationEvent.java:318)
> ~[?:?]
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:771) ~[?:?]
> at java.awt.EventQueue$4.run(EventQueue.java:722) ~[?:?]
> at java.awt.EventQueue$4.run(EventQueue.java:716) ~[?:?]
> at
> java.security.AccessController.doPrivile
> pass, I will delete this (pre-)5.6 version for the next release (and
> avoid to release before the end of vote!)
The artifacts have already propagated to Centarl, so there's virtually no
way to delete them.
I suggest we keep them, and release 5.6.1 instead if we need corrections.
By the way,
Thank you for preparing the RC.
+1 I support this release
Vladimir
I believe JMeter code is in a good shape now, and it is ready for
preparing a release candidate.
Milamber, would you please create one?
Vladimir
I've added a "copy code" context action (implementation, tests,
documentation), so it copies the code that users can paste into their
projects.
In other words, it enables configuring an element (or a subtree) in UI
and automatically generating code.
The generator uses element schemas to create a
>Any idea to solve this problem?
It is hard to understand the reason for the failure without looking into
the code.
It would be great if you could file a draft pull request with your changes.
Here's how you could add har-reader module into JMeter:
https://github.com/apache/jmeter/pull/5976
Currenlty, every pull request from external contributor requires manual
approval,
which, I believe, adds unnecessary barriers for the contributors.
Infra can remove that requirement, however, they ask us to review and
"affirm abiding by the requirements".
Here's the document:
I've been improving tests, and I realized there's a small change that
brings a decent way to build test plans.
I've updated PR https://github.com/apache/jmeter/pull/678
The PR includes samples for both Kotlin and Java
(see OpenModelThreadGroupConfigElementTest
and
> DO I need to add a checksum?
That is right, we require dependency verification.
Here's a sample when I recently added a new dependency:
https://github.com/apache/jmeter/commit/a2690e8a6d22420869eb89643c116901cc5c5bce
Note that there were changes to checksum.xml, and the new pgp keys have
been
> I have added
api("com.github.sdstoehr:har-reader:2.2.1")
in src/bom-thirdparty/build.gradle.kts
That’s right.
You declare version in bom-thirdparty, and then you add a dependency
without version.
For instance, add implementation(“
com.github.sdstoehr:har-reader”) to src/core/build.gradle.kts.
Hi there,
I believe we could release 5.6 soon.
I've merged the PR from Felix (the one for #{url} template in recorder).
I polished release notes: https://github.com/apache/jmeter/pull/5936
I've finished work on "editable checkboxes":
https://github.com/apache/jmeter/pull/5944
I believe the
Hi,
I'm about to finish work on "editable checkboxes" UI element in
https://github.com/apache/jmeter/pull/5944
It fixes 20year old bug https://github.com/apache/jmeter/issues/1252 :)
It enables users to configure expressions in UI for cases when checkboxes
were used previously.
For example,
>jmeter plugin don't
>work (I don't see the picto in menu bar)
Antonio, could you please file an issue?
What is not showing in the menu?
Vladimir
Hi,
JMeter release is long overdue, and I think we are almost ready to cut 5.6.
I am polishing the changelog in
https://github.com/apache/jmeter/pull/5936
I suggest we prepare a candidate after the changelog update.
Comments are welcome.
There is a couple of PRs that might be included to 5.6
Hi,
Recently, ASF GitHub repos had their defaults for GitHub Actions changed to
"always require approval for external contributors".
Airflow has recently submitted a ticket to have that changed back:
https://issues.apache.org/jira/browse/INFRA-24200.
IMO, we should do the same. I don't think we
I want to include
https://github.com/apache/jmeter/pull/727 (add NoThreadCloning to
httpHeaders)
It impacts RAM usage a lot in our case as we have headers for every http
sampler (just like recorder creates them)
It requires 5788 as headers might contain functions.
Felix> That is what I thought, too. But even changing the source of the
test (with something, I know will break it), didn't work. Spock tests in
the same package (src/components) will run just fine.
It turns out that junit5 tests were not executed since there was no
junit-jupiter engine on the
I guess the reason is that execute tests several times. Gradle caches
test results.
In other words, if you execute the same tests with the same source,
then the build does not execute tests again.
However, if you modify test code and/or change dependency, then tests
would be re-executed.
> +if (fmt.contains("u")) {
> +
> log.warn(JMeterUtils.getResString("time_format_changed"));
> +}
Should we rather print a warning one time only?
Should we print a sampler name and the format string in question?
I'm afraid the currently added
Hi
> The vast majority of all emails are auto-generated emails from GitHub.
The emails are not from GitHub. The ill notifications are from GitBox.
I've been deleting GitBox mails for quite some time now because they make
no sense.
GitHub produces much better notifications.
> it makes it hard
If PR5712 looks good enough, then it could indeed be merged.
I guess we could accompany that with 5.5.1 release to update the site
as a part of a regular release.
Vladimir
>Add issue templates on GitHub
done, see https://github.com/apache/jmeter/issues/new/choose
>* Handle ... template in documentation markup (currently,
changelog expects ..
done
>* Update documentation references (Bugzilla -> GitHub Issues)
See https://github.com/apache/jmeter/pull/5712
Hi,
It is somewhat strange that we have "src/" folder for modules.
It results in folders like src/core/src (note that src is duplicated).
What do you think of removing top-level "src" folder, and moving to layout
like
/jmeter-core/
/jmeter-components/
...
I guess it would be slightly easier to
Milamber,
Please create issues-gitbox mailing list via https://selfserve.apache.org/
Creating mailing lists it is "restricted to ASF members and PMC chairs
only", so I can't do it.
Vladimir
I've finished the migration.
The next steps are:
* Add issue templates on GitHub
E.g. https://github.com/apache/lucene/pull/1024
* Handle ... template in documentation markup (currently,
changelog expects ..
* Update documentation references (Bugzilla -> GitHub Issues)
It looks like I should not
I'm about to start the migration.
Please refrain from creating issues and PRs for apache/jmeter GitHub
repository until the migration is finished.
Vladimir
Hi,
I think I'm ready for migration bugs to GitHub Issues.
If no objections, I suggest starting the migration on ~ 23 Sep 08:00 UTC.
AFAIK JMeter Bugzilla is read-only now.
The plan is
1) Temporarily pause GitHub interactions for apache/jmeter repository
(prevent creating new PRs, issues)
2)
> HeaderManager should not be shared.
Can you elaborate on why HeaderManager should not be shared?
A colleague of mine just showed me a heap dump that included
~1'400'000 instances of HeaderManager.
Basically, the style of the test plan was to have a HeaderManager
under every HttpSampler, so it
I've conflated "os" labels to All, macOS, Windows, Linux (full OS is
present in text),
I've removed the severity label completely (it is in text only). I keep
just "enhancement" and "regression" as labels.
I've simplified priority labels. They are P1, P2, ... instead of "priority:
P1", "priority:
Update:
* I've implemented Bugzilla milestones -> GitHub milestones conversion
* I've added links to GitHub profiles
* I've removed issue headers, and moved attachments to comment footers, so
issues look pretty much the same as if they were manually created at GitHub
* I've removed "bugzilla"
I've created a draft migration plan, comments are welcome:
https://docs.google.com/document/d/1kUN9wMFR1CEydq345Nh_ohrPkCsQdaHjSUYpPAUfw6I/edit#heading=h.xm5w7ls8nz2w
https://issues.apache.org/jira/browse/INFRA-23553
Vladimir
Some updates: I've implemented cross-references (duplidates, duplicated by,
depends on, blocks)
On top of that, every "bug 2323" mention is replaced with GitHub URL, so
navigation between issues works.
Here's a sample issue: https://github.com/vlsi/tmp-jmeter-issues/issues/1188
The import takes
Drew from Infra fetched and sanitized the dump, and I was able use it
directly instead of fetching the data from UI.
I ran the first import, and here's how it looks:
https://github.com/vlsi/tmp-jmeter-issues/issues
It looks more-or-less fine to me.
Note: last time I imported, there was a
I've raised https://issues.apache.org/jira/browse/INFRA-23475 to fetch
Bugzilla dump.
Vladimir
>* Maybe we could dump the data from the MySQL database, import in into a
clone and work from that instance instead through the UI?
This might indeed be a better idea. It is great I did not invest much time
in scraping the UI.
The sad thing is the dump contains sensitive information, so I would
I've made progress on Bugzilla -> GitHub migration.
Frankly speaking, I'm not comfortable refactoring/maintaining Python code
(which is what many projects use to migrate off Bugzilla),
so I created Kotlin-based project so the data and fields are typed:
https://github.com/vlsi/bugzilla2github
For
>Could you create zip and tar.gz with real file date ?
The date is fixed for reproducibility reasons.
In other words, if you build JMeter with a more-or-less the same Java
version, you'll get the same archives.
Vladimir
Hello,
[x] +1 I support this release
Thanks to Milamber.
Vladimir
rea and explicitly disable line wrapping
instead?
Vladimir
пн, 21 мар. 2022 г. в 17:35, Felix Schumacher <
felix.schumac...@internetallee.de>:
>
> Am 20.03.22 um 16:35 schrieb Felix Schumacher:
>
>
> Am 16.03.22 um 18:14 schrieb Vladimir Sitnikov:
>
> I would say, tha
f it’s worth it as it will introduce additional config complexity
>
> Regards
> On Wednesday, March 16, 2022, Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com>
> wrote:
>
> > >I would say, that my issue is not a regression and therefore should be
> not
> > a blocker.
>I would say, that my issue is not a regression and therefore should be not
a blocker.
There might be a regression like: "new setting caused activating kerning
for texts smaller than 10K" (or whatever is the default).
So if previously the kerning was always disabled, the new option might
Felix, thank you.
I went over the stacktrace and found an interesting case:
8231084: Large performance regression in SwingMark TextArea in 14-b13
https://github.com/openjdk/jdk/commit/007a0fb2321f1691d341a3ceb9d321cd01d506c8
>Could anyone confirm, that switching between 0 and biggish (200-600 KByte)
samples will inflict an unresponsive GUI?)
Felix would you please share the test script?
As a workaround, we might disable kerning for Java <17 by default.
It looks like we might need another RC for that.
Vladimir
Could you please try if text.kerning.max_document_size=1 in
jmeter.properties solves the issue?
Vladimir
>When i clique to display the resultat data (html boy) the JMeter is
>very slow to show the page.
>I need to wait 4 sec to 8 sec between click and the http sampler and
>the display in text format.
Vincent, do you think you could create a reproducer for the issue? (e.g.
share HTML contents)
Do you
Thanks for the RM.
+1 for release
Vladimir
I think we should merge https://github.com/apache/jmeter/pull/696 before we
release.
>I am wondering, if the new notice I placed at the end of the Readme would
be better placed in the notice file
NOTICE is highly sensitive to "legal stuff", so I would refrain from
modifying NOTICE unless there's
>Ok, where do you think would be a good place? changes.xml? NOTICE? README?
README sounds good.
Vladimir
>CC0 (http://creativecommons.org/publicdomain/zero/1.0/)
CC0 should be allowed. It looks like a bug in the license-gather plugin if
it marks CC0 as unknown.
>Indiana University Extreme! Lab Software License
They have #3 which requires an explicit mention in the documentation
or in the
>Cannot select module with conflict on capability
>'org.codehaus.groovy:groovy:4.0.0' also provided by
>[org.codehaus.groovy:groovy:3.0.0(runtime)]*
That means you have both Groovy 3 and Groovy 4 on the classpath which are
incompatible.
I think Groovy3 comes from Spock, so you need to update
>org.codehaus doesn't have Groovy 4.0.0 yet. Could you please advise?
Thanks!
Please check
https://groovy-lang.org/releasenotes/groovy-4.0.html#Groovy4.0-naming-changes
org.codehaus.groovy should be updated with org.apache.groovy
For instance, here:
Hi,
Judging by
https://groovy-lang.org/releasenotes/groovy-4.0.html#Groovy4.0-naming-changes
,
the change is not backward-compatible.
In other words, users' JMeter scripts might start failing for no apparent
reason.
So I would suggest:
a) Plan Groovy 4 for JMeter 6. It does not mean we postpone
>When I run ./gradlew test -Djmeter.use_java_regex=true, it seems to have
>more effect
I have no idea how it works now, however, there are three JVMs:
1) The first JVM evaluates the build script (it basically runs
build.gradle.kts, and it is the JVM that parses the build command-line)
2) The
We need to add a convention so launching Gradle with a property
`jmeter.property.key=value` would pass
`key=value` JMeter property (it should remove jmeter.property. prefix, and
the prefix is there to avoid ambiguity)
The relevant bits are here:
Hi,
Does anybody want to try adding mutation testing to JMeter codebase?
I mean add extra tests to verify existing JMeter tests.
Recently I noticed there's https://www.arcmutate.com/ effort by pitest team
They unlock running mutation testing for the pull requests,
so it sounds like a good plan
>That's a annoying if my understanding is correct, how do we distinguish
>reporters comments from dev/committers ones ?
Comments on GitHub would start with "${username} commented: ${comment}"
>Does it means bugzilla would still be up ? What is the point then ?
It will be read-only for
Unfortunately, infra says GitHub can't help us with the migration:
https://issues.apache.org/jira/browse/INFRA-22618
So what we can do is to follow
https://github.com/Quuxplusone/BugzillaToGithub
The downsides would be:
a) All comments will be authored by the "asf-git" (or a similar bot-like
Hi,
Currently, GitBox sends notifications on issues and pull requests to
dev@jmeter list.
It results in duplicate notifications (one from GitHub, and another one
from GitBox).
Does anyone really use GitBox notifications?
I believe GitHub's notifications are better as they are better formatted,
I've filed a PR for changelog update (added an obligatory log4j mention,
elaborated on open model, etc):
https://github.com/apache/jmeter/pull/684
Vladimir
[ ] +1 I support this release.
Thank you,
Vladimir
>I don't see mention of
>OpenModel Thread Group.
See
https://github.com/apache/jmeter/blob/610eeeb866b1fda23025787e70bf0a81d0e8740c/xdocs/changes.xml#L64
However, it does make sense to elaborate right in the release notes and
welcome users to try the new feature.
Vladimir
Hi,
Does anybody volunteer to release JMeter 5.5?
I can try releasing JMeter this time.
It is not that urgent, however, I believe 5.5 is long overdue.
For instance, there are important bugs fixed, and users start running
JMeter with Java 17 which was not supported before 5.5.
Vladimir
1 - 100 of 839 matches
Mail list logo
