>So I am happy you agree to say that it involves PMC, whatever the time it
>takes.
If PMC can't allocate a minimal time for the release, they SHOULD be willing
to transfer rights to the people who have more time.
>If I may correct your formulation
My formulation is:
If somebody chimes in and
>To be a release manager , you need committer rights no ?
No idea. It does not matter though. The contributor can do
the heavy-lifting of composing the changelog, etc, etc.
Of course, there will be some work on PMC to formally vote, build from
sources, etc.
However, I believe it is not really
>Now regarding a fix to jmeter 1 or 2, well it’s your opinion as of now
Philippe,
Supposed someone chimes in and suggest releasing JMeter 3.x
with log4j fixed. Suppose they would be open to do 90% of all the
heavy-lifting.
For instance, they might suggest a PR to make JMeter 3 buildable, they
>so it’s really a straw man argument.
Please. Log4j 1.x -> 2.x upgrade is no way seamless.
I know lots of apps that do not need 2.x features, and that can't upgrade.
That is they are stuck with 1.x.
>There is nothing stopping people from forking log4j and using their own
fork
A fork under
>People have had nearly a decade
... to remove COBOL from their apps.
Seamless migration does not exist yet, and people have large apps that
can't really be upgraded that easily.
They would rather fork log4j and use their own fork.
>This is more akin to asking the JMeter team to support JMeter 2
>would you be happy
>to see our users abandon JMeter because a CVE is discovered
>but it can happen to any
>project (logback also had one although less impacting)
Consider a case:
1. A critical vulnerability is discovered in JMeter 3.0 (e.g. remote code
execution via HTTP client)
2. Multiple
Hi,
What do you think of replacing log4j2 with logback?
Even though it might sound like an over-reaction,
I believe it is the net positive thing.
The reasons are:
* log4j2 has lots of features, and we do not really need them
* lots of log4j2 are in-core, so a breach in one of them impacts the
Thank you.
I've no idea why I can't comment on wiki.
Frankly speaking, I would love to minimize the manual steps, and it looks
like there are a lot of them left.
> do not update the version in build.xml yet; master branch should remain a
SNAPSHOT
This should probably be removed.
>Clean the
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.
I'm inclined to "Bugzilla -> Gitlab -> GitHub" approach, so I asked INFRA
if they can help with requesting GitHub support:
https://issues.apache.org/jira/browse/INFRA-22618
Does anybody want to try https://github.com/llvm/bugzilla2gitlab/tree/llvm
with JMeter's Bugzilla?
Gitlab could probably be
Thank you Milamber
+1
The release looks good to me.
Vladimir
I suggest naming the branch as release/5.4.x (or branch/5.4.x or
branch/5.4), so we can cut 5.4.x releases from it (e.g. in case more CVEs
are to be fixed)
Of course, it is not a show-stopper now, and we can create the branch later.
Having an explicit branch is helpful for creating PRs that
I think 5.5 is ready.
Vladimir
>Are you planning on chaning the entire engine to use co-routines?
It is not really that hard to switch the engine from threads to Kotlin
coroutines:
https://github.com/apache/jmeter/pull/540
The complicated part is to find a good HTTP client that can simulate lots
of clients.
For instance, last
@Milamber, do you think you could prepare JMeter 5.5 release?
Vladimir
It looks like LLVM migration to GitHub is done.
The approach is described in
https://groups.google.com/g/llvm-dev/c/vum4_czZ13E/m/o4kxxOgQCAAJ
What they did was they migrated Bugzilla -> Gitlab, and then they used
GitHub Enterprise Migration API to migrate from Gitlab dump to GitHub.
Gitlab
Please check
https://repository.apache.org/content/repositories/snapshots/org/apache/jmeter/
https://jmeter.apache.org/nightly.html
Vladimir
>test plan can
>be run in different envs with different jmeter installation paths
Do you think relative path is a viable solution?
An alternative option is to have "library paths" JMeter propery, so it
would lookup libraries in the given set of paths.
When it comes to the UI, I would love to
>Gotcha, thanks for clarifying - then it might absolutely be an
>alternative solution.
In practice, there's not much difference overall :)
However, many programming languages have the concept of "exporting and
importing symbols" (e.g. import ... in Java),
so JMeter might be good to borrow the
> However, it doesn't seem to not be an optimal solution for
the case when I have 20+ "libraries" with a certain level of depth
each having multiple nested modules/elements that also can reference
I think there's misunderstanding.
I don't suggest copying the trees at import time.
I suggest that
Lena>a decent reason why it was not implemented over all these years?
I guess the reason is nobody invested time to make it happen.
Lena>I am in a strong need of having a Controller that allows to choose a
Lena>certain module from an external file, something like a hybrid of
Module and
>Another question regarding CI, I see tarvis, github action and Jenkins are
used in Jmeter. What is the main CI ?
It is complicated. All of them add value.
I would inline to GitHub Actions, however, we can't drop all Travis and all
Jenkins jobs.
There's https://github.com/renovatebot/renovate
So 6.0 is:
* http 2
* with coroutine-based async samplers
* and programmatic test plan generation
* built with Java 17
* distributed as jlink images
* with UI based on Compose Multiplatform
It sounds cool, and the question is who implements all the features :)
Frankly speaking, I see no reasons
>I would be fine with both versions 5.5 and 6.0.
Same for me.
I am limited in time :-/, so I would not be able to rename 5.5 -> 6.0,
so I would suggest releasing as 5.5, and going for 6.0 a bit later.
I thought I could work on DSL this December, however, it turns out not to
be the case.
>and
Hi,
Vincent suggested an interesting idea: release the upcoming version as
JMeter 6.0.
See
https://github.com/apache/jmeter/commit/417846471d320c5d18bfec899b8518276c8a9574#commitcomment-61294792
WDYT?
Initially, I did not think "a new component" might qualify for 5.x -> 6.0
version change
I've merged Open Model Thread Group.
Thank you everybody for the review.
Vladimir
Just in case, LLVM is migrating issues from Bugzilla to GitHub Issues:
https://llvm.discourse.group/t/bugzilla-migration/4848
I guess we could approach the LLVM team after they migrate.
They collected GitHub ids via Google form.
Basically, they asked to submit their "email -> github login" pairs,
>wrapper registry
I think wrapper is just a single case, and it is unlikely "wrapper
registry" would be reused in the future.
Test plan transformations will likely be on a case-by-case basis.
>that might come to a curious mind.
Let me put it this way: expression transformation is a very common
>Because to check if a sampler is enabled at the moment of the execution i
>think it should be checked in GenericController, in the next method
If you wrap a component with "if controller", then ANY component (not sure
regarding pre/post processors) would get
dynamic support for free.
That is
>I have no idea, how TreeCloner works, so maybe a good idea
I do not know if you want to figure out the implementation on your own, or
if you need detailed instructions.
Here's the code that deals with isEnabled:
Anas,
Here's the failure message:
> Failures detected while testing
/mnt/Linux2T/work/anasoid/repo/jmeter/bin/testfiles/FTP_TESTS.jmx
Could you please try opening the test file in JMeter and see what that
script is doing?
In theory, you should be able to reproduce the failure when running the
>actually enable is used before test to
> filter component, and I think each case (listener, controller, sampler,
..)
>will be adapted especially to have this feature
Why do you think each component needs to treat "dynamic enable" differently?
Vladimir
Nice.
It looks like it might be worth trying GitHub issues.
>but what happens if at some step we have to leave github
INFRA team has scripts for importing GitHub history to ASF JIRA.
Any thoughts on the migration of the old issues?
Do we need to migrate comments from Bugzilla to GitHub
> The second variant would hide the expression text in the two static cases.
I thought behind those lines as well. It might be we could add a small
marker that
informs the user that checkbox is configurable.
I just attended a talk by
https://www.smashingmagazine.com/author/vitaly-friedman/
control explicitly, however,
having such control would make JMeter UI more consistent.
Vladimir
чт, 25 нояб. 2021 г. в 15:53, OUFDOU Anas :
> It's not clear for me what do you mean by generic solution??
>
> Can you detail more what you expect to have ?
>
> On Thu, Nov 25, 2021 at 12:15
>if any boolean or integer who doesn't support using the expression , i
think it should be corrected at component level like CSV dataset
JMeter should provide a solid foundation so other components can reuse and
extend core approaches.
This case has clear and generic solutions for the problems
Hi,
Does anybody have a strong opinion regarding Bugzilla vs JIRA vs GitHub
issues?
Frankly speaking, I am inclined to migrate to GitHub Issues or to the ASF
JIRA.
I have no strong opinion between JIRA vs GitHub Issues, however, the
current JMeter development workflow is pull-request centric,
>In my case I will add a new string value and keep the static enabled also
Is this "enabled" property any different from other properties like "number
of threads", "sleep delay", and so on?
Is this "enabled" property different than "follow redirects" property in
HTTP Sampler?
I would suggest
Hi,
That is great.
Do you think it duplicates
https://lists.apache.org/thread/1mplrt4bqd6h08kj38hkvxwy527nckpn ?
>Disable post processor (when extracting value from home page, there is
>no need to consume CPU with each iteration to get the same value )
Currently, JMeter ignores disabled
Hello,
Please prefer sending error messages as text (e.g. copy-paste from
terminal), as it makes the errors searchable.
For instance, https://lists.apache.org/list.html?dev@jmeter.apache.org is
not able to search for text in images.
What you see are flaky tests.
There are tests that use
Hi all,
This email calls for a vote to enable Github Discussion on Apache JMeter
repo.
*Intended Use*:
A forum for users, you might consider it as a replacement of
us...@jmeter.apache.org.
*Caveats*:
GitHub discussion is NOT to be used for anything other than user help. As
is the policy of the
>I think, we already use %{..} inside JMeter,
Just in case, Gatling team has recently moved to #{...} syntax as ${...}
caused issues with both Scala and Kotlin.
Vladimir
There will be a meetup related to JMeter DSL tomorrow: 24 November 11:30
UTC (see
https://github.com/anasoid/jmeter-as-code/issues/133#issuecomment-976332680
)
Feel free to join:
https://zoom.us/j/95780554945?pwd=MWtvYjlmc1dRREMzbWdsbmxSMk5MQT09
Vladimir
>Well, maybe we see use cases, when we see the first implementation of
>the generating function (`http`, `aggregateReport` in your example).
I've filed https://github.com/apache/jmeter/pull/678 to get
something started.
The relevant code is located in jmeterdsl.kt.
The immediate question is "how
>I would understand the
>declaration of a general variable, but (at the moment) not a special
>regex one
See
https://jmeter.apache.org/usermanual/component_reference.html#Regular_Expression_Extractor
Regular expression extractor sets and resets **several** variables.
I think variable names like
> Can the kotlin templating mechanism be switched off in that case?
Unfortunately, there's no way to switch it off yet.
The issue is known as https://youtrack.jetbrains.com/issue/KT-2425
>I don't understand it, can you give an example?
testPlan {
var orderId by variables.regex()
http {
> How do you see the DSL for plugins ?
The baseline is they would be able to integrate if they want. They would
have to code their DSL in Kotlin though.
>How will JSR223 custom code be used inside DSL ?
Suggestions are welcome. Kotlin has raw literals (~multiline strings), so
coding JSR223 as a
It is better now.
Frankly speaking I do not know how to deal with separator, and with array
vs List in the API.
In most cases, Lists are more pleasant to work from Java.
However, I would not die on that hill.
Vladimir
Vladimir> I've idea what would work the best to resolve it.
Fix: I've *no* idea what would work :)
Vladimir
>The annotations could be used for scanning for TestPlan elements on
startup, too.
I remember we have discussed it, however, it sounds like a different
feature.
Of course, some level of code generation might help, however, I have no use
cases for it now.
>Maybe start with a global
>Do you have a rough idea, what the dsl would look like, or how the
>elements get mapped/detected to be a part of the dsl?
Commonly used elements have to be mapped manually for consistency reasons.
There might be a generic (string-like) approach to allow fine-tuning.
>Could you elaborate a bit
>I think it's important to slowly isolate the Jmeter core from GUI,
If anybody wants to contribute that, please do so.
Antonio>I think it's a good idea to add DSL in core is a good idea
The immediate question is do we put classes for DSL right into the
current ApacheJMeter_core,
Hi,
Is there a way to disable a component (e.g. thread group, listener) from a
command line?
What do you think if we add a way to configure element disabling with a
regular JMeter property?
The related question is making "checkbox" UI elements configurable.
For text fields, we often support
I think the code is ready for review and merge.
I am inclined to rename the controller to "Open Model Requests" (see below)
* validation mode works now for openmodel
* unit tests for schedule generators are there
* even_arrivals is supported as well (for both constant and
increasing/decreasing
I see,
+1 for unifying the properties.
I don't quite like the naming of the fields:
String CIPHER_SUITE_LIST becomes String[] SUPPORTED_CIPHER_LIST after
split(" ").
The names are not that important as the fields are private (which is good),
however, it is really hard to follow which property
>What do you mean ?
https://www.jetbrains.com/help/idea/project-security.html#open_first_time
>Maybe you can share this configuration in the document.
I think we could even share the configuration via .idea/... file (see
Philippe>1) Using IntelliJ IDEA 2021.2.3, I didn't get a popup to be able
to select:
Philippe> - Make sure Create separate module per source set is selected
Philippe> - Make sure Use default gradle wrapper is selected
Those steps indeed seem obsolete. I think nowadays the only question it
Felix>So, in a sense, it is being used. (No idea, if it is useful enough.
Has
Felix>it done its purpose and reminded you to edit both files at once?)
I find the nagging useless since FILEVERSION is the **only** thing that
everybody changes
when adding a new sampler :-/
If other modifications are
Upd:
I've added the relevant tests and CI now passes.
I've updated the build configuration, so the build now passes without
warnings with Gradle 7.3 and Java 17.
SecurityManager has been deprecated for removal, so we might need to drop
its use.
Vladimir
Hi,
I do not completely understand the use case, however, I support adding the
common property names
so different implementations could be configured in the same way.
So please file the PR with the property names and the supported values.
I don't understand what do you mean by
Hi,
I see that TestSaveService > testFILEVERSION fails on every update of
saveservice.properties.
What is the purpose of testFILEVERSION?
I suggest we just remove SaveService#FILEVERSION field as it is not really
used.
The failure looks as follows:
FAILURE 0.0sec,
I renamed the thread group to "Open Model Thread Group" as it seems to be
the best title among the suggestions.
I added code comments.
Review is welcome. I've no idea why GitHub CI hangs, and I have not
explored it yet.
So far there's a request from Philippe regarding Kotlin removal.
@Philippe,
Vincent>Usually I do not model the load in urls/sec but in full scenarios
(from
Vincent>login to logout) per hour in high activity.
Ah, it looks like you misunderstand my proposal.
The proposed "Precise Thread Group" measures workload rate in scenarios
rather than "URLs or samplers".
It does not
Mariusz>also discussion about JMeter threading model and constraints
Frankly speaking, this time I just implemented the thread group the way I
wanted, and I did zero research on the past requests.
Thanks for the links above, and I think they discuss the very similar
problem and I think Kirk would
>Why not call it « Open Model thread group » instead of precise throughput
>thread group?
Naming is hard, and I have no idea of the proper name. Suggestions are
welcome.
I used "precise thread group" just to pick a name and get the thing running.
I think "open model thread group" is not exactly
Mariusz>Vladimir, will your new thread group allow to simulate open system?
Currently, the code simulates an open model, and it does not limit the
number of threads it spawns.
Vladimir
Felix>I think the old ThreadGroup has a nice and simple interface, that can
be
Felix>understood in a short time (my opinion :))
Well, the old thread group easily configures "N threads", however, as soon
as you need to set the desired request rate you are out of luck :-)
One of the key questions
>I said that as scheduleParser.kt, scheduleTokenizer.kt are related to DSL,
>I am ok with them being in Kotlin.
Then it is a misunderstanding.
They implement a typical textbook regular-expression-based tokenizer and
parser.
The files have nothing to do with Kotlin DSL for programmatic test plan
Philippe>@All members, what do you think ?
I guess this question is not only for committers, so don't hesitate to
speak up.
Philippe>Maybe but in the current active members of the team how many are
as good
Philippe>in Kotlin as in Java ?
Frankly speaking, I do not think that is the right
I do not think there are blockers, however:
a) I use lets-plot for charting which is Kotlin library. I was not able to
find a Java library (JFreeCharts license is not compatible with the ASF
requirements)
Frankly speaking, the chart was the last feature I added, and it was more
of a coincidence.
I wanted to add a chart with "desired load profile", and I found
https://github.com/JetBrains/lets-plot charting library.
The screenshot is in the PR
It adds some jars to the distribution, however, I think it would be hard to
find another library.
The unfortunate consequence is that UI
I got the first bits working:
https://github.com/apache/jmeter/pull/674#issuecomment-955579290
It creates threads according to the schedule
Comments are welcome.
Vladimir
Up
Apparently, text-based JMeter script generation is used in the wild,
however, the perception is that JMeter is GUI-only :(
What do you think if we add in-core Kotlin-based DSL?
Vladimir
Hi,
What do you think if we add samples/* directory under the source control to
show samples for frequently asked cases?
Here's a similar case in Gradle documentation: [1]
For instance:
* gradle-kotlin-lib: Gradle-based project that builds a library and uses it
within JSR223 sampler
*
Philippe>But I would keep Thread Group as is for the following reasons:
Thanks for the corner cases, and I think I cover all of them
> - Backward compatibility although I see you propose a solution
Yes, the old group stays "forever" and we just deprecate it (e.g. mark as
deprecated and
>make Thread Group
more flexible (to simulate open and closed system without plugins)
This
>I understand it may break old test plans (jmx files)
The new group can be implemented in a completely new class file, and the
current test group could be deprecated (e.g. renamed to "old thread group"
in
Hi,
Some time back I contributed "Precise Throughput Timer" which enables uses
to throttle requests to a certain throughput (see [1])
It works, however, there are issues with that approach:
a) It is not that easy to configure the thread group. Default thread group
creates threads on regular
I wonder why all those plugins depend on LoggingManager.
Given the number of usages, we would have to keep the class forever, so we
might want to add the related javadoc.
If the third-party plugins use the class for logging purposes, then we
might even want to heal the class (e.g. divert all the
Philippe>It is broken for me as it generates broken .classpath files.
Have you tried File → Import... -> Existing Gradle project ?
I'm not sure if "gradlew eclipse" works, however, I know "gradlew idea" has
been deprecated long ago (by both Gradle and IDEA).
Felix>I have another problem with the
>Could be named isConsumable and isResolvable
That is Gradle public API, so I can't influence the naming:
https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/Configuration.html#isCanBeConsumed--
I agree it sounds weird.
isCanBeConsumed / isCanBeResolved have been added long ago, and
Many thanks for migrating the jobs.
Vladimir
+1 for moving at least the analysis to Java 11.
I wonder what if we require Java 11 for JMeter execution?
For instance, Java 11 is a requirement for
https://github.com/kirill-grouchnikov/radiance LaF
Vladimir
>Sha512 plus the rest of links on page with explicit version information
>would avoid this
As I said, adding jmeter-latest.zip creates more issues than it solves.
Can you please provide a page that looks like what you mean?
What is the software that lists -latest.zip for the download link?
Philippe>Do you think that providing a stable name for latest version of
JMeter
Philippe>(without version suffix) would be useful ?
Can you please clarify?
Do you mean something like https://host/path/apache-jmeter-latest.zip ?
It would hurt reproducibility. The issue would be like "it worked
>But it does not seem to work.
There are two issues:
1) You should use TESTSTART.MS rather than START.MS which is "JMeter start
time"
2) JMeter's execution model does not have room for "reducing timer delay on
the fly".
The current engine asks the timer for the "pause duration", then it pauses
>- Step 1 : X req/s
>- Step 2 : Y req/s
>- Step 3 : Y req/s
>I am not sure it is feasible with PTT.
It should be feasible if a variable is used in PTT throughput.
Vladimir
Hi,
Gunar>It appears that only colleagues using our public NAT IP 217.10.52.10
have these issues.
Gunar>Is our IP 217.10.52.10 blocked on your server?
I guess the limits are here: https://infra.apache.org/infra-ban.html
The suggested communication is us...@infra.apache.org or asfinfra Slack
>for compute by groovy code the pacing
I'm afraid I don't follow you here.
Can you please clarify why the current Precise Throughput Timer does not
work for your "pacing" scenario?
Vladimir
Image test :
[image: schema_pacing_4_iter_v3.png]
Vladimir
Vincent,
I'm not sure why do you call it pacing, but what you draw is exactly what
JMeter's Precise Throughput Timer is doing.
If you place the timer under a "flow control action" which is before
sampler1, then the timer would delay the theads that come to early.
Have you tried it?
Does it work
>How skip the autostyle check ?
Please use -PskipAutostyle
An alternative option is to download the sources via git clone ...
Or execute ./gradlew autostyleApply (from within buildSrc directory first)
to fix line endings.
Vladimir
>[image: schema_pacing_v1.png]
Unfortunately, the images are not yet enabled in this mailing list.
I've filed https://issues.apache.org/jira/browse/INFRA-20125 to fix that.
Could you please upload the image to gist.github.com or something like that
in the mean time?
Vladimir
Philippe>- you don’t have a requirement of number of execution per minute
How do you compute "pacing" then? :)
I guess you almost always have something on the number of scenarios per
hour :)
Philippe>How do you avoid a burst in the first steps (the one before
failure) of
Philippe>your scenario
Hi,
>For 3 years I have been using the notion of Pacing an iteration to
>facilitate the modeling of the load and also because it is very practical
>when we are doing loads with load steps
Can you please clarify how pacing makes it practical?
For instance, I have never faced a case when the
Philippe>I don't know. But AFAIK, every time people attach files or
screenshot to
Philippe>our mailing list and we get nothing, so we need to ask again and
use 3rd
Philippe>parties
The lack of images is indeed painful for JMeter.
Vladimir>Can attachments be allowed
Here's a case when they ask
Philippe>I would add those 2:
Philippe> - org.codehaus.groovy:groovy-templates :
Philippe>
https://docs.groovy-lang.org/docs/next/html/documentation/template-engines.html
Philippe> - org.codehaus.groovy:groovy-xml : XmlSlurper
The libraries were on my list as well:
Vladimir> How about
>3) What about upgrade to groovy ? Do we skip it for this release ?
Let's update to Groovy 3.
>2) I upgraded some dependencies, but github is facing an incident so we
>didn't get the mail
Thanks.
I suggest we stop adding lines like "Updated equalsverifier to 3.1.9 (from
3.1.12)" to
>I didn't have opportunity to review it more deeply or test it on real life
>case.
Same for me :-(
>Should we request users to test it and give feedback ?
>I have seen 2 or 3 very interested.
My understanding is we have a chicken and egg problem here.
JMeter releases are very rare, so features
Alexander> What about auto-correlation
https://github.com/apache/jmeter/pull/499 ?
Do you think it is ready for merge as is?
Vladimir
>if the work about improve UX is done
There's always room for UX, however, the further improvements might come
with upcoming versions.
For instance, upcoming Darklaf would have high contrast theme, and it would
support OS notifications for UI preferences (e.g. switch JMeter between
light-dark as
101 - 200 of 839 matches
Mail list logo
