I've merged Open Model Thread Group.
Thank you everybody for the review.
Vladimir
Hello,
I have the same position as Felix.
Regards
On Thu, Nov 25, 2021 at 10:07 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> Philippe. All,
>
> Are there blockers on including Kotlin for main and test code in JMeter?
>
> I proposed Kotlin-based implementation for
I would be OK with addition of Kotlin to the core, when we are certain
(and are on the same side that) JMeter will still be usable with
"normal" Java (that seems to be the case, as I read it)
But it is yet another language added to our growing list of languages
(Java, Groovy, Ant, Gradle, JS,
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
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
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
Hi,
>
*Vincent mentions the pacing feature, however, I believe it is really
reallyclose to my current proposal as well.For instance, "pacing of 1 min"
means exactly the same as configuring "1request per minute".In other words,
if you configure the new thread group to "1 request perminute",
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
I think, that current Thread Group is natively more closed model than open.
To make it more open-friendly the "delay thread creation" is usable but it
is not perfect solution. This Thread Group has no any build in feature to
create changing (in time) load characteristics.
Thread Group which is
Hi
In my opinion, we need to keep the old thread group to allow us to simulate
open and closed models and because some time we need to simulate X users
and not only X action.
About Kotlin, I don't have an opinion.
Le dim. 7 nov. 2021 à 18:16, Vincent Daburon a écrit :
> Hi,
> For me JMeter is
Hi,
For me JMeter is only in java for the main functionalities including
the groups of threads and I do not appreciate that we add kotlin
language to the project.
First line of the Jmeter overview : “ The Apache JMeter™ application
is open source software, a 100% pure Java application “
Adding
>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
Hello,
Why not call it « Open Model thread group » instead of precise throughput
thread group?
Precise is a bit weird as it would mean others are not.
Regards
On Sunday, November 7, 2021, Vladimir Sitnikov
wrote:
> Mariusz>Vladimir, will your new thread group allow to simulate open system?
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
Hi,
Vladimir, will your new thread group allow to simulate open system? I think
about defining new request arrival at defined rate (or characteristic)
irrespectively of number of threads in system (and created by generator).
Something like described in: https://www.cs.cmu.edu/~bianca/nsdi06.pdf
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
Hi,
I was a bit silent on the last discussion, so I try to combine my
opinions on some of the points in this mail.
* Deprecating the "old" ThreadGroup.
I think the old ThreadGroup has a nice and simple interface, that can be
understood in a short time (my opinion :)). The new one should be as
>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
On Fri, Nov 5, 2021 at 9:18 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> Philippe>@All members, what do you think ?
>
> I guess this question is not only for committers, so don't hesitate to
> speak up.
>
For me, contributors opinion has the biggest weight .
But I am ok to see
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
On Fri, Nov 5, 2021 at 7:58 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> 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
>
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 understand that Kotlin is better for DSL, so I would suggest to restrict
Kotlin use to this part only unless there is a blocker in Java.
On Fri, Nov 5, 2021 at 12:24 AM Philippe Mouawad
wrote:
> Hello Vladimir,
>
> Thanks for the PR and work on it.
>
> I started looking at code, and I am
Hello Vladimir,
Thanks for the PR and work on it.
I started looking at code, and I am wondering if there is a particular
reason for not using Java for the new development ?
I must say I am not comfortable with mixing Java and Kotlin in the project.
I have reduced my activity on project these
Hi Vladimir,
It looks good, I will test it asap
Do you plan to add a feature to load/save events fired time (seed) to have
exactly the same repeatable sequence for each test execution?
Le dim. 31 oct. 2021 à 21:01, Vladimir Sitnikov
a écrit :
> I wanted to add a chart with "desired load
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
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,
Vladimir, Do you want to fix Precise Throughput Timer or make Thread Group
more flexible (to simulate open and closed system without plugins)?
As I understand it may break old test plans (jmx files).
Regards,
Mariusz
On Thu, 14 Oct 2021 at 20:58, Vladimir Sitnikov
wrote:
> Hi,
>
> Some
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
32 matches
Mail list logo
