> Regarding the "Open Model Thread Group" component that was introduced in
> version 5.5, can you please explain how this component spins up threads in
> order to meet the rate requirements?
It launches threads according to the schedule.
Each thread executes its body only once.
> In particular,
I'm afraid the attachment was cut.
Do you think you could create a bug in Bugzilla
https://bz.apache.org/bugzilla/ and attach the test plan there?
Vladimir
@Milamber, would you please prepare a new JMeter 5.5 RC?
It looks like it is good to go.
Vladimir
>Any updates on this migration please? Thanks!
See https://lists.apache.org/thread/xt9n5tjb9h3lo1hplhyqmz7ctx8tto7l
I got 10 Bugzilla-GitHub pairs via the form above.
I've got not much progress though :-/
Vladimir
It looks like we wait for repository.apache.org -> Sonatype OSSRH sync.
Here's one of the artifacts:
https://repository.apache.org/#nexus-search;gav~org.apache.jmeter~ApacheJMeter_core~5.4.2~jar~
Vladimir
Dear All,
As you might know, Apache JMeter is working on migrating the data
that is currently residing in Bugzilla at https://bz.apache.org/bugzilla/
into
JMeter GitHub project repository. The ultimate goal is to make JMeter
Bugzilla
read-only and allow the use of GitHub issues and pull requests.
>Sadly the nashorn jars are Java 11+.
The default JavaScript engine is present till Java 14,
so I just thought we could use "in-JDK Nashorn" for Java 8..14, and the
external one in 15+.
I hope nashorn-core does not force us to use module path, however, I have
not explored it.
Does JMeter work
Felix>I am preparing a patch to update the Mozilla Rhino implementation in
Felix>JMeter to the current one (1.7.13)
An alternative option is to bundle https://github.com/openjdk/nashorn
The jar is 2.5 MiB:
https://repo1.maven.org/maven2/org/openjdk/nashorn/nashorn-core/15.3/
One more option is
>NVM, this is really not a jmeter question
Good luck with figuring out the details :)
You might try https://sdkman.io/ as it has up-to-date Java distributions
from different vendors.
Vladimir
Hi,
Have you tried ./gradlew runGui ?
An alternative option is to use ./gradlew createDist which would copy all
the dependencies, so you could launch JMeter with bin/jmeter.
Please find the commands at
https://jmeter.apache.org/usermanual/jmeter_tutorial.html#building
Vladimir
Hi,
Could you share a test plan to reproduce the issue?
Vladimir
Hi,
I see the following options:
a) Add support for GraalJS to JMeter. GraalJS is a standalone library that
evaluates JavaScript (of course, it works faster with GraalJS JIT compiler,
however it should work with any JVM)
b) Use Nashorn as a standalone library. It looks like there are people
>You can keep the date, but other Apache products as tomcat and spark use
build date as files' date
What is the issue with fixed timestamps?
I strongly believe that reproducible builds are more important than updated
timestamps in the archives.
So if you want both reproducibility and timestamps,
Felix>Plus, it probably is set that way by default to enable reproducible
Felix>builds. The timestamp is the same no matter where or when it was
build.
The timestamps are constants for build reproducibility indeed.
One can download source files (e.g. source release artifacts),
build it and the
>Also, I would request you to review others open points as well, which I
listed below.
You raise valid points, however, it is hard to review since you've provided
just a short summary.
If you are interested in improving Apache JMeter, I would recommend create
multiple discussions on the dev
Rahul, have you seen https://github.com/apache/jmeter/pull/499 ?
Is your suggestion different? Is it the same?
Vladimir
16 matches
Mail list logo
