Re: Java 21 Virtual Threads benefit for JMeter

[Philippe Mouawad]

On Tue, Jan 16, 2024 at 7:41 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >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.
>

That's not my understanding of what Virtual Threads provide:

   -
   
https://www.theserverside.com/tip/A-primer-on-Java-21-virtual-threads-with-examples


> It might produce hype, however, I doubt it would produce significant gains
>

My understanding is that Virtual Threads brings the benefit of async
without its complexity (
https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html#GUID-B163BC51-039B-43BD-87ED-27BE384B509D)
through the use of Continuation.

When running a test, JMeter threads are frequently waiting for IO so they
would highly benefit from this, so from a theoretical perspective I don't
understand this argument.

Besides, it didn't look that hard to benefit from this, as we need to:

   - Change create of Threads to Virtual Threads
   - replace synchronized with Read/Write Lock
   - Possibly replace where possible the use of Thread Local for expensive
   objects
   - Replace for Parallel Download which uses a Thread Pool by Semaphore


Not sure we would still need to switch to Async HTTP Client.


> except for
> "ok, you might help OpenJDK team to test Virtual Thread implementation by
> trying JMeter with Virtual Threads".
>

I have nothing against helping OpenJDK team if it also helps JMeter getting
more scalable.


> The major memory consumption would still be caused by JMeter's approach of
> test plan cloning.
>

Maybe it won't help on memory side, but it will help on CPU side and
increase scalability.


> In our cases, HTTP Header Manager cloning virtually kills us: JMeter
> recorder creates HTTP Header Managers for every HTTP sampler,
> and every manager consumes **a lot** of memory since every header is stored
> in JMeter's quite sparse "JMeterProperty -> Arguments -> name -> value".
> See https://github.com/apache/jmeter/pull/727
>
> At the same time, we can't easily mark all HTTP Header Managers as "safe
> for reuse across threads" since there might be cases when the JMX uses
> JSR223
> to access and modify HTTP Header Manager properties **during test
> execution**.
>
> >ended with a  PR from Vladimir using Kotlin Co-Routines which
> >never got merged.
>
> The key reasons the PR was not merged are:
>
> a) Lack of relevant testing. I never got use cases when a new approach
> would be needed.
> The much more needed feature in that regard is "concurrency limiter" (see
> https://github.com/apache/jmeter/issues/5966).
>
> b) A major part of the change (see
> https://github.com/apache/jmeter/pull/540)
> was to **add** support for non-blocking HTTP clients:
> Apache HTTP5 Async client and Jetty async client.
> Unfortunately, the clients did not play well with the load testing we
> needed.
>
> What we need is to be able to simulate the load generated by **multiple**
> clients each having their cookies, connection pool, source IP address, and
> so on.
> Unfortunately, as I attempted various HTTP clients, almost all of them
> created **a thread pool of 8+ threads** for **each new HTTP client**.
> For a typical application, having one thread pool of 8 threads for all HTTP
> communication is fine, however, JMeter wants to have
> "HTTP client per virtual user", so we can't afford "a thread pool per
> virtual user" :)
>
> Things might have changed since then, however, that limitation was
> significant then.
> I have not tried
> https://apple.github.io/servicetalk//servicetalk/0.33/index.html yet
>
> Vladimir
>


-- 
Cordialement.
Philippe Mouawad.

Java 21 Virtual Threads benefit for JMeter

[Philippe Mouawad]

Hello,

Few months ago, we discussed the potential benefits of Project Loom, the
discussion ended with a  PR from Vladimir using Kotlin Co-Routines which
never got merged.

Now java 21 has integrated Virtual Threads , isn't it the time to use it,
knowing me may have to refactor some piece of code to exploit completely
the feature:
https://docs.oracle.com/en/java/javase/21/core/virtual-threads
.html#GUID-8AEDDBE6-F783-4D77-8786-AC5A79F517C0

To stay compatible with previous Java version, we could use Reflection to
create Virtual Threads only if we are on Java >= 21.

WDYT ?

-- 

PS: Aucune réponse n’est requise pour ce mail en dehors de votre temps de
travail

Cordialement
Philippe M.
Ubik-Ingenierie

Re: (jmeter) branch master updated: chore: set next version to 6.0.0

[Philippe Mouawad]

Hello,
Fine for me.
Regards

On Tue, Jan 9, 2024 at 7:03 PM Milamber  wrote:

>
> No special issue to have 3 digits, just want keep same logic as other
> JMeter major release.
> If PMC members are agree with 3 digits, I am ok too.
>
>
> On 09/01/2024 18:21, Vladimir Sitnikov wrote:
> > semver suggests always using three components (e.g. see 2.0.0 at
> semver.org)
> >
> > WDYT?
> >
> > Vladimir
> >
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.6.3 RC2

[Philippe Mouawad]

Hello,
Thanks for the work on this release !

[x] +1 I support this release (binding)



Regards.
Philippe M.




Le ven. 5 janv. 2024 à 18:57, Felix Schumacher <
felix.schumac...@internetallee.de> a écrit :

>
> Am 02.01.24 um 17:17 schrieb Milamber:
>
>  Hello,
>
> The second release candidate for JMeter 5.6.3 (34a2785748) has been
> prepared, and your votes are solicited.
>
> JMeter is a Java desktop application designed to load test functional
> behavior and measure performance. The current version targets Java 8+
>
> This release restored binary API compatibility with pre-5.6.2, and bring
> some fixes.
>
> Please, test this release candidate (with load tests and/or functional
> tests) using Java 8+ on Linux/Windows/macOS, especially on the changes.
> Feedback is very welcome.
>
> You can read the New and Noteworthy section to see improvements and full
> list of changes at:
> https://apache.github.io/jmeter-site-preview/site/changes.html
>
> Download - Archives/hashes/sigs:
> https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-5.6.3-rc2
> (dist revision 66387)
>
> RAT report:
> https://apache.github.io/jmeter-site-preview/rat/
>
> SHA512 hashes of archives for this vote: see footnote [1]
>
> Site preview is here:
> https://apache.github.io/jmeter-site-preview/site/
>
> JavaDoc API preview is here:
> https://apache.github.io/jmeter-site-preview/site/api/
>
> Maven staging repository is accessible here:
>
> https://repository.apache.org/content/repositories/orgapachejmeter-1089/org/apache/jmeter/
>
> Tag:
> https://github.com/apache/jmeter/releases/tag/v5.6.3-rc2
>
> Keys are here:
> https://www.apache.org/dist/jmeter/KEYS
>
> N.B.
> To create the distribution and test JMeter: "./gradlew build -Prelease
> -PskipSign".
>
> JMeter 5.6.3 requires Java 8 or later to run. *But, now JMeter 5.6.3
> requires Java 17 or later to build binaries.*
>
> The artifacts were built with
>   Java(TM) SE Runtime Environment Oracle Corporation (build
> 17.0.9+11-LTS-201)
>   Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build
> 17.0.9+11-LTS-201, mixed mode, sharing)
>
> Some known issues and incompatible changes are listed on changes page.
>
> https://apache.github.io/jmeter-site-preview/site/changes.html#Known%20problems%20and%20workarounds
>
> All feedback and vote are welcome.
>
> [x] +1 I support this release
> [ ] +0 I am OK with this release
> [ ] -0 OK, but
> [ ] -1 I do not support this release (please indicate why)
>
> The vote will remain open for at least 72 hours.
>
> The PMC members please indicate the mention "(binding)" with your vote.
>
> +1
>
> Thanks for doing all the work
>
> Felix (binding)
>
>
>
> Note: If the vote passes, the intention is to release the archive files
> and rename the RC tag as the release tag.
>
> Thanks in advance!
>
> Milamber
>
> ===
> [1] SHA512 hashes of archives for this vote:
>
> 5978a1a35edb5a7d428e270564ff49d2b1b257a65e17a759d259a9283fc17093e522fe46f474a043864aea6910683486340706d745fcdf3db1505fd71e689083
>
> *apache-jmeter-5.6.3.tgz
> 387fadca903ee0aa30e3f2115fdfedb3898b102e6b9fe7cc3942703094bd2e65b235df2b0c6d0d3248e74c9a7950a36e42625fd74425368342c12e40b0163076
>
> *apache-jmeter-5.6.3.zip
> e00a9e6fea279c5f40217638fdb9304fa67459dc1c39ae4c1cc4deaade56ab40e696c1cfb3b8996e6e8f5b849a1edb2579bbcc4b5ba2c3c342f56eee6d459076
>
> *apache-jmeter-5.6.3_src.tgz
> 90faa94a3b266fa3441594ef69de61a6e438d74f73eb2b3974d4a98582f622671ff4f8f7cd59d5390cc59f64816ff3aad3cad133e8ed5e5d3b753a1e6682d6b0
>
> *apache-jmeter-5.6.3_src.zip
>
>
>
>
>
>
>
>
>
>
>

Re: [VOTE] Release JMeter 5.6.3 RC1

[Philippe Mouawad]

Hello,
Thanks to the team for the work on this version.


On Mac OSX 12.1, version Java 21, I noticed  a major regression compared to
5.6.2 that seems blocker to me.

Scenario:
Create a new Test Plan
Add a Thread Group and add an HTTP Request Sampler to it
On Thread Group
check specify Thread Lifetime
Set duration to 300
Set startup delay to 1
go to another element
go back to Thread Group all settings are lost

Regards

On Sun, Dec 31, 2023 at 6:36 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> +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 issues as we bump the required Java to 17.
>
> Vladimir
>


-- 

PS: Aucune réponse n’est requise pour ce mail en dehors de votre temps de
travail

Cordialement
Philippe M.
Ubik-Ingenierie

Re: [VOTE] Release JMeter 5.6.3 RC1

[Philippe Mouawad]

Hello,
Happy new year 2024 and best wishes to all the team !

Regards

On Mon, Jan 1, 2024 at 10:27 AM Philippe Mouawad <
p.moua...@ubik-ingenierie.com> wrote:

> Hello,
> Thanks to the team for the work on this version.
>
>
> On Mac OSX 12.1, version Java 21, I noticed  a major regression compared
> to 5.6.2 that seems blocker to me.
>
> Scenario:
> Create a new Test Plan
> Add a Thread Group and add an HTTP Request Sampler to it
> On Thread Group
> check specify Thread Lifetime
> Set duration to 300
> Set startup delay to 1
> go to another element
> go back to Thread Group all settings are lost
>
> Regards
>
> On Sun, Dec 31, 2023 at 6:36 PM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
>> +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 issues as we bump the required Java to 17.
>>
>> Vladimir
>>
>
>
> --
>
> PS: Aucune réponse n’est requise pour ce mail en dehors de votre temps de
> travail
>
> Cordialement
> Philippe M.
> Ubik-Ingenierie
>


-- 

PS: Aucune réponse n’est requise pour ce mail en dehors de votre temps de
travail

Cordialement
Philippe M.
Ubik-Ingenierie

Re: Require Java 17 in JMeter 6

[Philippe Mouawad]

Hello,
Ok by me, good idea

Regarde

Le ven. 1 déc. 2023 à 13:10, Felix Schumacher <
felix.schumac...@internetallee.de> a écrit :

>
>
> Am 1. Dezember 2023 12:01:57 MEZ schrieb Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com>:
> >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 JMeter with Java 17+ already (e.g. due to security and
> >performance reasons),
> >and upgrading Java would probably fix many Swing problems.
> >
> >Any thoughts on this?
>
> I think it is great to move forward.
>
> Felix
>
> >
> >Vladimir
>

Re: JMeter 5.6.1 release plan

[Philippe Mouawad]

Hello,
Few notes below
Regards

On Thu, Jun 29, 2023 at 9:19 AM Milamber  wrote:

> Hi,
>
> Can you confirm that these issues are included:
>
> * improvement on JavaFX missing error message when java 9+?
> * fix for exception on http2 plugin
>
Vladimir explained the problem, it's more in the plugin code than in JMeter

> * losing SampleResults on interruption
>
 Although theorically I thought it would happen,  I was not able to create
a reproducer so not sure if it should be considered an issue

>
> If yes, I can start a new RC.
>
> Milamber
>
> On 28/06/2023 16:44, Vladimir Sitnikov wrote:
> > 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 based on an
> > outdated RFC.
> > The current browsers use UTF-8 by default for encoding the data, and if
> the
> > filename can't be encoded, Chrome uses HTML entities.
> >
> > I suggest we go for UTF-8 by default, since, well, the browsers do that,
> > and Java 18+ uses UTF-8 by default thanks to JEP 400.
> > The PR is https://github.com/apache/jmeter/pull/6010
> >
> > Any thoughts?
> >
> > The other improvements would be:
> > * Moving to Gradle JVM Toolchains, so we can use different JDKs for
> > building, testing, and executing Gradle (merged)
> > * CI testing with Java 21 (merged)
> > * bumping third-party patch versions (we can bump some patch versions
> from
> > https://github.com/apache/jmeter/issues/5823 )
> >
> > Vladimir
> >
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.6 RC1

[Philippe Mouawad]

Hello,

It is fine for me if 5.6 is released, it's not a struggle here.
Still l don't get the point of the vote if artifacts are published.

Vladimir, I am working on providing a reproducer, please be patient with me.

Thanks
Regards

On Fri, Jun 23, 2023 at 1:18 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> > 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 affirmatively for release, and there
> must be more positive than negative votes"
> Both conditions satisfied. We have three +1 from PMC members (Milamber,
> Vladimir, Antonio), and the number of positive votes is more than negative
> ones.
> 3) I do not think there are serious issues with 5.6 release
> 4) The jars have already propagated to Maven Central which is **outside**
> of the ASF reach:
> https://repo1.maven.org/maven2/org/apache/jmeter/ApacheJMeter_core/5.6/
> Somebody might have started using them, and if you convince Sonatype folks
> to remove 5.6 jars, you might break the build for those who use it already.
> 5) Philippe have not provided the reproducer test case, so I doubt we must
> trigger a rollback right away. Even if the issue is there, we could fix it
> in 5.6.1. There's no need to rollback in a hurry.
>
> Of course, it is up to the release manager, however, I would suggest you
> consider the above items (release voting rules, issue severity, and so on)
> once again and present your decision.
>
> Vladimir
>


-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.6 RC1

[Philippe Mouawad]

Hello,
My vote:
[-1] for the explained reason

Thanks for RM and all the work from Vladimir and Felix.
My answers inline below.

Regards

On Thu, Jun 22, 2023 at 10:59 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> > 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 shows that "interrupted" event is generated. If
> BackendListener loses events, it might be an issue in BackendListener code.
>
Since queue.offer is interrupted, the SampleResult is lost

>
> ---
>
> The change was a bug fix.
> Before the fix it was not possible to terminate (e.g. stop) a test if http
> sampler was waiting the response from server (e.g. if server was stuck)
>
This issue was always there due to missing timeout on HTTP Sampler no ?

>
> Note, that OMTG was already using java thread interrupt previously, and now
> the key change I made was **jmeter** thread interrupt (jmeterThread has its
> own interrupt method).
>
For me previously we Safe stopped the thread without interrupt.
Calling Interrupt introduces a regression in BackendListener which is a
component that is used a lot I think.



> It would be great if you could file an issue that describes the regression,
> however, if people need to wait some time at the end of the test, they can
> use `pause(2 min)`, so OMTG will wait for 2 min before interrupting
> samplers.
>
I'll do that

>
> We probably need something like `await_completion(5 min)` which would wait
> till all threads to complete 5 min maximum, and then interrupt them.
>
>
> Vladimir
>
> --
> Vladimir
>


-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.6 RC1

[Philippe Mouawad]

Hello,
I think there is a behavioural change related to this commit:

   -
   
https://github.com/apache/jmeter/commit/14986056c8b2441ebe4c2edafa996206073cb511

With the addition of interrupt, it seems to me we can end up losing
SampleResults in implementations of SampleLIstener when the interruption
occurs at end of test,
for example in BackendListener here, an InterruptedException will occur:

   -
   
https://github.com/apache/jmeter/blob/e024bf3703b9ca459fa531997d5874c9eaae8e36/src/components/src/main/java/org/apache/jmeter/visualizers/backend/BackendListener.java#L157


For me it's a regression

Regards

On Thu, Jun 22, 2023 at 9:45 PM Philippe Mouawad 
wrote:

> Hello,
> Can you give me few more hours ?
>
> I am currently testing the version , nice to see all this work and the new
> DSL.
> I have noticed a strange behaviour , I need to double check it, I am doing
> it now.
>
> Regards
>
> On Thu, Jun 22, 2023 at 7:47 PM Antonio Gomes Rodrigues 
> wrote:
>
>>  Here's my +1 (binding)
>>
>> Le jeu. 22 juin 2023 à 18:41, Antonio Gomes Rodrigues 
>> a
>> écrit :
>>
>> > I check something before
>> >
>> > Le jeu. 22 juin 2023, 18:07, Vladimir Sitnikov <
>> > sitnikov.vladi...@gmail.com> a écrit :
>> >
>> >> > Need 2 bindings (PMC member so)
>> >>
>> >> Here's my +1 (binding):
>> >> https://lists.apache.org/thread/2wd8l8zy3lbqhhrlhxf446l56m0mg335
>> >> So only one more is needed for the release.
>> >>
>> >> Antonio? Felix? Philippe?
>> >>
>> >> Vladimir
>> >>
>> >
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.6 RC1

[Philippe Mouawad]

Hello,
Can you give me few more hours ?

I am currently testing the version , nice to see all this work and the new
DSL.
I have noticed a strange behaviour , I need to double check it, I am doing
it now.

Regards

On Thu, Jun 22, 2023 at 7:47 PM Antonio Gomes Rodrigues 
wrote:

>  Here's my +1 (binding)
>
> Le jeu. 22 juin 2023 à 18:41, Antonio Gomes Rodrigues  a
> écrit :
>
> > I check something before
> >
> > Le jeu. 22 juin 2023, 18:07, Vladimir Sitnikov <
> > sitnikov.vladi...@gmail.com> a écrit :
> >
> >> > Need 2 bindings (PMC member so)
> >>
> >> Here's my +1 (binding):
> >> https://lists.apache.org/thread/2wd8l8zy3lbqhhrlhxf446l56m0mg335
> >> So only one more is needed for the release.
> >>
> >> Antonio? Felix? Philippe?
> >>
> >> Vladimir
> >>
> >
>


-- 
Cordialement.
Philippe Mouawad.

Re: [GitHub] [jmeter] vlsi opened a new pull request, #727: Add NoThreadClone to HeaderManager to reduce heap utilization

[Philippe Mouawad]

Hello,
Are you sure this does not break existing plans that create Headers
dynamically ?

HeaderManager should not be shared.

Regards

On Monday, September 19, 2022, GitBox  wrote:

>
> vlsi opened a new pull request, #727:
> URL: https://github.com/apache/jmeter/pull/727
>
>## Motivation and Context
>
>HeaderManager consumes heap, and it looks it can be reused between
> threads.
>
>
>
> --
> 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: dev-unsubscr...@jmeter.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.5 RC1

[Philippe Mouawad]

Hello,
I submitted:
https://github.com/apache/jmeter/pull/709

Regards

On Sat, Apr 30, 2022 at 9:52 AM Philippe Mouawad 
wrote:

> Hello,
> I updated ticket.
>
> I don't promise I'll have time to revert commit, but I'll try this
> week-end.
>
> Thanks
> Regards
>
> On Fri, Apr 29, 2022 at 5:21 PM Bruno DEMION 
> wrote:
>
>> Hi Philippe,
>>
>> I don't reproduce the issue of bug 65885 on JMeter 5.3/5.4.2 (i ask a
>> simple test case on bugzilla)
>>
>> Can you revert the commit? we can try to fix the issue before a new RC
>> if we can find the solve in few days.
>>
>> Milamber
>>
>> On 28/04/2022 08:47, Philippe Mouawad wrote:
>> > Hello,
>> > I don't have a fix for now , I didn't look deeply but for now as we
>> don't
>> > have in CSV file the fact the "Ignore status" is set, I don't see how to
>> > fix it.
>> > Since it's a regression, I think we need to revert the change if nobody
>> has
>> > an idea, and start a new release.
>> >
>> > What do you think ?
>> >
>> > Regards
>> > Philippe
>> >
>> >
>> > On Thu, Apr 28, 2022 at 10:44 AM Milamber  wrote:
>> >
>> >> Hi Philippe,
>> >>
>> >> Need to cancel RC2 for have a fix (or a rollback)? or i continue with
>> >> the RC process?
>> >>
>> >> Milamber
>> >>
>> >> On 27/04/2022 11:23, Philippe Mouawad wrote:
>> >>> Hello,
>> >>> Sorry for late reply @Milamber <mailto:milambersp...@gmail.com> , I
>> >>> see you're releasing.
>> >>> I noticed a regression on Reporting that may be problematic, in the
>> >>> error tables, the assertion message takes precedence on error code
>> >>> which makes  analysis
>> >>> more complex.
>> >>>
>> >>> It's a regression introduced by
>> >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=65885.
>> >>> Only when ignore status is checked should this happen.
>> >>>
>> >>> Regards
>> >>>
>> >>> On Wed, Apr 27, 2022 at 10:13 AM Milamber > >>> <mailto:milam...@apache.org>> wrote:
>> >>>
>> >>>  Hi,
>> >>>
>> >>>  I will prepare the RC2 today
>> >>>
>> >>>  Milamber
>> >>>
>> >>>  On 23/04/2022 11:02, Felix Schumacher wrote:
>> >>>  >
>> >>>  > What about trying an RC2 of JMeter 5.5?
>> >>>  >
>> >>>  > I updated our dependencies and added a workaround for the UI
>> >>>  problem.
>> >>>  >
>> >>>  > Felix
>> >>>  >
>> >>>  > Am 18.03.22 um 17:35 schrieb Milamber:
>> >>>  >>
>> >>>  >>
>> >>>  >> Ready for RC2? (I think that no?)
>> >>>  >> cc @Vladimir
>> >>>  >>
>> >>>  >> On 16/03/2022 22:42, UBIK LOAD PACK Support wrote:
>> >>>  >>> Hello,
>> >>>  >>> Looks good to me.
>> >>>  >>> Let's do another RC with this.
>> >>>  >>> Regards
>> >>>  >>>
>> >>>  >>> On Wed, Mar 16, 2022 at 6:30 PM Vladimir Sitnikov <
>> >>>  >>> sitnikov.vladi...@gmail.com
>> >>>  <mailto:sitnikov.vladi...@gmail.com>> wrote:
>> >>>  >>>
>> >>>  >>>>> Could we make the setting java version dependant ?
>> >>>  >>>> By default, the setting would be commented in
>> jmeter.properties.
>> >>>  >>>> Then, the code would use the appropriate default value
>> >>>  according to
>> >>>  >>>> Java
>> >>>  >>>> version.
>> >>>  >>>>
>> >>>  >>>> So I suggest changing
>> >>>  >>>>
>> >>>  >>>>
>> >>>
>> >>
>> https://github.com/apache/jmeter/blob/53a992c8179f0f64fe1993df34bda6594856cf5e/src/jorphan/src/main/java/org/apache/jorphan/gui/ui/KerningOptimizer.java#L48
>> >>>  >>>>
>> >>&g

Re: [VOTE] Release JMeter 5.5 RC1

[Philippe Mouawad]

Hello,
I updated ticket.

I don't promise I'll have time to revert commit, but I'll try this week-end.

Thanks
Regards

On Fri, Apr 29, 2022 at 5:21 PM Bruno DEMION  wrote:

> Hi Philippe,
>
> I don't reproduce the issue of bug 65885 on JMeter 5.3/5.4.2 (i ask a
> simple test case on bugzilla)
>
> Can you revert the commit? we can try to fix the issue before a new RC
> if we can find the solve in few days.
>
> Milamber
>
> On 28/04/2022 08:47, Philippe Mouawad wrote:
> > Hello,
> > I don't have a fix for now , I didn't look deeply but for now as we don't
> > have in CSV file the fact the "Ignore status" is set, I don't see how to
> > fix it.
> > Since it's a regression, I think we need to revert the change if nobody
> has
> > an idea, and start a new release.
> >
> > What do you think ?
> >
> > Regards
> > Philippe
> >
> >
> > On Thu, Apr 28, 2022 at 10:44 AM Milamber  wrote:
> >
> >> Hi Philippe,
> >>
> >> Need to cancel RC2 for have a fix (or a rollback)? or i continue with
> >> the RC process?
> >>
> >> Milamber
> >>
> >> On 27/04/2022 11:23, Philippe Mouawad wrote:
> >>> Hello,
> >>> Sorry for late reply @Milamber <mailto:milambersp...@gmail.com> , I
> >>> see you're releasing.
> >>> I noticed a regression on Reporting that may be problematic, in the
> >>> error tables, the assertion message takes precedence on error code
> >>> which makes  analysis
> >>> more complex.
> >>>
> >>> It's a regression introduced by
> >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=65885.
> >>> Only when ignore status is checked should this happen.
> >>>
> >>> Regards
> >>>
> >>> On Wed, Apr 27, 2022 at 10:13 AM Milamber  >>> <mailto:milam...@apache.org>> wrote:
> >>>
> >>>  Hi,
> >>>
> >>>  I will prepare the RC2 today
> >>>
> >>>  Milamber
> >>>
> >>>  On 23/04/2022 11:02, Felix Schumacher wrote:
> >>>  >
> >>>  > What about trying an RC2 of JMeter 5.5?
> >>>  >
> >>>  > I updated our dependencies and added a workaround for the UI
> >>>  problem.
> >>>  >
> >>>  > Felix
> >>>  >
> >>>  > Am 18.03.22 um 17:35 schrieb Milamber:
> >>>  >>
> >>>  >>
> >>>  >> Ready for RC2? (I think that no?)
> >>>  >> cc @Vladimir
> >>>  >>
> >>>  >> On 16/03/2022 22:42, UBIK LOAD PACK Support wrote:
> >>>  >>> Hello,
> >>>  >>> Looks good to me.
> >>>  >>> Let's do another RC with this.
> >>>  >>> Regards
> >>>  >>>
> >>>  >>> On Wed, Mar 16, 2022 at 6:30 PM Vladimir Sitnikov <
> >>>  >>> sitnikov.vladi...@gmail.com
> >>>  <mailto:sitnikov.vladi...@gmail.com>> wrote:
> >>>  >>>
> >>>  >>>>> Could we make the setting java version dependant ?
> >>>  >>>> By default, the setting would be commented in
> jmeter.properties.
> >>>  >>>> Then, the code would use the appropriate default value
> >>>  according to
> >>>  >>>> Java
> >>>  >>>> version.
> >>>  >>>>
> >>>  >>>> So I suggest changing
> >>>  >>>>
> >>>  >>>>
> >>>
> >>
> https://github.com/apache/jmeter/blob/53a992c8179f0f64fe1993df34bda6594856cf5e/src/jorphan/src/main/java/org/apache/jorphan/gui/ui/KerningOptimizer.java#L48
> >>>  >>>>
> >>>  >>>>
> >>>  >>>> into something like maxLengthWithKerning = currentJava < 17 ?
> >>>  -1 :
> >>>  >>>> 1;
> >>>  >>>>
> >>>  >>>> Vladimir
> >>>  >>>>
> >>>  >>>>
> >>>  >>>> ср, 16 мар. 2022 г. в 20:25, Philippe Mouawad <
> >>>  >>>> p.moua...@ubik-ingenierie.com
> >>>  <

Re: [VOTE] Release JMeter 5.5 RC1

[Philippe Mouawad]

Hello,
I don't have a fix for now , I didn't look deeply but for now as we don't
have in CSV file the fact the "Ignore status" is set, I don't see how to
fix it.
Since it's a regression, I think we need to revert the change if nobody has
an idea, and start a new release.

What do you think ?

Regards
Philippe


On Thu, Apr 28, 2022 at 10:44 AM Milamber  wrote:

> Hi Philippe,
>
> Need to cancel RC2 for have a fix (or a rollback)? or i continue with
> the RC process?
>
> Milamber
>
> On 27/04/2022 11:23, Philippe Mouawad wrote:
> > Hello,
> > Sorry for late reply @Milamber <mailto:milambersp...@gmail.com> , I
> > see you're releasing.
> > I noticed a regression on Reporting that may be problematic, in the
> > error tables, the assertion message takes precedence on error code
> > which makes  analysis
> > more complex.
> >
> > It's a regression introduced by
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=65885.
> > Only when ignore status is checked should this happen.
> >
> > Regards
> >
> > On Wed, Apr 27, 2022 at 10:13 AM Milamber  > <mailto:milam...@apache.org>> wrote:
> >
> > Hi,
> >
> > I will prepare the RC2 today
> >
> > Milamber
> >
> > On 23/04/2022 11:02, Felix Schumacher wrote:
> > >
> > > What about trying an RC2 of JMeter 5.5?
> > >
> > > I updated our dependencies and added a workaround for the UI
> > problem.
> > >
> > > Felix
> > >
> > > Am 18.03.22 um 17:35 schrieb Milamber:
> > >>
> > >>
> > >> Ready for RC2? (I think that no?)
> > >> cc @Vladimir
> > >>
> > >> On 16/03/2022 22:42, UBIK LOAD PACK Support wrote:
> > >>> Hello,
> > >>> Looks good to me.
> > >>> Let's do another RC with this.
> > >>> Regards
> > >>>
> > >>> On Wed, Mar 16, 2022 at 6:30 PM Vladimir Sitnikov <
> > >>> sitnikov.vladi...@gmail.com
> > <mailto:sitnikov.vladi...@gmail.com>> wrote:
> > >>>
> > >>>>> Could we make the setting java version dependant ?
> > >>>> By default, the setting would be commented in jmeter.properties.
> > >>>> Then, the code would use the appropriate default value
> >     according to
> > >>>> Java
> > >>>> version.
> > >>>>
> > >>>> So I suggest changing
> > >>>>
> > >>>>
> >
> https://github.com/apache/jmeter/blob/53a992c8179f0f64fe1993df34bda6594856cf5e/src/jorphan/src/main/java/org/apache/jorphan/gui/ui/KerningOptimizer.java#L48
> >
> > >>>>
> > >>>>
> > >>>> into something like maxLengthWithKerning = currentJava < 17 ?
> > -1 :
> > >>>> 1;
> > >>>>
> > >>>> Vladimir
> > >>>>
> > >>>>
> > >>>> ср, 16 мар. 2022 г. в 20:25, Philippe Mouawad <
> > >>>> p.moua...@ubik-ingenierie.com
> > <mailto:p.moua...@ubik-ingenierie.com>
> > >>>>> :
> > >>>>> Could we make the setting java version dependant ?
> > >>>>> If it’s worth it as it will introduce additional config
> > complexity
> > >>>>>
> > >>>>> Regards
> > >>>>> On Wednesday, March 16, 2022, Vladimir Sitnikov <
> > >>>>> sitnikov.vladi...@gmail.com
> > <mailto:sitnikov.vladi...@gmail.com>>
> > >>>>> wrote:
> > >>>>>
> > >>>>>>> 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
> > >>>>>> unexpectedly activate it.
> > >>>>>>
> > >>>>>> My assumption was that "it should not hurt since the text
> > is only
> > >>>>>> 10K",
> > >>>>>> however, in reality, it looks like even short texts cause
> > slowness
> > >>>>>> for the old JDK.
> > >>>>>>
> > >>>>>> So I'm inclined to make the default 0 (always disable
> > kerning in
> > >>>> response
> > >>>>>> text areas) for Java <17.
> > >>>>>> WDYT?
> > >>>>>>
> > >>>>>> Vladimir
> > >>>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Cordialement
> > >>>>> Philippe M.
> > >>>>> Ubik-Ingenierie
> > >>>>>
> > >>>
> > >>
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> >
> >
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.5 RC1

[Philippe Mouawad]

Hello,
Sorry for late reply @Milamber  , I see you're
releasing.
I noticed a regression on Reporting that may be problematic, in the error
tables, the assertion message takes precedence on error code which makes
analysis
more complex.

It's a regression introduced by
https://bz.apache.org/bugzilla/show_bug.cgi?id=65885.
Only when ignore status is checked should this happen.

Regards

On Wed, Apr 27, 2022 at 10:13 AM Milamber  wrote:

> Hi,
>
> I will prepare the RC2 today
>
> Milamber
>
> On 23/04/2022 11:02, Felix Schumacher wrote:
> >
> > What about trying an RC2 of JMeter 5.5?
> >
> > I updated our dependencies and added a workaround for the UI problem.
> >
> > Felix
> >
> > Am 18.03.22 um 17:35 schrieb Milamber:
> >>
> >>
> >> Ready for RC2? (I think that no?)
> >> cc @Vladimir
> >>
> >> On 16/03/2022 22:42, UBIK LOAD PACK Support wrote:
> >>> Hello,
> >>> Looks good to me.
> >>> Let's do another RC with this.
> >>> Regards
> >>>
> >>> On Wed, Mar 16, 2022 at 6:30 PM Vladimir Sitnikov <
> >>> sitnikov.vladi...@gmail.com> wrote:
> >>>
> >>>>> Could we make the setting java version dependant ?
> >>>> By default, the setting would be commented in jmeter.properties.
> >>>> Then, the code would use the appropriate default value according to
> >>>> Java
> >>>> version.
> >>>>
> >>>> So I suggest changing
> >>>>
> >>>>
> https://github.com/apache/jmeter/blob/53a992c8179f0f64fe1993df34bda6594856cf5e/src/jorphan/src/main/java/org/apache/jorphan/gui/ui/KerningOptimizer.java#L48
> >>>>
> >>>>
> >>>> into something like maxLengthWithKerning = currentJava < 17 ? -1 :
> >>>> 1;
> >>>>
> >>>> Vladimir
> >>>>
> >>>>
> >>>> ср, 16 мар. 2022 г. в 20:25, Philippe Mouawad <
> >>>> p.moua...@ubik-ingenierie.com
> >>>>> :
> >>>>> Could we make the setting java version dependant ?
> >>>>> If 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.
> >>>>>>
> >>>>>> 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
> >>>>>> unexpectedly activate it.
> >>>>>>
> >>>>>> My assumption was that "it should not hurt since the text is only
> >>>>>> 10K",
> >>>>>> however, in reality, it looks like even short texts cause slowness
> >>>>>> for the old JDK.
> >>>>>>
> >>>>>> So I'm inclined to make the default 0 (always disable kerning in
> >>>> response
> >>>>>> text areas) for Java <17.
> >>>>>> WDYT?
> >>>>>>
> >>>>>> Vladimir
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Cordialement
> >>>>> Philippe M.
> >>>>> Ubik-Ingenierie
> >>>>>
> >>>
> >>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.5 RC1

[Philippe Mouawad]

Hello,
Looks good to me.
Let's do another RC with this.
Regards

On Wed, Mar 16, 2022 at 6:32 PM Vincent Daburon  wrote:

> Hi,
>
> I use a JMeter 5.4.1 patched manually with log4j 2.17.2 and a jdk 8 because
> i need to add  proxy certificats for the enterprise X509 certificats in the
> carcerts jdk file.
>
> I get some troubles with open jdk 11 (i think for perfmon server that kill
> the jdk) so i still use the jdk8.
>
> I not sure that regression is for the version 5.5 but i made somes tests
> with this version and the jdk 11.x and i decided to warry you.
>
> I think lot of users will use jdk 11 and not jdk 17 in Enterprise.
>
> Regards.
> Vincent DABURON
>
> Le mer. 16 mars 2022 à 16:35, Philippe Mouawad <
> p.moua...@ubik-ingenierie.com> a écrit :
>
> > Hello Vincent,
> > Thanks for your reports.
> > Did you notice those problems in JMeter 5.4.3 ?
> >
> > Thank you
> > Regards
> >
> > On Mon, Mar 14, 2022 at 1:19 PM Vincent Daburon 
> > wrote:
> >
> > > Hi,
> > > I try JMeter 5.5 on Windows 10 + JDK openjdk-11u-11.0.4_11 (no
> > > external plugin add)
> > > I record a short JMeter script with simple html page
> > >
> > > I find a trouble for display the simple html page in the View Results
> > > Tree format text
> > > 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.
> > >
> > > The html page is very simple 2Ko
> > > and other html page 7Ko takes 16 sec to display in text format !
> > > java.runtime.name=OpenJDK Runtime Environment
> > > java.runtime.version=11.0.4+11
> > >
> > > -1 for release
> > >
> > > Big regression to display a simple page html in the View Results Tree
> > > with OpenJDK 11.02 or 11.04
> > > I can't use this version of the View Results Tree
> > >
> > >
> > > I try with
> > > java.runtime.name=OpenJDK Runtime Environment
> > > java.runtime.version=11.0.2+9
> > > java.specification.vendor=Oracle Corporation
> > > java.specification.version=11
> > >
> > > same trouble
> > >
> > >
> > > I try with the same script and result with Oracle jdk1.8.0_191
> > > JMeter 5.5 on Windows 10 + Oracle jdk1.8.0_191 (no external plugin add)
> > > I don't have the trouble, text is display quickly.
> > >
> > > I try the same script and result with Open JDK 17.0.2
> > > java.runtime.name=OpenJDK Runtime Environment
> > > java.runtime.version=17.0.2+8-86
> > > java.specification.vendor=Oracle Corporation
> > > java.specification.version=17
> > >
> > > i don't have the trouble, text is display quickly.
> > >
> > > Summary :
> > > OK with JDK 8 and 17
> > > KO with JDK 11.02 and 11.04
> > >
> > > Regards.
> > > Vincent DABURON
> > >
> > > Le lun. 14 mars 2022 à 09:19, Antonio Gomes Rodrigues
> > >  a écrit :
> > > >
> > > >  Thanks for the RM.
> > > >
> > > > +1 for release
> > > >
> > > > Le lun. 14 mars 2022 à 09:06, Vladimir Sitnikov <
> > > sitnikov.vladi...@gmail.com>
> > > > a écrit :
> > > >
> > > > > Thanks for the RM.
> > > > >
> > > > > +1 for release
> > > > >
> > > > > Vladimir
> > > > >
> > >
> >
> >
> > --
> > Cordialement
> > Philippe M.
> > Ubik-Ingenierie
> >
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: [VOTE] Release JMeter 5.5 RC1

[Philippe Mouawad]

Could we make the setting java version dependant ?
If it’s worth it as it will introduce additional config complexity

Regards
On Wednesday, March 16, 2022, Vladimir Sitnikov 
wrote:

> >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
> unexpectedly activate it.
>
> My assumption was that "it should not hurt since the text is only 10K",
> however, in reality, it looks like even short texts cause slowness
> for the old JDK.
>
> So I'm inclined to make the default 0 (always disable kerning in response
> text areas) for Java <17.
> WDYT?
>
> Vladimir
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: [VOTE] Release JMeter 5.5 RC1

[Philippe Mouawad]

Hello Vincent,
Thanks for your reports.
Did you notice those problems in JMeter 5.4.3 ?

Thank you
Regards

On Mon, Mar 14, 2022 at 1:19 PM Vincent Daburon  wrote:

> Hi,
> I try JMeter 5.5 on Windows 10 + JDK openjdk-11u-11.0.4_11 (no
> external plugin add)
> I record a short JMeter script with simple html page
>
> I find a trouble for display the simple html page in the View Results
> Tree format text
> 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.
>
> The html page is very simple 2Ko
> and other html page 7Ko takes 16 sec to display in text format !
> java.runtime.name=OpenJDK Runtime Environment
> java.runtime.version=11.0.4+11
>
> -1 for release
>
> Big regression to display a simple page html in the View Results Tree
> with OpenJDK 11.02 or 11.04
> I can't use this version of the View Results Tree
>
>
> I try with
> java.runtime.name=OpenJDK Runtime Environment
> java.runtime.version=11.0.2+9
> java.specification.vendor=Oracle Corporation
> java.specification.version=11
>
> same trouble
>
>
> I try with the same script and result with Oracle jdk1.8.0_191
> JMeter 5.5 on Windows 10 + Oracle jdk1.8.0_191 (no external plugin add)
> I don't have the trouble, text is display quickly.
>
> I try the same script and result with Open JDK 17.0.2
> java.runtime.name=OpenJDK Runtime Environment
> java.runtime.version=17.0.2+8-86
> java.specification.vendor=Oracle Corporation
> java.specification.version=17
>
> i don't have the trouble, text is display quickly.
>
> Summary :
> OK with JDK 8 and 17
> KO with JDK 11.02 and 11.04
>
> Regards.
> Vincent DABURON
>
> Le lun. 14 mars 2022 à 09:19, Antonio Gomes Rodrigues
>  a écrit :
> >
> >  Thanks for the RM.
> >
> > +1 for release
> >
> > Le lun. 14 mars 2022 à 09:06, Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com>
> > a écrit :
> >
> > > Thanks for the RM.
> > >
> > > +1 for release
> > >
> > > Vladimir
> > >
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: [VOTE] Release JMeter 5.5 RC1

[Philippe Mouawad]

Hello Felix,
Unless somebody has identified a specific issue in this version, it's not
clear for me if Vincent's report is specific to this version.

Regards

On Wed, Mar 16, 2022 at 4:15 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 15.03.22 um 22:42 schrieb Philippe Mouawad:
>
> Hello,
> I have same behaviour on Java 8 and Java 11 on MacOSX, GUI freezes.
>
> Setting below property does not improve behaviour:
>
>- text.kerning.max_document_size=1
>
>
> Note that I observe similar freeze with 5.4.1
>
> That is right, so it is not a regression per se.
>
> Does that mean, we should move on with the release?
>
> Felix
>
>
> Regards
>
>
>
> On Tue, Mar 15, 2022 at 12:58 PM Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
>> I tried the attached file.
>>
>> It samples heise.de/newsticker which will send a redirect and the
>> result, which gets stored in the View Results Tree. When I open the sub
>> results and switch between the redirect and the content sample, my GUI gets
>> stuck.
>>
>> On linux it spends a long time in
>>
>> AWT-EventQueue-0" #18 prio=6 os_prio=0 tid=0x7ff961140800
>> nid=0x25a240 runnable [0x7ff8c3b98000]
>>java.lang.Thread.State: RUNNABLE
>> at javax.swing.text.GapContent.getChars(GapContent.java:213)
>> at
>> javax.swing.text.AbstractDocument.getText(AbstractDocument.java:810)
>> at javax.swing.text.GlyphView.getText(GlyphView.java:135)
>> at javax.swing.text.GlyphView.getBreakSpot(GlyphView.java:791)
>> at javax.swing.text.GlyphView.getMinimumSpan(GlyphView.java:551)
>> at
>> javax.swing.text.ParagraphView.calculateMinorAxisRequirements(ParagraphView.java:724)
>>
>> at
>> javax.swing.JEditorPane$PlainEditorKit$PlainParagraph.calculateMinorAxisRequirements(JEditorPane.java:2163)
>>
>> at javax.swing.text.BoxView.checkRequests(BoxView.java:935)
>> at javax.swing.text.BoxView.getMinimumSpan(BoxView.java:568)
>> at
>> javax.swing.text.BoxView.calculateMinorAxisRequirements(BoxView.java:903)
>> at javax.swing.text.BoxView.checkRequests(BoxView.java:935)
>> at javax.swing.text.BoxView.setSpanOnAxis(BoxView.java:343)
>> at javax.swing.text.BoxView.layout(BoxView.java:708)
>> at javax.swing.text.BoxView.setSize(BoxView.java:397)
>> at
>> javax.swing.plaf.basic.BasicTextUI$RootView.setSize(BasicTextUI.java:1722)
>> at
>> javax.swing.plaf.basic.BasicTextUI.getPreferredSize(BasicTextUI.java:912)
>> at
>> com.github.weisj.darklaf.ui.text.DarkTextUI.getPreferredSize(DarkTextUI.java:223)
>>
>> at javax.swing.JComponent.getPreferredSize(JComponent.java:1662)
>> at javax.swing.JEditorPane.getPreferredSize(JEditorPane.java:1333)
>> at javax.swing.JViewport.getViewSize(JViewport.java:999)
>> at
>> javax.swing.plaf.basic.BasicScrollPaneUI.syncScrollPaneWithViewport(BasicScrollPaneUI.java:278)
>>
>> at
>> javax.swing.plaf.basic.BasicScrollPaneUI$Handler.stateChanged(BasicScrollPaneUI.java:1034)
>>
>> at javax.swing.JViewport.fireStateChanged(JViewport.java:1369)
>> at javax.swing.JViewport.setView(JViewport.java:969)
>> at javax.swing.JScrollPane.setViewportView(JScrollPane.java:1007)
>> at
>> org.apache.jmeter.visualizers.RenderAsText.showTextResponse(RenderAsText.java:36)
>>
>>
>> The result is about 700 KByte, so should trigger the kerning mechanism
>> anyway.
>>
>> Felix
>>
>> PS. My linux computer is currently maxed out with running a test suite
>> and the lagging can be observed with linux, too.
>> Am 15.03.22 um 12:48 schrieb Vladimir Sitnikov:
>>
>> 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
>>
>>
>>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.5 RC1

[Philippe Mouawad]

Hello,
I have same behaviour on Java 8 and Java 11 on MacOSX, GUI freezes.

Setting below property does not improve behaviour:

   - text.kerning.max_document_size=1


Note that I observe similar freeze with 5.4.1

Regards



On Tue, Mar 15, 2022 at 12:58 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

> I tried the attached file.
>
> It samples heise.de/newsticker which will send a redirect and the result,
> which gets stored in the View Results Tree. When I open the sub results and
> switch between the redirect and the content sample, my GUI gets stuck.
>
> On linux it spends a long time in
>
> AWT-EventQueue-0" #18 prio=6 os_prio=0 tid=0x7ff961140800 nid=0x25a240
> runnable [0x7ff8c3b98000]
>java.lang.Thread.State: RUNNABLE
> at javax.swing.text.GapContent.getChars(GapContent.java:213)
> at
> javax.swing.text.AbstractDocument.getText(AbstractDocument.java:810)
> at javax.swing.text.GlyphView.getText(GlyphView.java:135)
> at javax.swing.text.GlyphView.getBreakSpot(GlyphView.java:791)
> at javax.swing.text.GlyphView.getMinimumSpan(GlyphView.java:551)
> at
> javax.swing.text.ParagraphView.calculateMinorAxisRequirements(ParagraphView.java:724)
>
> at
> javax.swing.JEditorPane$PlainEditorKit$PlainParagraph.calculateMinorAxisRequirements(JEditorPane.java:2163)
>
> at javax.swing.text.BoxView.checkRequests(BoxView.java:935)
> at javax.swing.text.BoxView.getMinimumSpan(BoxView.java:568)
> at
> javax.swing.text.BoxView.calculateMinorAxisRequirements(BoxView.java:903)
> at javax.swing.text.BoxView.checkRequests(BoxView.java:935)
> at javax.swing.text.BoxView.setSpanOnAxis(BoxView.java:343)
> at javax.swing.text.BoxView.layout(BoxView.java:708)
> at javax.swing.text.BoxView.setSize(BoxView.java:397)
> at
> javax.swing.plaf.basic.BasicTextUI$RootView.setSize(BasicTextUI.java:1722)
> at
> javax.swing.plaf.basic.BasicTextUI.getPreferredSize(BasicTextUI.java:912)
> at
> com.github.weisj.darklaf.ui.text.DarkTextUI.getPreferredSize(DarkTextUI.java:223)
>
> at javax.swing.JComponent.getPreferredSize(JComponent.java:1662)
> at javax.swing.JEditorPane.getPreferredSize(JEditorPane.java:1333)
> at javax.swing.JViewport.getViewSize(JViewport.java:999)
> at
> javax.swing.plaf.basic.BasicScrollPaneUI.syncScrollPaneWithViewport(BasicScrollPaneUI.java:278)
>
> at
> javax.swing.plaf.basic.BasicScrollPaneUI$Handler.stateChanged(BasicScrollPaneUI.java:1034)
>
> at javax.swing.JViewport.fireStateChanged(JViewport.java:1369)
> at javax.swing.JViewport.setView(JViewport.java:969)
> at javax.swing.JScrollPane.setViewportView(JScrollPane.java:1007)
> at
> org.apache.jmeter.visualizers.RenderAsText.showTextResponse(RenderAsText.java:36)
>
>
> The result is about 700 KByte, so should trigger the kerning mechanism
> anyway.
>
> Felix
>
> PS. My linux computer is currently maxed out with running a test suite and
> the lagging can be observed with linux, too.
> Am 15.03.22 um 12:48 schrieb Vladimir Sitnikov:
>
> 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
>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.5 RC1

[Philippe Mouawad]

Hello

Thanks for the RM

[X] +1  I support this release (binding)

Tested on Mac OS Java 11:

   - Plugin installation
   - Cli mode test run with report generation
   - Test run from GUI
   - Test creation from Template
   - Report generation only
   - Report generation from GUI
   - Multiple GUI features

Regards


On Sun, Mar 13, 2022 at 11:47 AM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 12.03.22 um 16:18 schrieb Milamber:
>
> Hello,
>
> The first release candidate for JMeter 5.5 (1efebb753d) has been prepared,
> and your votes are solicited.
>
> This release brings some new features and improvements, and also fixes
> bugs.
>
> Please, test this release candidate (with load tests and/or functional
> tests) using Java 8+ on Linux/Windows/macOS, especially on the changes.
> Feedback is very welcome within the next 72 hours.
>
> You can read the New and Noteworthy section with some screenshots to
> illustrate improvements and full list of changes at:
> https://apache.github.io/jmeter-site-preview/site/changes.html
>
> JMeter is a Java desktop application designed to load test functional
> behavior and measure performance. The current version targets Java 8+
>
> Download - Archives/hashes/sigs:
> https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-5.5-rc1
> (dist revision 52999)
>
> RAT report:
> https://apache.github.io/jmeter-site-preview/rat/
>
> SHA512 hashes of archives for this vote: see footnote [1]
>
> Site preview is here:
> https://apache.github.io/jmeter-site-preview/site/
>
> JavaDoc API preview is here:
> https://apache.github.io/jmeter-site-preview/site/api/
>
> Maven staging repository is accessible here:
>
> https://repository.apache.org/content/repositories/orgapachejmeter-1076/org/apache/jmeter/
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=jmeter.git;a=tag;h=refs/tags/v5.5-rc1
>
>
> Keys are here:
> https://www.apache.org/dist/jmeter/KEYS
>
> N.B.
> To create the distribution and test JMeter: "./gradlew build -Prelease
> -PskipSign".
>
> JMeter 5.5 requires Java 8 or later to run.
>
> The artifacts were built with
>   Java(TM) SE Runtime Environment Oracle Corporation (build 1.8.0_271-b09)
>   Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build 25.271-b09,
> mixed mode)
>
> Some known issues and incompatible changes are listed on changes page.
>
> https://apache.github.io/jmeter-site-preview/site/changes.html#Known%20problems%20and%20workarounds
>
>
> All feedback and vote are welcome.
>
> [x] +1  I support this release
>
> Thanks for the RM
>
> Checked the Signatures, Sources to the Tag and ran some short tests under
> Linux with Java 8 and Java 17 (with Nashorn added to the lib directory --
> without module path)
>
> Felix (binding)
>
>
> [  ] +0  I am OK with this release
> [  ] -0  OK, but
> [  ] -1  I do not support this release (please indicate why)
>
> The vote will remain open for at least 72 hours.
>
> The PMC members please indicate the mention "(binding)" with your vote.
>
>
> Note: If the vote passes, the intention is to release the archive files
> and rename the RC tag as the release tag.
>
> Thanks in advance!
>
> Milamber
>
> ===
> [1] SHA512 hashes of archives for this vote:
>
> 839751529d46314ef5028de47f2ec4c72e3a9eaf7da86d169b18eaa1af425350a3863d25d58621b8fc40c45d52059157d9f8b4ee20aa6c9b8b3569beae0a5243
>
> *apache-jmeter-5.5.tgz
> 519efbaec7f9f14c806a7bac22a9eafdfe8d90296d7a981c692278cf1b137ce46e5b5f6f2f03e84bdc1404ef32df8c2143364f11c1a33fdd1ad367796d39bbbe
>
> *apache-jmeter-5.5.zip
> 84e3d94415822fa14c2eee4e675d825bbc1e67c28d9bd1ab4ca610d3700d4da800542d3ba3078bb370a6e6bf01c83ec4d10a798286b3a601435386e8394b0733
>
> *apache-jmeter-5.5_src.tgz
> f28e7acb6543b6bb6c6832a74cf21849d06de7d7842b139c438ba6f1c959e8e668a16af0a98f51ae38a99a6f36ff161b9cb9014ccff597fc0d16af549206ed57
>
> *apache-jmeter-5.5_src.zip
>
>
>

-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: Let's release JMeter 5.5 ?

[Philippe Mouawad]

Hello,
Yes let’s merge it.

Regards

On Saturday, March 5, 2022, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

> *ping* (log4j 2.17.2 is out :) )
>
> (Should we merge PR 700 before release?)
>
> Am 21.02.22 um 11:17 schrieb Philippe Mouawad:
>
>> Hello,
>>
>> What do you think of releasing version 5.5 ?
>>
>> The version looks nice and also answers the log4j update  to 2.17.1 that
>> is
>> requested by some users.
>>
>>
>> Regards
>> Philippe M.
>>
>>

-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Let's release JMeter 5.5 ?

[Philippe Mouawad]

Hello,

What do you think of releasing version 5.5 ?

The version looks nice and also answers the log4j update  to 2.17.1 that is
requested by some users.


Regards
Philippe M.

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

[Philippe Mouawad]

Hello,
Find my answers inline below.

Regards

On Tue, Dec 28, 2021 at 7:34 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> 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
> account)
>
That's a annoying if my understanding is correct, how do we distinguish
reporters comments from dev/committers ones ?

b) Attachments won't be copied (we could hyperlink to the Bugzilla instance
> though)
>
Does it means bugzilla would still be up ? What is the point then ?

Do the downsides vs benefit worth the migration ?

>
> Vladimir
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: [VOTE] Release JMeter 5.4.3 RC1

[Philippe Mouawad]

Hello,
Thanks to RM

+1  I support this release.

Happy holidays
Regards

On Thursday, December 23, 2021, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> [  ] +1  I support this release.
>
> Thank you,
>
> Vladimir
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: JMeter 5.5 release

[Philippe Mouawad]

Hello,

I think changes.xml might be missing some updates, I don't see mention of
OpenModel Thread Group.

Regards

On Tue, Dec 21, 2021 at 4:33 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> 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
>


-- 
Cordialement.
Philippe Mouawad.

Re: [DISCUSS] Replace log4j2 with logback

[Philippe Mouawad]

On Tue, Dec 21, 2021 at 1:51 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >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.
>

It's not that simple.
We're speaking about time to fix EOL library .
PMC can prefer to allocate time for constructive work that is beneficial to
the project.

Are you saying a person taking time just to fix its problem and leave the
project once done should be a PMC member ?


> >If I may correct your formulation
>
> My formulation is:
> If somebody chimes in and does the heavy lifting for fixing JMeter 2.x,
> I would be OK to help with pushing the release,
> or I would be OK to transfer rights for 2.x to the given team if I can't
> help with the release.
>
> No way I would say something like "2.x is EOL, contributions unwelcome".
> No way I would say something like "please provide all the patches before I
> even consider the request"
>

The demagogue side of myself would fully agree with you.
The realistic side of myself would say that's not that easy.


> >What is being blocked here ? Please clarify ?
> >Are you speaking about:
> >   - releasing JMeter 3.X with log4j2 updated  ?
>
> I am speaking about "releasing JMeter 3.x with log4j2 updated".
>
Did anybody ask for it ?
If you're willing to do it, I won't block you if other members are ok with
this.

Here's the case once again:
>
> Vladimir>Supposed someone chimes in and suggest releasing JMeter 3.x
> Vladimir>with log4j fixed. Suppose they would be open to do 90% of all the
> heavy-lifting.
> Vladimir>For instance, they might suggest a PR to make JMeter 3 buildable,
> they act as a release manager, etc.
> Vladimir>Would you be open to just allowing the release to happen and
> voting on the release?
>
> I believe there's nothing to consider there, and we could (should) welcome
> that.
> I believe that behavior would be great for the community, and it would
> highlight JMeter in a positive light.
>

Maybe , or maybe not
Let me share with you this about what we should do:

   - http://www.la-fontaine-ch-thierry.net/meunfils.htm



> Vladimir
>


-- 
Cordialement.
Philippe Mouawad.

Re: [DISCUSS] Replace log4j2 with logback

[Philippe Mouawad]

On Tue, Dec 21, 2021 at 1:26 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >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 that time-consuming.
>
So I am happy you agree to say that it involves PMC, whatever the time it
takes.


> >I'll consider the case when it happens
>
> I am sure the case is crystal clear.
> It is sad if you still need to "consider".
>

If I may correct your formulation: 'I (you) feel sad if you still need to
"consider" '


> I absolutely see no reason for PMC to block releases for past versions,
> especially in the case when the contributor does most of the work.
>

What is being blocked here ? Please clarify ?
Are you speaking about:

   - releasing log4j 1?
   - releasing JMeter 3.X with log4j2 updated  ?
   - switching from log4j2 to logback ?
   - something else ?


I am a bit lost.
I'll answer when you clarify and will stop discussing on this thread as I
see it may be taking the wrong path.


> Vladimir
>


-- 
Cordialement.
Philippe Mouawad.

Re: [DISCUSS] Replace log4j2 with logback

[Philippe Mouawad]

On Tue, Dec 21, 2021 at 1:17 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >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 act
> as a release manager, etc.
>

To be a release manager , you need committer rights no ?

>
> Would you be open to just allowing the release to happen and voting on the
> release?
>
I'll consider the case when it happens

>
> Vladimir
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: [DISCUSS] Replace log4j2 with logback

[Philippe Mouawad]

Hello,
When a free OSS library is publicly in EOL since many years, and you don’t
pay extended support to anybody, you know the risks you’re taking.

As a software developer I am very frequently frustrated by people refusing
the upgrade of libraries because it costs money and « doesn’t bring
anything », so I will not contrubute to giving arguments to this policy.
Fixing EOL library is just that IMO.

If you want a fix, then you can pay for a project member or consultant to
implement the fix and share it if you want with community on github without
involving us, ASF allows that AFAIU.

But you should not expect contributors of OSS project to do it on their
free time , EOL has a meaning.

Saying that, I wonder if we are explicit enough about EOL in JMeter.

Regarding your comparison with Cobol is not free, and I am sure users pay
lot of money for its « extended or not support », so it does not compare to
log4j in any way.

Now regarding a fix to jmeter 1 or 2, well it’s your opinion as of now, I
am happy you’re contributing a lot these days, but things change as long as
people.

As of me, I would responsibly advise users to forget about Jmeter 1, 2, 3
not only for CVE but for all other bugs that have been fixed and all
features in more up to date versions.
We take time in our development to explicitly document deprecated features,
 changes… That helps upgrading.

Regards
Philippe

On Tuesday, December 21, 2021, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >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
>
> Suppose:
> 1. someone asks to fix CVE in JMeter 1
> 2. they are eager to implement the fix
> 3. they provide a reasonable explanation why they can't upgrade
>
> I would expect:
> a) JMeter team to implement the fix
> b) or co-operate with getting the fix released (e.g. create Git branch,
> accept PRs, etc, prepare versions).
> c) or give away control over JMeter 1 so other contributors can implement
> 1.x fixes and release 1.x versions.
>
> For instance, option "c" might be selected by JMeter team if applying fixes
> and releasing takes too much effort.
> For example, if somebody adds GitHub Actions CI to JMeter 1.x I would be OK
> to review and merge it.
>
> Does that answer your question?
>
> >I would fully expect you to say move to the latest version where we have
> fixed this issue
>
> Note that we are about to release JMeter 5.5 with new features.
> The repository is all good for the release, however, the team did
> back-patch 5.4.2
> Back-patching 5.4.2 was not my idea, and I appreciate the ones who did that
> (Milamber?)
>
> >I wouldn’t expect you to patch JMeter 2, 3, 4, and 5.
>
> JMeter 2 is not using log4j2, so it is not that impacted.
> We assume 5.x->5.4 upgrade is workable for everybody, and nobody voiced
> they are stuck with 5.0.
> I know people might be stuck with 4.x, and 3.x (that are affected by log4j2
> CVE), so it would be responsible
> to release those versions as well.
>
> Unfortunately, 3.x and 4.x are Ant-based, so the release steps are way
> harder there than we have now.
>
> Vladimir
>

Re: [DISCUSS] Replace log4j2 with logback

[Philippe Mouawad]

Hello Vladimir,

I feel that it's over engineering here. If we were starting a new project ,
I would be ok.
But this change here and now, does not bring major features to users (I
think logging works pretty nicely today), it will even
bring more work for them in case they don't know logback.

On a personal point of view, ok log4j2 had CVEs, but it can happen to any
project (logback also had one although less impacting), would you be happy
to see our users abandon JMeter because a CVE is discovered ?

I'll of course reconsider this position if we see no activity in log4j2 in
the future.

So I am against this change.

Regards
Philippe


On Tue, Dec 21, 2021 at 10:58 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> 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 whole
> application
> * log4j2 team seems to treat silent variable substitution (which caused
> ${ldap}) a feature, and they tried to keep compatibility for it, so 2.15
> was not enough
> * log4j2 team seems to treat "infinite pattern recursion" as a feature
> * log4j2 team is not responsible enough to release log4j 1.x that would fix
> known security vulnerabilities even though lots of apps can't really
> upgrade from 1.x to 2.x
>
> * logback is developed by Ceki who maintains both slf4j and logback.
> That is the integration of slf4j+logback should be much more stable than
> slf4j->log4j2
> * logback has a good story regarding the team, feature set, performance.
> Ceki incepted (?) log4j, he was a chair of Logging PMC, Ceki incepted slf4j
> and logback.
> That is a really good story, and it is really hard to beat that.
>
> So I believe we should migrate off log4j2 as soon as possible.
> I can do the migration, however, I would be glad if somebody else steps in
> as well.
>
> Vladimir
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: jMeter v3.3 log4j Remediation Steps

[Philippe Mouawad]

Hello,
Just replace the log4j2 libraries by latest version.
See:

https://www.ubik-ingenierie.com/blog/jmeter-log4j-vulnerability/

Regards

On Mon, Dec 20, 2021 at 10:07 PM Warner - OIT, Kennon <
kennon.war...@state.co.us> wrote:

> To Whom It May Concern,
>
> Are there any remediation steps documented we could follow to address this
> issue? We don't really have the ability to upgrade to the latest version of
> jmeter 5x.
>
> Thanks
>
> --
>
> *Kennon Warner*
>
> *Senior Manager - **Customer Applications - Labor*
>
>
>
> P:  303.318.8346  |  C: 720.347.7701
>
> Gvoice: 720.773.0839
>
> 633 17th Street, Ste 800, Denver, CO 80202 <
> https://goo.gl/maps/afc8bkLcadt>
>
> kennon.war...@state.co.us  |  www.colorado.gov/oit
>
>
>
> How am I doing?  Please contact my director Robert Belton
> , at robert.bel...@state.co.us for comments or
> questions.
>
>
> CONFIDENTIALITY:  This electronic mail transmission (including any
> attachments) may contain confidential or legally privileged information,
> intended only for the person(s) named.  Any use, distribution, copying, or
> disclosure by another person is strictly prohibited.
>


-- 
Cordialement.
Philippe Mouawad.

Re: Log4j 2.17 Update

[Philippe Mouawad]

Hello,
This CVE is not as critical as previous ones, it allows denial of service
not to take control of server.
since JMeter is not a server application but more a client tool, I don’t
think there is an urgent need to release a new version.


See:
-
https://snyk.io/blog/log4j-2-16-high-severity-vulnerability-cve-cve-2021-45105-discovered/

Regards

On Sunday, December 19, 2021, NaveenKumar Namachivayam <
catchnaveen.psgt...@gmail.com> wrote:

> Hi Team,
>
>
>
> Log4j 2.17 has been released for the CVE-2021-45105. Any plans to release a
> minor version or, are we going to Jmeter 5.5?
>
>
>
> Any input please?
>
>
> Thanks!
> ‌
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: [VOTE] Release JMeter 5.4.2 RC1

[Philippe Mouawad]

Hello Milamber,
Do you think we really need to wait 72h ?

Since all active members have voted, I think we should release ASAP just to
avoid all the noise regarding this CVE.

Thanks
Regards

On Thursday, December 16, 2021, Antonio Gomes Rodrigues 
wrote:

> +1
>
> Le jeu. 16 déc. 2021 à 09:40, OUFDOU Anas  a écrit
> :
>
> > Hello,
> >
> > > [x] +1  I support this release
> >
> >
> > On Wed, Dec 15, 2021 at 9:41 PM Felix Schumacher <
> > felix.schumac...@internetallee.de> wrote:
> >
> > >
> > > Am 15.12.21 um 19:23 schrieb Milamber:
> > > > Hello,
> > > >
> > > > The first release candidate for JMeter 5.4.2 (f393453287) has been
> > > > prepared, and your votes are solicited.
> > > >
> > > > This release is only a vulnerabily fix release about the
> > > > CVE-2021-44228: Apache Log4j2 JNDI features do not protect against
> > > > attacker controlled LDAP and other JNDI related endpoints.
> > > >
> > > > Please, test this release candidate (with load tests and/or
> functional
> > > > tests) using Java 8+ on Linux/Windows/macOS, especially on the
> changes.
> > > > Feedback is very welcome within the next 72 hours.
> > > >
> > > > You can read the New and Noteworthy section with some screenshots to
> > > > illustrate improvements and full list of changes at:
> > > > https://apache.github.io/jmeter-site-preview/site/changes.html
> > > >
> > > > JMeter is a Java desktop application designed to load test functional
> > > > behavior and measure performance. The current version targets Java 8+
> > > >
> > > > Download - Archives/hashes/sigs:
> > > > https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-
> 5.4.2-rc1
> > > > (dist revision 51472)
> > > >
> > > > RAT report:
> > > > https://apache.github.io/jmeter-site-preview/rat/
> > > >
> > > > SHA512 hashes of archives for this vote: see footnote [1]
> > > >
> > > > Site preview is here:
> > > > https://apache.github.io/jmeter-site-preview/site/
> > > >
> > > > JavaDoc API preview is here:
> > > > https://apache.github.io/jmeter-site-preview/site/api/
> > > >
> > > > Maven staging repository is accessible here:
> > > >
> > >
> > https://repository.apache.org/content/repositories/
> orgapachejmeter-1073/org/apache/jmeter/
> > > >
> > > >
> > > > Tag:
> > > >
> > >
> > https://gitbox.apache.org/repos/asf?p=jmeter.git;a=tag;
> h=refs/tags/v5.4.2-rc1
> > > >
> > > >
> > > >
> > > > Keys are here:
> > > > https://www.apache.org/dist/jmeter/KEYS
> > > >
> > > > N.B.
> > > > To create the distribution and test JMeter: "./gradlew build
> -Prelease
> > > > -PskipSign".
> > > >
> > > > JMeter 5.4.2 requires Java 8 or later to run.
> > > >
> > > > The artifacts were built with
> > > >   Java(TM) SE Runtime Environment Oracle Corporation (build
> > > > 1.8.0_271-b09)
> > > >   Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build
> > > > 25.271-b09, mixed mode)
> > > >
> > > > Some known issues and incompatible changes are listed on changes
> page.
> > > >
> > >
> > https://apache.github.io/jmeter-site-preview/site/
> changes.html#Known%20problems%20and%20workarounds
> > > >
> > > >
> > > >
> > > > All feedback and vote are welcome.
> > > >
> > > > [x] +1  I support this release
> > > > [  ] +0  I am OK with this release
> > > > [  ] -0  OK, but
> > > > [  ] -1  I do not support this release (please indicate why)
> > > >
> > > > The vote will remain open for at least 72 hours.
> > > >
> > > > The PMC members please indicate the mention "(binding)" with your
> vote.
> > >
> > > Thanks Milamber for the release work.
> > >
> > > Felix (binding)
> > >
> > >
> > > >
> > > >
> > > > Note: If the vote passes, the intention is to release the archive
> files
> > > > and rename the RC tag as the release tag.
> > > >
> > > > Thanks in advance!
> > > >
> > > > Milamber
> > > >
> > > > ===
> > > > [1] SHA512 hashes of archives for this vote:
> > > >
> > > >
> > >
> > 5eaf0ad4ef8941080c0cf1d7fb732c6d14e3d16ac900885b912a62bea242
> 10adcc9c9a09cb0f028f0253e3f6f785800aec2f3dda92121d0259dcda09223a0de1
> > > >
> > > > *apache-jmeter-5.4.2.tgz
> > > >
> > >
> > 968e2b8c6b8ea393ae83d021c67adf36657a561b37e577ca499bc73becc3
> a4fd49989069d94fdc2d26f23fd223b3c769426a39d5a928502f16f3a2889955bbdc
> > > >
> > > > *apache-jmeter-5.4.2.zip
> > > >
> > >
> > 98c75f3151990d94951dc46051d8382a60766455344528ea021638913ee9
> 731a60534ba53167723255aa03e41f6621f5be4a2eb36692b42642dc8e406bf2bb4b
> > > >
> > > > *apache-jmeter-5.4.2_src.tgz
> > > >
> > >
> > 8443ee884e06d121201aaeb47e623da5a5f4a3054cf030c3cce454d700dc
> 13cc676f3d3e44279afd1463f40382551ad42e8faae1388f6617f543a354282bab08
> > > >
> > > > *apache-jmeter-5.4.2_src.zip
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> > --
> > Cordialement,
> > -
> > Anas OUFDOU
> >
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: [VOTE] Release JMeter 5.4.2 RC1

[Philippe Mouawad]

Hello,
Thanks for release Milamber

+1 I support this release

Regards

On Wednesday, December 15, 2021, Milamber  wrote:

> Hello,
>
> The first release candidate for JMeter 5.4.2 (f393453287) has been
> prepared, and your votes are solicited.
>
> This release is only a vulnerabily fix release about the CVE-2021-44228:
> Apache Log4j2 JNDI features do not protect against attacker controlled LDAP
> and other JNDI related endpoints.
>
> Please, test this release candidate (with load tests and/or functional
> tests) using Java 8+ on Linux/Windows/macOS, especially on the changes.
> Feedback is very welcome within the next 72 hours.
>
> You can read the New and Noteworthy section with some screenshots to
> illustrate improvements and full list of changes at:
> https://apache.github.io/jmeter-site-preview/site/changes.html
>
> JMeter is a Java desktop application designed to load test functional
> behavior and measure performance. The current version targets Java 8+
>
> Download - Archives/hashes/sigs:
> https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-5.4.2-rc1
> (dist revision 51472)
>
> RAT report:
> https://apache.github.io/jmeter-site-preview/rat/
>
> SHA512 hashes of archives for this vote: see footnote [1]
>
> Site preview is here:
> https://apache.github.io/jmeter-site-preview/site/
>
> JavaDoc API preview is here:
> https://apache.github.io/jmeter-site-preview/site/api/
>
> Maven staging repository is accessible here:
> https://repository.apache.org/content/repositories/orgapache
> jmeter-1073/org/apache/jmeter/
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=jmeter.git;a=tag;h=
> refs/tags/v5.4.2-rc1
>
>
> Keys are here:
> https://www.apache.org/dist/jmeter/KEYS
>
> N.B.
> To create the distribution and test JMeter: "./gradlew build -Prelease
> -PskipSign".
>
> JMeter 5.4.2 requires Java 8 or later to run.
>
> The artifacts were built with
>   Java(TM) SE Runtime Environment Oracle Corporation (build 1.8.0_271-b09)
>   Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build 25.271-b09,
> mixed mode)
>
> Some known issues and incompatible changes are listed on changes page.
> https://apache.github.io/jmeter-site-preview/site/changes.
> html#Known%20problems%20and%20workarounds
>
>
> All feedback and vote are welcome.
>
> [  ] +1  I support this release
> [  ] +0  I am OK with this release
> [  ] -0  OK, but
> [  ] -1  I do not support this release (please indicate why)
>
> The vote will remain open for at least 72 hours.
>
> The PMC members please indicate the mention "(binding)" with your vote.
>
>
> Note: If the vote passes, the intention is to release the archive files
> and rename the RC tag as the release tag.
>
> Thanks in advance!
>
> Milamber
>
> ===
> [1] SHA512 hashes of archives for this vote:
>
> 5eaf0ad4ef8941080c0cf1d7fb732c6d14e3d16ac900885b912a62bea242
> 10adcc9c9a09cb0f028f0253e3f6f785800aec2f3dda92121d0259dcda09223a0de1
> *apache-jmeter-5.4.2.tgz
> 968e2b8c6b8ea393ae83d021c67adf36657a561b37e577ca499bc73becc3
> a4fd49989069d94fdc2d26f23fd223b3c769426a39d5a928502f16f3a2889955bbdc
> *apache-jmeter-5.4.2.zip
> 98c75f3151990d94951dc46051d8382a60766455344528ea021638913ee9
> 731a60534ba53167723255aa03e41f6621f5be4a2eb36692b42642dc8e406bf2bb4b
> *apache-jmeter-5.4.2_src.tgz
> 8443ee884e06d121201aaeb47e623da5a5f4a3054cf030c3cce454d700dc
> 13cc676f3d3e44279afd1463f40382551ad42e8faae1388f6617f543a354282bab08
> *apache-jmeter-5.4.2_src.zip
>
>
>
>
>

-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: JMeter versions and release dates

[Philippe Mouawad]

Hello Milamber,
If you're available, it would be good to release:

   - 5.4.2 with just the fix for Log4J
   - 5.5 (fix+improvements)

If not, just 5.5

Thanks

On Wed, Dec 15, 2021 at 9:02 AM Milamber  wrote:

> Hi,
>
> Probably need to release ASAP a fix version? 5.4.1? (from tag with just
> the fix for Log4J) or new version 5.5 (fix+improvements)?
>
> Milamber
>
> On 14/12/2021 21:42, Philippe Mouawad wrote:
> > Hello,
> > For information:
> >
> > - https://blogs.apache.org/security/entry/cve-2021-44228
> >
> > Regards
> > On Tuesday, December 14, 2021, Philippe Mouawad <
> > p.moua...@ubik-ingenierie.com> wrote:
> >
> >> Hello,
> >> For me both 6.0 and 5.5 are ok.
> >> Regards
> >>
> >> On Tue, Dec 7, 2021 at 9:02 PM Milamber  wrote:
> >>
> >>> Hi,
> >>>
> >>> Currently, I prefer release 5.5 as version, add deprecated elements if
> >>> needed.
> >>>
> >>> for 6.0 version, probably we can migrate JMeter on next openjdk LTS 11
> >>> (or why not 17) (so with OpenJDK official support instead Oracle Java).
> >>> Using recent openjdk allow improvements from java release.
> >>>
> >>> and for 6.0, add support for HTTP/2.0 request seems be a requirement.
> >>>
> >>> Milamber
> >>>
> >>> On 07/12/2021 19:07, Felix Schumacher wrote:
> >>>> Am 07.12.21 um 18:48 schrieb Vladimir Sitnikov:
> >>>>>> 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 more important a major version could be a good point to drop old
> >>>>>> stuff
> >>>>> I am afraid it does not work that way.
> >>>>> If we want to drop something, we need to announce the deprecation
> plan
> >>> in
> >>>>> advance.
> >>>>> AFAIK MongoDB is not deprecated (at least, MongoScriptSampler is not
> >>>>> deprecated), so there's no option to drop it yet.
> >>>> That is what I meant. If we want to use the next major version to drop
> >>>> things. 5.5 would be a good opportunity to mark those features as
> >>>> deprecated.
> >>>>
> >>>>
> >>>>>> so a 6.0 is not necessarily needed
> >>>>> In 99% of the cases, the versions are there to convey the changes to
> >>> the
> >>>>> end-users.
> >>>>> I really like realver:
> >>>>> https://twitter.com/lorenc_dan/status/1209289792569131008
> >>>>>
> >>>>> 6.0 would mean "hey, there's something big, go and try it" :)
> >>>> That is true, too :)
> >>>>
> >>>> Felix
> >>>>
> >>>>> Vladimir
> >>>>>
> >>>
> >> --
> >> Cordialement
> >> Philippe M.
> >> Ubik-Ingenierie
> >>
> >
>
>

-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: JMeter versions and release dates

[Philippe Mouawad]

Hello,
For information:

- https://blogs.apache.org/security/entry/cve-2021-44228

Regards
On Tuesday, December 14, 2021, Philippe Mouawad <
p.moua...@ubik-ingenierie.com> wrote:

> Hello,
> For me both 6.0 and 5.5 are ok.
> Regards
>
> On Tue, Dec 7, 2021 at 9:02 PM Milamber  wrote:
>
>> Hi,
>>
>> Currently, I prefer release 5.5 as version, add deprecated elements if
>> needed.
>>
>> for 6.0 version, probably we can migrate JMeter on next openjdk LTS 11
>> (or why not 17) (so with OpenJDK official support instead Oracle Java).
>> Using recent openjdk allow improvements from java release.
>>
>> and for 6.0, add support for HTTP/2.0 request seems be a requirement.
>>
>> Milamber
>>
>> On 07/12/2021 19:07, Felix Schumacher wrote:
>> > Am 07.12.21 um 18:48 schrieb Vladimir Sitnikov:
>> >>> 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 more important a major version could be a good point to drop old
>> >>> stuff
>> >> I am afraid it does not work that way.
>> >> If we want to drop something, we need to announce the deprecation plan
>> in
>> >> advance.
>> >> AFAIK MongoDB is not deprecated (at least, MongoScriptSampler is not
>> >> deprecated), so there's no option to drop it yet.
>> > That is what I meant. If we want to use the next major version to drop
>> > things. 5.5 would be a good opportunity to mark those features as
>> > deprecated.
>> >
>> >
>> >>> so a 6.0 is not necessarily needed
>> >> In 99% of the cases, the versions are there to convey the changes to
>> the
>> >> end-users.
>> >> I really like realver:
>> >> https://twitter.com/lorenc_dan/status/1209289792569131008
>> >>
>> >> 6.0 would mean "hey, there's something big, go and try it" :)
>> > That is true, too :)
>> >
>> > Felix
>> >
>> >> Vladimir
>> >>
>>
>>
>
> --
> Cordialement
> Philippe M.
> Ubik-Ingenierie
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: JMeter versions and release dates

[Philippe Mouawad]

Hello,
For me both 6.0 and 5.5 are ok.
Regards

On Tue, Dec 7, 2021 at 9:02 PM Milamber  wrote:

> Hi,
>
> Currently, I prefer release 5.5 as version, add deprecated elements if
> needed.
>
> for 6.0 version, probably we can migrate JMeter on next openjdk LTS 11
> (or why not 17) (so with OpenJDK official support instead Oracle Java).
> Using recent openjdk allow improvements from java release.
>
> and for 6.0, add support for HTTP/2.0 request seems be a requirement.
>
> Milamber
>
> On 07/12/2021 19:07, Felix Schumacher wrote:
> > Am 07.12.21 um 18:48 schrieb Vladimir Sitnikov:
> >>> 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 more important a major version could be a good point to drop old
> >>> stuff
> >> I am afraid it does not work that way.
> >> If we want to drop something, we need to announce the deprecation plan
> in
> >> advance.
> >> AFAIK MongoDB is not deprecated (at least, MongoScriptSampler is not
> >> deprecated), so there's no option to drop it yet.
> > That is what I meant. If we want to use the next major version to drop
> > things. 5.5 would be a good opportunity to mark those features as
> > deprecated.
> >
> >
> >>> so a 6.0 is not necessarily needed
> >> In 99% of the cases, the versions are there to convey the changes to the
> >> end-users.
> >> I really like realver:
> >> https://twitter.com/lorenc_dan/status/1209289792569131008
> >>
> >> 6.0 would mean "hey, there's something big, go and try it" :)
> > That is true, too :)
> >
> > Felix
> >
> >> Vladimir
> >>
>
>

-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: JMeter versions and release dates

[Philippe Mouawad]

Ok for me

On Fri, Dec 3, 2021 at 10:55 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> 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
> However, now it looks like it might be a good idea:
> * Open Model Thread Group introduces a new way to configure workload.
> Of course, it is experimental, and it would sound fine when we refine it in
> 6.1+
> * We add Kotlin language. Even though it is an "invisible" change for the
> end-users (it is not much different from upgrading dependencies),
> however, it might attract contributors.
> * We increase distribution size (we bundle lets-plot for plots)
>
> I am not sure how long it would take for adding experimental DSL, however,
> if we merge both DSL and OpenModel,
> then it definitely qualifies as 6.0.
>
> Vladimir
>


-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Enable Github Discussions on Apache JMeter Github Repo

[Philippe Mouawad]

Hello,

-1 it is yet another place, where stuff will pile up.

Regards

On Thu, Nov 25, 2021 at 5:21 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

> +1 binding
>
> even, if it is yet another place, where stuff will pile up.
>
> Felix
>
> Am 25.11.21 um 06:34 schrieb Vladimir Sitnikov:
> > 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 ASF Foundation, all code-related discussions and
> > project management activities MUST be reflected to an ASF mailing list (
> > dev@jmeter.apache.org).
> >
> >
> > *Discussion Threads in Apache Airflow*:
> > https://lists.apache.org/thread/hhd1gbd848hod3t73mchfbdt10ztddyw
> > https://lists.apache.org/thread/59qn02v749lktj18to0krpolzp8wt0no
> >
> >
> > Consider this my +1 binding
> >
> > Regards,
> > Vladimir
> >
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: Move "precise throughput computation" to thread group

[Philippe Mouawad]

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 OpenModelThreadGroup almost a
> month ago,
> and it looks like Kotlin is the only open question left.
>
> I do not think I have seen opinions like "somebody quitting JMeter
> community because of Kotlin"
> I do not think I have seen opinions like "somebody stopping JMeter
> maintenance because of Kotlin".
> In theory, such people might exist, however, we can never make
> everybody happy, especially those who never speak up.
>
> Can we accept the use of Kotlin for the main codebase and move forward?
>
> Vladimir
>


-- 
Cordialement.
Philippe Mouawad.

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

[Philippe Mouawad]

Hello,
My discussion "vote" is
+1 keep Bugzilla (not much work for me, and it works for me really well)
-1 JIRA (I find it very slow last time I used it)
+1 Github Issues (but what happens if at some step we have to leave github
provided we don"t loose bugzilla history)

Regards
Philippe

On Thu, Nov 25, 2021 at 5:05 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

> My discussion "vote" is
>
> +1 keep Bugzilla (not much work for me, and it works for me really well)
> -0.8 JIRA (I find it difficult to use)
> +0.5 Github Issues (they seem to be lightweight enough to be
> understandable by me, but I fear, that we would loose a lot of old
> issues (which might be a good thing))
>
> Felix
>
> Am 25.11.21 um 12:09 schrieb Vladimir Sitnikov:
> > 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,
> > so GitHub Issues would be easier for me.
> >
> > Let us try the following vote (see https://rangevoting.org/ ):
> > -1..+1 keep using Bugzilla for issue management
> > -1..+1 migrate to GitHub Issues
> > -1..+1 migrate to ASF JIRA
> >
> > Here's my vote:
> > -0.8 keep using Bugzilla
> > +1 migrate to GitHub Issues
> > +0.8 migrate to ASF JIRA
> >
> > AFAIK there is no automatic issue migration, so any change would involve
> > dealing with issues somehow.
> > AFAIK there are no legal implications, so we can use either issue
> tracking
> > system.
> >
> > Bugzilla:
> > Pros:
> > * It worked more-or-less fine for ages
> > Cons:
> > * Bugzilla is less widespread at the moment. I think only 10 or so ASF
> > projects are listed at https://bz.apache.org/bugzilla/enter_bug.cgi
> > * There's no integration between pull requests and issues
> >
> > GitHub issues:
> > Pros:
> > * GitHub issues integrate well with pull requests and discussions. I
> think
> > the vast majority of contributions come via pull requests
> > * It is probably easier for external contributors. In practice, GitHub
> is a
> > de-facto standard now
> > * Issues integrate well with GitHub Actions. We do not use it
> extensively,
> > however, I think we can label issues/prs, and things like that
> > * Query language is more or less known (for instance, I do use
> > https://github.com/gradle/gradle/issues a lot)
> > * Rich comment formatting: code samples, images
> > Cons:
> > * Only 20 external collaborators for issue triage (see
> >
> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-AssigningexternalcollaboratorswiththetriageroleonGitHub
> >  )
> > * Non-ASF-hosted solution. I think this is a low risk.
> >
> > JIRA:
> > Pros:
> > * Other ASF projects use JIRA. For example, INFRA. So PMCs and committers
> > can't really avoid JIRA :)
> > * It works more-or-less well for Apache Calcite (I'm a member of PMC for
> > Calcite)
> > * Query language is more or less known
> > * Search can find similar cases across different ASF projects. For
> > instance, I used ASF JIRA to figure out how (and which) projects enable
> > GitHub Discussions.
> > * Rich comment formatting: code samples, images
> > * Non-committers can get access to JIRA for issue triage
> > * ASF-hosted solution. We are safe if GitHub adds limits in the future
> > (e.g. "no more than 20 repos per organization")
> > Cons:
> > * Somebody might think JIRA is "heavyweight", however, it looks like the
> > last couple of years ASF JIRA works just fine
> >
> > Vladimir
> >
>
>

-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: About SSL properties in JMeter and their use in Java / HC Impl and Recorder

[Philippe Mouawad]

Hello,
I updated PR.

Shall I merge it.

Regards

On Monday, November 15, 2021, Vladimir Sitnikov 
wrote:

> 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 goes where.
> It might be JOrphanUtils.split(JMeterUtils.getPropOrDefault(...)...) would
> avoid creating a String fields,
> so you don't have to invent two names for basically the same thing.
>
> ---
>
> It is a bit sad to have different separators for different properties.
> Do you think commas could be used as separators?
>
> Vladimir
>


-- 
Cordialement.
Philippe Mouawad.

Re: JMeter DSL discussion

[Philippe Mouawad]

Hello,

Few questions regarding the feature :

- How do you see the DSL for plugins ?
- How will JSR223 custom code be used inside DSL ?


Also few notes inline below

Regards
On Saturday, November 20, 2021, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >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 org.apache.jmeter.experimental.dsl
> package/module name
>
> I think experimental works better with annotations like
> @OptIn(Experimental)
> If you put experimental into a package name, you can't remove it without
> breaking the usages.


Looks good to me

>
> A single .dsl. package would help indeed, so users could import
> jmeter.dsl.* and use the functions rather than import every package or
> class individually.
> On the other hand, the users won't be able to unimport features they do not
> need


That looks acceptable to me

>
> > Kotlin has a very similar string template format to JMeter, is there a
> good way to distinguish those, or guard the JMeter ones?
>
> That is indeed a problem.
> I've idea what would work the best to resolve it.
> Changing syntax to %{..} might work.
> Changing syntax to explicit expr("__javaScript(...)") might work as well.
> Making variables explicit might work as well. For instance, we can declare
> "variable holder", and pass it to regex extractor, and later use it for
> retrieving the result.
> That would reduce the number of cases where $ is needed in the test plan as
> every use of $ is basically a place for hidden error like "use of undefined
> variable", and so on


is your suggestion about changing JMeter ${var} syntax or do I
misunderstand ?


>
> > It seems, that `aggregateReport` has its parameters given by a closure
> (is that the right name?) , while `http` per positional parameter. Is
> this a Kotlin feature, that we can mix those, or is it only a first
> example and showing different ways of settings parameters on the elements?
>
> Kotlin has positioned parameters, it has named parameters, parameters can
> have default values (even computed values based on other parameters), and
> the final lambda can be outside of the parenthesis.
>
> >And a completely other construction site: Currently JMeter uses a global
> context, which could trip off users of the dsl, when they want to
> execute plans in parallel. Would this be worse, than now?
>
> Do you mean static context when running the plan?
>
> Vladimir
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: Make element disabling configurable via ${..} expressions

[Philippe Mouawad]

Hello,
No there is not such way, only possible hacks.

For non scoped elements, there is ability to work with If.
Yur proposal or a notion of Profile would be nice.

Regards

On Fri, Nov 19, 2021 at 1:43 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> 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 ${...}, however, there's no way to put an
> expression into the checkbox.
>
> Vladimir
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: About SSL properties in JMeter and their use in Java / HC Impl and Recorder

[Philippe Mouawad]

Hello,
https://github.com/apache/jmeter/pull/677

Regards

On Sun, Nov 14, 2021 at 11:13 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> 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 https.socket.protocols
>
> Vladimir
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: Questions following switch from Eclipse to IntelliJ

[Philippe Mouawad]

Thanks for rapid answer.
My notes inline below.

On Sun, Nov 14, 2021 at 7:09 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> 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
> raises is "do you trust the project?"
>

What do you mean ?


> Philippe>2) I used gradle runGui task to debug JMeter, is it the advised
> way ?
>
> Both debugging runGui and debugging individual tests should work.
>

Yes it works.

>
> Earlier I created a "run configuration" that launches NewDriver with a
> classpath of "dist" module,
>
Maybe you can share this configuration in the document.
Does it make startup faster ?
Does it allow code reload during debugging ?

however, I debug tests or debug runGui task.
>
> Vladimir
>


-- 
Cordialement.
Philippe Mouawad.

Questions following switch from Eclipse to IntelliJ

[Philippe Mouawad]

Hello,
I have switched today to using IntelliJ as my future hopefully preferred
IDE for JMeter.

I followed below tutorial which is not up to date anymore I think:

   -
   
https://github.com/apache/jmeter/blob/c7279348335b820c35ee570462cb2e0b4eb1c370/CONTRIBUTING.md


1) Using IntelliJ IDEA 2021.2.3, I didn't get a popup to be able to select:

   - Make sure Create separate module per source set is selected
   - Make sure Use default gradle wrapper is selected

2) I used gradle runGui task to debug JMeter, is it the advised way ?
If not, maybe the advised way should be documented.


-- 
Regards
Philippe M.

About SSL properties in JMeter and their use in Java / HC Impl and Recorder

[Philippe Mouawad]

Hello,

I see few problems in this field in JMeter.

1) Cipher Suite is configurable through 2 properties:
Documented one called "https.cipherSuites" in HttpSSLProtocolSocketFactory
Undocumented one called "https.socket.ciphers" in
LazyLayeredConnectionSocketFactory

For HC4, the latter is the used one
For Java, the first one is used


I suggest we switch in LazyLayeredConnectionSocketFactory
https.socket.ciphers to https.cipherSuites as the latter is documented

2) It seems it's not possible to control cipher suites and protocols in
HTTP(S) Test Script Recorder, we only allow setting SSLContext algo but
neither SSLSocket protocols nor cipherSuites.

I suggest we set both using the values of properties in Proxy#startSSL:

   - https.cipherSuites
   - https.socket.protocols


Are you ok with my analysis and proposals ?
Thanks
-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: Move "precise throughput computation" to thread group

[Philippe Mouawad]

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?
>
> Currently, the code simulates an open model, and it does not limit the
> number of threads it spawns.
>
> Vladimir
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: Move "precise throughput computation" to thread group

[Philippe Mouawad]

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 what all say.

>
> 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 question to ask.
>

I think it is :-)

> The adoption grows (e.g. see
>
> https://developers.googleblog.com/2021/11/announcing-kotlin-support-for-protocol.html
> ),
> and developers can get productive in 2 weeks.
>

Maybe if you use Kotlin every day within your work (because you have to
otherwise you can leave) then maybe
you'll be able to move forward , but I don't believe that in 2 weeks you'll
be the equivalent of what you are in Java.

Now if you don't work in Kotlin, and have to learn it on your little
remaining time (not speaking about personal , family time) , then
for sure in 2 weeks I won't be.


> The language is statically typed, so there are no features that magically
> appear in the runtime.
> What you see is what gets executed.
>
> So I am sure, fixing a bug in Kotiln code is not dramatically different
> from fixing a bug in Java code.
> It might be even easier than fixing a bug in Groovy code since Groovy is
> dynamic.
>
> If fixing a bug or adding a feature requires creating new classes, you can
> still create Java classes.
> However, once you try Kotlin, you won't look back.
>
> Philippe>I am ok to use Kotlin when it brings missing features, but not
> when we can
> Philippe>use Java, in this particular case, I don't think those classes
> should be in
> Philippe>Kotlin in the PR:
>
> What do you think
> of scheduleParser.kt, scheduleTokenizer.kt, ThreadScheduleTest.kt?
>
> I think the files are more feature-dense than the files you listed, and if
> you are OK with reading scheduleParser.kt, scheduleTokenizer.kt,
> then PoissonRamp.kt, PreciseThreadGroup.kt, etc should not be a problem.
>

I said that as scheduleParser.kt, scheduleTokenizer.kt are related to DSL,
I am ok with them being in Kotlin.
I didn't say they were easy to read.


> Philippe>ok for DSL as I already wrote, benefit is clear
>
> I can easily imagine that making the existing classes dsl-friendly might
> require modifications.
> There might be dsl-only interfaces or classes. Do you mean we'll have to
> discuss the language for each and every class?
>
> Philippe>it's not used in the last  PR right ?
>
> No, I do not use coroutines and jetpack compose for the new thread group.
>
> Philippe>Finalizing move to Java 11 without all the flags might be a first
> step.
>
What about this ?

> Philippe>What about compatibility of the libraries we use ? I think many
> are not
> Philippe>compatible.
>
> Frankly speaking, I've no idea, however, I assume we can use Java 17
> without modules.
> In other words, we should be good provided the libraries do not use Unsafe
> and reflection against core Java classes.
> Our CI tests run with Java 14 now, and running with 17 should not be that
> different.
> Of course, migrating to Java modules would be a non-trivial task.
>

> However, I agree making all the clients use Java 17+ would be a non-trivial
> exercise for testing, documenting, etc.
>
I agree

> That means records, switch expressions, etc, are not really available for
> JMeter code, while Kotlin provides similar constructs right now.
>
> Vladimir
>


-- 
Cordialement.
Philippe Mouawad.

Re: Move "precise throughput computation" to thread group

[Philippe Mouawad]

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
> requirements)
> Frankly speaking, the chart was the last feature I added, and it was more
> of a coincidence.
>
no problem for this one, I agree it's very hard to find a good OS friendly
API for charting in Java.

b) Kotlin covers null safety <-- in my opinion, this is huge
>
this is not significant enough for me

c) There are cases for having Kotlin in project where Java solutions do not
> exist: DSL for programmatic testplan generation,

ok for DSL as I already wrote, benefit is clear


> coroutines (well, Loom +
> virtual threads might be just enough, however, the release date is
> moot),


it's not used in the last  PR right ?

JetPack
> Compose might be a good fit for UI
> d) Kotlin is less verbose, and there are lots of convenience things like
> if-expressions, when-expressions, readonly lists and maps, and so on.
>

Maybe but in the current active members of the team how many  are as good
in Kotlin as in Java ?
Although it's great you're contributing actively these last weeks, what
will happen when you'll be less
active ?
I must say I consider myself a very junior in Kotlin, while I hope I am a
bit better in Java.
And regarding verbosity, sometimes it gives  more readable/immediately
understandable code IMO.

e) Kotlin is easier to read: less verbosity yield better signal to noise
> ratio. Even though, IDEs can generate all the Java boilerplate code, and I
> do not type it, I still have to read it.
>

It's an opinion. I don't have the same. As of me, I don't find it easier to
read at all.

f) The language interops with Java just fine, and it does not require data
> conversion.
>
Agreed.


> I do not intend to rewrite the existing code in Kotlin in one day, however,
> I think it makes sense to write new code in Kotlin.
>

I think that would require a discussion before going further.
I am ok to use Kotlin when it brings missing features, but not when we can
use Java, in this particular case, I don't think those classes should be in
Kotlin in the PR:

   -
   src/core/src/main/kotlin/org/apache/jmeter/threads/precise/PoissonRamp.kt
   -
   
src/core/src/main/kotlin/org/apache/jmeter/threads/precise/PreciseThreadGroup.kt
   -
   
src/core/src/main/kotlin/org/apache/jmeter/threads/precise/PreciseThreadGroupController.kt
   -
   
src/core/src/main/kotlin/org/apache/jmeter/threads/precise/ThreadScheduleProcessGenerator.kt
   -
   
src/core/src/main/kotlin/org/apache/jmeter/threads/precise/gui/PreciseThreadGroupGui.kt

Those are critical classes if the element is used and we will have to dig
into edgy cases , as of me, I don't feel confident enough
maintaining current PR code
@All members, what do you think ?



> By the way, it might be time to bump language version to Java 17 for JMeter
> code. Moving to 17 would ease some of the pain points (records, switch
> expressions), however, it does not resolve all of them.
>

Finalizing move to Java 11 without all the flags might be a first step.
What about compatibility of the libraries we use ? I think many are not
compatible.


> Vladimir
>


-- 
Regards
Philippe M.
Ubik-Ingenierie

Re: Move "precise throughput computation" to thread group

[Philippe Mouawad]

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 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 last month, so my opinion does
> not count as much as a more active contributor as Felix.
>
> But if I was as active as I have been in the past (I may be more active in
> the future), I would tend to stick to Java unless Kotlin brings something
> that is not available in Java.
> In the past, there was this PR https://github.com/apache/jmeter/pull/540
> which was using Kotlin for a good reason I think.
> In this particular case , I don't see it.
>
> Regards
> Philippe
>
>
> On Tue, Nov 2, 2021 at 9:58 PM Antonio Gomes Rodrigues 
> wrote:
>
>> 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 <
>> sitnikov.vladi...@gmail.com>
>> a écrit :
>>
>> > 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 dependencies become "core"
>> > dependencies. I've no idea what to do with that,
>> > and we might probably want to move UI classes to core-ui module or
>> > something like that.
>> >
>> > The current dependency diff is as follows:
>> >
>> > 54852334 => 71166807 bytes (+16314473 bytes)
>> > 99 => 134 files (+35)
>> >
>> >   +   17536 annotations-13.0.jar
>> >   -   18538 annotations-16.0.2.jar
>> >   +  507197 base-portable-jvm-2.1.0.jar
>> >   +  485809 batik-anim-1.14.jar
>> >   +  424624 batik-awt-util-1.14.jar
>> >   +  703757 batik-bridge-1.14.jar
>> >   +  112373 batik-codec-1.14.jar
>> >   +8433 batik-constants-1.14.jar
>> >   +  330318 batik-css-1.14.jar
>> >   +  184487 batik-dom-1.14.jar
>> >   +   10238 batik-ext-1.14.jar
>> >   +  192087 batik-gvt-1.14.jar
>> >   +   11466 batik-i18n-1.14.jar
>> >   +   76875 batik-parser-1.14.jar
>> >   +   25876 batik-script-1.14.jar
>> >   +6663 batik-shared-resources-1.14.jar
>> >   +  232734 batik-svg-dom-1.14.jar
>> >   +  227514 batik-svggen-1.14.jar
>> >   +  129300 batik-transcoder-1.14.jar
>> >   +  127477 batik-util-1.14.jar
>> >   +   33866 batik-xml-1.14.jar
>> >   +   32033 kotlin-logging-jvm-2.0.5.jar
>> >   + 2993765 kotlin-reflect-1.5.21.jar
>> >   + 1505952 kotlin-stdlib-1.5.31.jar
>> >   +  198322 kotlin-stdlib-common-1.5.31.jar
>> >   +   22986 kotlin-stdlib-jdk7-1.5.31.jar
>> >   +   16121 kotlin-stdlib-jdk8-1.5.31.jar
>> >   +  792176 kotlinx-html-jvm-0.7.3.jar
>> >   +  196707 lets-plot-batik-2.1.0.jar
>> >   + 3593892 lets-plot-common-2.1.0.jar
>> >   +  627895 plot-api-jvm-3.0.2.jar
>> >   +  882509 plot-base-portable-jvm-2.1.0.jar
>> >   +  792534 plot-builder-portable-jvm-2.1.0.jar
>> >   +  115007 plot-common-portable-jvm-2.1.0.jar
>> >   +  454864 plot-config-portable-jvm-2.1.0.jar
>> >   +  173932 vis-svg-portable-jvm-2.1.0.jar
>> >   +   85686 xml-apis-ext-1.3.04.jar
>> >
>> > Vladimir
>> >
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: Move "precise throughput computation" to thread group

[Philippe Mouawad]

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 last month, so my opinion does
not count as much as a more active contributor as Felix.

But if I was as active as I have been in the past (I may be more active in
the future), I would tend to stick to Java unless Kotlin brings something
that is not available in Java.
In the past, there was this PR https://github.com/apache/jmeter/pull/540
which was using Kotlin for a good reason I think.
In this particular case , I don't see it.

Regards
Philippe


On Tue, Nov 2, 2021 at 9:58 PM Antonio Gomes Rodrigues 
wrote:

> 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 <
> sitnikov.vladi...@gmail.com>
> a écrit :
>
> > 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 dependencies become "core"
> > dependencies. I've no idea what to do with that,
> > and we might probably want to move UI classes to core-ui module or
> > something like that.
> >
> > The current dependency diff is as follows:
> >
> > 54852334 => 71166807 bytes (+16314473 bytes)
> > 99 => 134 files (+35)
> >
> >   +   17536 annotations-13.0.jar
> >   -   18538 annotations-16.0.2.jar
> >   +  507197 base-portable-jvm-2.1.0.jar
> >   +  485809 batik-anim-1.14.jar
> >   +  424624 batik-awt-util-1.14.jar
> >   +  703757 batik-bridge-1.14.jar
> >   +  112373 batik-codec-1.14.jar
> >   +8433 batik-constants-1.14.jar
> >   +  330318 batik-css-1.14.jar
> >   +  184487 batik-dom-1.14.jar
> >   +   10238 batik-ext-1.14.jar
> >   +  192087 batik-gvt-1.14.jar
> >   +   11466 batik-i18n-1.14.jar
> >   +   76875 batik-parser-1.14.jar
> >   +   25876 batik-script-1.14.jar
> >   +6663 batik-shared-resources-1.14.jar
> >   +  232734 batik-svg-dom-1.14.jar
> >   +  227514 batik-svggen-1.14.jar
> >   +  129300 batik-transcoder-1.14.jar
> >   +  127477 batik-util-1.14.jar
> >   +   33866 batik-xml-1.14.jar
> >   +   32033 kotlin-logging-jvm-2.0.5.jar
> >   + 2993765 kotlin-reflect-1.5.21.jar
> >   + 1505952 kotlin-stdlib-1.5.31.jar
> >   +  198322 kotlin-stdlib-common-1.5.31.jar
> >   +   22986 kotlin-stdlib-jdk7-1.5.31.jar
> >   +   16121 kotlin-stdlib-jdk8-1.5.31.jar
> >   +  792176 kotlinx-html-jvm-0.7.3.jar
> >   +  196707 lets-plot-batik-2.1.0.jar
> >   + 3593892 lets-plot-common-2.1.0.jar
> >   +  627895 plot-api-jvm-3.0.2.jar
> >   +  882509 plot-base-portable-jvm-2.1.0.jar
> >   +  792534 plot-builder-portable-jvm-2.1.0.jar
> >   +  115007 plot-common-portable-jvm-2.1.0.jar
> >   +  454864 plot-config-portable-jvm-2.1.0.jar
> >   +  173932 vis-svg-portable-jvm-2.1.0.jar
> >   +   85686 xml-apis-ext-1.3.04.jar
> >
> > Vladimir
> >
>


-- 
Cordialement.
Philippe Mouawad.

Re: [DISCUSS] JMeter samples collection

[Philippe Mouawad]

Hello,
It's a good idea

Regards

On Tue, Oct 19, 2021 at 1:17 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> 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
> * docker-compose-influx: a docker-compose-based project that sends data to
> InfluxDB
> * gradle-java-programmatic-test-plan: programmatic test plan generation
> with Java"
> * ...
>
> It would be useful for both users (they could use the samples for bootstrap
> purposes), and it would be useful for JMeter to test integrations.
>
> I'm not sure if that would be compliant with the ASF rules though (see [2],
> [3]).
>
> WDYT?
>
> [1] https://docs.gradle.org/current/samples/index.html
> [2]
>
> https://lists.apache.org/thread.html/f3d7efbb9000ee166b3f2129ea54855b1cd79a461b80876820e0d464%401432336409%40%3Cdev.jmeter.apache.org%3E
> [3] https://www.apache.org/foundation/marks/linking#productsupport
>
> Vladimir
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: [jmeter] branch master updated: Make the estimator used for calculating percentiles on the dashboard configurable

[Philippe Mouawad]

xdocs/usermanual/properties_reference.xml
> index de95a86..5e1565d 100644
> --- a/xdocs/usermanual/properties_reference.xml
> +++ b/xdocs/usermanual/properties_reference.xml
> @@ -1161,7 +1161,11 @@ JMETER-SERVER
>  Setting this value too high can lead to OOM Backend metrics sliding
> window size
>  Defaults to: 5000
>  
> -
> +
> +Specify the https://commons.apache.org/proper/commons-math/javadocs/api-3.5/org/apache/commons/math3/stat/descriptive/rank/Percentile.EstimationType.html;>Percentile
> Estimation Type to use.
> +To make the values from the dashboard compatible with the Aggragate
> Report, use the value R_3.
> +Defaults to: LEGACY
> +
>  
>  Backend metrics window mode.
>  Possible values:
>


-- 
Cordialement.
Philippe Mouawad.

Re: Starting Jmeter without the logo

[Philippe Mouawad]

Hello Felix,

Regarding the patch proposal, IMO there are already too much properties in
JMeter.
Do you think we should add one for splash screen disabling, knowing that as
suggested root cause of issue is just somewhere else ?


Regards
Philippe

On Saturday, April 10, 2021, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 10.04.21 um 09:23 schrieb Adrian Sp:
> > Hi,
> >
> > It's an open source project. Just check the code and see how it works
> > under the hood if you feel comfortable with this.
>
> Apart from the sources there are other places, where you might be able
> to find the good stuff, bugzilla for example ;)
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64658
>
> >
> > However, if you have startup problems, the logo is the last of your
> > worries. You need to approach this from a completely different angle.
>
>
> +1
>
> In the linked issue above, the solution was to disable undo for JMeter,
> which is a pity, but if someone has the knowledge to work on that part,
> feel welcome.
>
> If you still want to disable the splash screen, there is a patch
> referenced, that should do that.
>
> Felix
>
> >
> > Cheers,
> > Adrian.
> >
> > On Fri, Apr 9, 2021 at 9:52 PM Tong Sun  wrote:
> >> Hi,
> >>
> >> Is it possible to start Jmeter without the logo?
> >>
> >> My Jmeter has a start up problem and I have to move above to see what's
> wrong.
> >>
> >> It'll be nice to have the logo not in the way.
> >>
> >> Thanks
> >>
> >> -
> >> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
> >> For additional commands, e-mail: user-h...@jmeter.apache.org
> >>
> > -
> > To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
> > For additional commands, e-mail: user-h...@jmeter.apache.org
> >
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: About adding JSonPointer extractor

[Philippe Mouawad]

Hello,

Well in the end I think it’s not a good idea, we already have json-path,
jmes and json-pointer looks a bit limited if I understood it well.
I thought it might be interesting for dev audience using it but in the end
it’s better not to include it.

Regards

On Saturday, February 6, 2021, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

> Which problem would you like to address with the addition?
>
> Felix
>
> Am 26.01.21 um 20:39 schrieb Philippe Mouawad:
> > Hello,
> > What do you think of adding a JSONPointer Extractor ?
> >
> >
> >- https://www.baeldung.com/json-pointer
> >- https://tools.ietf.org/html/rfc6901
> >
> >
>


-- 
Cordialement.
Philippe Mouawad.

About adding JSonPointer extractor

[Philippe Mouawad]

Hello,
What do you think of adding a JSONPointer Extractor ?


   - https://www.baeldung.com/json-pointer
   - https://tools.ietf.org/html/rfc6901


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: [VOTE] Release JMeter 5.4.1 RC2

[Philippe Mouawad]

Hello,
Thanks for RM milamber and for fixes on RC1 Felix.
[X] +1  I support this release

Regards
Philippe M.

On Sun, Jan 17, 2021 at 2:20 PM Milamber  wrote:

> Hello,
>
> The second release candidate for JMeter 5.4.1 (e7ff6eddd3) has been
> prepared, and your votes are solicited.
>
> This release is mainly a bugfix release.
>
> Please, test this release candidate (with load tests and/or functional
> tests) using Java 8+ on Linux/Windows/macOS, especially on the changes.
> Feedback is very welcome within the next 72 hours.
>
> You can read the New and Noteworthy section with some screenshots to
> illustrate improvements and full list of changes at:
> https://apache.github.io/jmeter-site-preview/site/changes.html
>
> JMeter is a Java desktop application designed to load test functional
> behavior and measure performance. The current version targets Java 8+
>
> Download - Archives/hashes/sigs:
> https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-5.4.1-rc2
> (dist revision 45465)
>
> RAT report:
> https://apache.github.io/jmeter-site-preview/rat/
>
> SHA512 hashes of archives for this vote: see footnote [1]
>
> Site preview is here:
> https://apache.github.io/jmeter-site-preview/site/
>
> JavaDoc API preview is here:
> https://apache.github.io/jmeter-site-preview/site/api/
>
> Maven staging repository is accessible here:
>
> https://repository.apache.org/content/repositories/orgapachejmeter-1070/org/apache/jmeter/
>
> Tag:
>
> https://gitbox.apache.org/repos/asf?p=jmeter.git;a=tag;h=refs/tags/v5.4.1-rc2
>
> Keys are here:
> https://www.apache.org/dist/jmeter/KEYS
>
> N.B.
> To create the distribution and test JMeter: "./gradlew build -Prelease
> -PskipSign".
>
> JMeter 5.4.1 requires Java 8 or later to run.
>
> The artifacts were built with
>Java(TM) SE Runtime Environment Oracle Corporation (build 1.8.0_271-b09)
>Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build
> 25.271-b09, mixed mode)
>
> Some known issues and incompatible changes are listed on changes page.
>
> https://apache.github.io/jmeter-site-preview/site/changes.html#Known%20problems%20and%20workarounds
>
>
> All feedback and vote are welcome.
>
> [  ] +1  I support this release
> [  ] +0  I am OK with this release
> [  ] -0  OK, but
> [  ] -1  I do not support this release (please indicate why)
>
> The vote will remain open for at least 72 hours.
>
> The PMC members please indicate the mention "(binding)" with your vote.
>
>
> Note: If the vote passes, the intention is to release the archive files
> and rename the RC tag as the release tag.
>
> Thanks in advance!
>
> Milamber
>
> ===
> [1] SHA512 hashes of archives for this vote:
>
>
> bfc0faa84769b58c1fd498417b3a5c65749f52226bd6e3533f08ca7ea4a3798bb8d2cbd7091b443dd6837f3cbea5565c3c18e6497b40bec95616bf44dfdf590d
> *apache-jmeter-5.4.1.tgz
>
> 78e41e5fbbc3d09319b9c2593286a6326b3cb111377944b2f41650a0c5adcb131a38898e7b856bd034557015d6e6b150d4ad585de780d622e28e5e62eb8bf82d
> *apache-jmeter-5.4.1.zip
>
> 4c03c92d52860bbf10577440a90623727df1d5c638dbc0b03f1822a3a81abfe76e05a2e696aa89969e9b8a6d6cbbef75661ee7b9f234bed3fb730ee9f74d2f27
> *apache-jmeter-5.4.1_src.tgz
>
> 6b5743ea21f12ff4725666bc0bff2351e82ef23dd2825197ce8f4fa5a3bacc54a3c04c7acc02561ec499d8ff919114fba484f5dea337d5e1548e121d0f650077
> *apache-jmeter-5.4.1_src.zip
>
>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.4.1 RC1

[Philippe Mouawad]

Hello,
Ok by me also.

Regards

On Friday, January 15, 2021, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 15.01.21 um 13:16 schrieb Philippe Mouawad:
> > Hello Milamber,
> > Can you wait a bit, Felix wantes to commit another thing and we may want
> to
> > change a bit the tika fix
>
> I didn't want to commit the other thing :) I wait for the next round
> after the release. But I did change the loading of the tika-config.xml
> (it took way more commits, that I would like to admit. Sorry for the
> noise).
>
> I tested those changes on linux and windows and they seem to work. No
> warnings are emitted and the tool menu has the curl parser action
> available and it seems to work.
>
> So I think I am done.
>
> Felix
>
> >
> > Regards
> >
> > On Friday, January 15, 2021, Milamber  wrote:
> >
> >> Hello,
> >>
> >> Due of the issue (warning tika), I cancel the vote and start the next
> RC2
> >> asap.
> >>
> >> Milamber
> >>
> >> On 11/01/2021 16:33, Milamber wrote:
> >>
> >>> Hello,
> >>>
> >>> The first release candidate for JMeter 5.4.1 (032b55e3c8) has been
> >>> prepared, and your votes are solicited.
> >>>
> >>> This release is mainly a bugfix release.
> >>>
> >>> Please, test this release candidate (with load tests and/or functional
> >>> tests) using Java 8+ on Linux/Windows/macOS, especially on the changes.
> >>> Feedback is very welcome within the next 72 hours.
> >>>
> >>> You can read the New and Noteworthy section with some screenshots to
> >>> illustrate improvements and full list of changes at:
> >>> https://apache.github.io/jmeter-site-preview/site/changes.html
> >>>
> >>> JMeter is a Java desktop application designed to load test functional
> >>> behavior and measure performance. The current version targets Java 8+
> >>>
> >>> Download - Archives/hashes/sigs:
> >>> https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-5.4.1-rc1
> >>> (dist revision 45323)
> >>>
> >>> RAT report:
> >>> https://apache.github.io/jmeter-site-preview/rat/
> >>>
> >>> SHA512 hashes of archives for this vote: see footnote [1]
> >>>
> >>> Site preview is here:
> >>> https://apache.github.io/jmeter-site-preview/site/
> >>>
> >>> JavaDoc API preview is here:
> >>> https://apache.github.io/jmeter-site-preview/site/api/
> >>>
> >>> Maven staging repository is accessible here:
> >>> https://repository.apache.org/content/repositories/orgapache
> >>> jmeter-1069/org/apache/jmeter/
> >>>
> >>> Tag:
> >>> https://gitbox.apache.org/repos/asf?p=jmeter.git;a=tag;h=
> >>> refs/tags/v5.4.1-rc1
> >>>
> >>> Keys are here:
> >>> https://www.apache.org/dist/jmeter/KEYS
> >>>
> >>> N.B.
> >>> To create the distribution and test JMeter: "./gradlew build -Prelease
> >>> -PskipSign".
> >>>
> >>> JMeter 5.4.1 requires Java 8 or later to run.
> >>>
> >>> The artifacts were built with
> >>>   Java(TM) SE Runtime Environment Oracle Corporation (build
> 1.8.0_221-b11)
> >>>   Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build
> 25.221-b11,
> >>> mixed mode)
> >>>
> >>> Some known issues and incompatible changes are listed on changes page.
> >>> https://apache.github.io/jmeter-site-preview/site/changes.
> >>> html#Known%20problems%20and%20workarounds
> >>>
> >>>
> >>> All feedback and vote are welcome.
> >>>
> >>> [  ] +1  I support this release
> >>> [  ] +0  I am OK with this release
> >>> [  ] -0  OK, but
> >>> [  ] -1  I do not support this release (please indicate why)
> >>>
> >>> The vote will remain open for at least 72 hours.
> >>>
> >>> The PMC members please indicate the mention "(binding)" with your vote.
> >>>
> >>>
> >>> Note: If the vote passes, the intention is to release the archive files
> >>> and rename the RC tag as the release tag.
> >>>
> >>> Thanks in advance!
> >>>
> >>> Milamber
> >>>
> >>> ===
> >>> [1] SHA512 hashes of archives for this vote:
> >>>
> >>> 387e3c249e2b06cfe0b1b9417a17414f79337e8d0a0baec34afd9f16c009
> >>> 474bcec7773686ba438dd5c7bee70183222af62d694321c2f78ff18250fa690c0061
> >>> *apache-jmeter-5.4.1.tgz
> >>> f65c14073befc60ec4c46d4734cfbb0d081a385c395db65a4f933bf6629b
> >>> 46bbb9617f2139eb2e2c34bd99618c6d2309eee629107d87136c41e0ebd463441eff
> >>> *apache-jmeter-5.4.1.zip
> >>> 0cdd8e5024ed27ffe563eff9c393e703aa705858d11dfe6f7201a0e02cb2
> >>> 61858fe74d4e8990ad06e87d58e8f9449fe3a31f0e2389e6121f1d5cf9bc73649950
> >>> *apache-jmeter-5.4.1_src.tgz
> >>> ed78a896af42b49a0d65b2ec860a2902552f6a27077164e73f57f18a1de1
> >>> f31e8e53b967540bba6cfebd9b8d980526aca91700ceb4f9fda8b6178f819727587d
> >>> *apache-jmeter-5.4.1_src.zip
> >>>
> >>>
> >>>
> >>>
> >>>
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: [jmeter] 01/02: Partly revert "Silence warning of tika about missing sqlite-jdbc dependency"

[Philippe Mouawad]

Thanks !

On Fri, Jan 15, 2021 at 7:16 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 15.01.21 um 19:04 schrieb Felix Schumacher:
> > Am 15.01.21 um 18:52 schrieb Philippe Mouawad:
> >> Hi Felix,
> >> For simplicity and impact on Maven plugin , why not embed
> tika-config.xml
> >> in core (src/main/resources) ?
> >
> > Will try to do it.
>
> Done
>
> Felix
>
> >
> > Felix
> >
> >> Regards
> >>
> >> On Fri, Jan 15, 2021 at 6:39 PM  wrote:
> >>
> >>> This is an automated email from the ASF dual-hosted git repository.
> >>>
> >>> fschumacher pushed a commit to branch master
> >>> in repository https://gitbox.apache.org/repos/asf/jmeter.git
> >>>
> >>> commit 803f69f8484aa34c78ab160d1474db56bf0aff47
> >>> Author: Felix Schumacher 
> >>> AuthorDate: Fri Jan 15 15:34:11 2021 +0100
> >>>
> >>> Partly revert "Silence warning of tika about missing sqlite-jdbc
> >>> dependency"
> >>>
> >>> This reverts commit aa6c7633d6ff8125d588071cb4739930a847e1fa.
> >>>
> >>> Instead of using a system property and extending the shell scripts
> to
> >>> start
> >>> JMeter, we now configure Tika inside the client code directly. The
> used
> >>> config file stays at the same location and has still the same
> content.
> >>> ---
> >>>  .gitignore|  2 +-
> >>>  bin/jmeter|  2 +-
> >>>  bin/jmeter.bat|  2 +-
> >>>  .../protocol/http/gui/action/ParseCurlCommandAction.java  | 15
> >>> ++-
> >>>  4 files changed, 17 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/.gitignore b/.gitignore
> >>> index 61df09b..21abad6 100644
> >>> --- a/.gitignore
> >>> +++ b/.gitignore
> >>> @@ -51,7 +51,7 @@
> >>>  /bin/*.jmx
> >>>  /bin/*.jtl
> >>>  /bin/*.xml
> >>> -# We need log4j2.xml even though we want to exclude xml created by
> batch
> >>> tests
> >>> +# We need log4j2.xml and tika-config.xml even though we want to
> exclude
> >>> xml created by batch tests
> >>>  !/bin/log4j2.xml
> >>>  !/bin/tika-config.xml
> >>>
> >>> diff --git a/bin/jmeter b/bin/jmeter
> >>> index fae82ff..5d5b949 100755
> >>> --- a/bin/jmeter
> >>> +++ b/bin/jmeter
> >>> @@ -187,7 +187,7 @@ esac
> >>>
> >>>  # Always dump on OOM (does not cost anything unless triggered)
> >>>  DUMP="-XX:+HeapDumpOnOutOfMemoryError"
> >>> -SYSTEM_PROPS="-Djava.security.egd=file:/dev/urandom
> >>> -Dtika.config=${JMETER_HOME}/bin/tika-config.xml"
> >>> +SYSTEM_PROPS="-Djava.security.egd=file:/dev/urandom"
> >>>  SERVER="-server"
> >>>
> >>>  if [ -z "${JMETER_COMPLETE_ARGS}" ]; then
> >>> diff --git a/bin/jmeter.bat b/bin/jmeter.bat
> >>> index 2c96b54..80fc534 100644
> >>> --- a/bin/jmeter.bat
> >>> +++ b/bin/jmeter.bat
> >>> @@ -162,7 +162,7 @@ if not defined GC_ALGO (
> >>>  set GC_ALGO=-XX:+UseG1GC -XX:MaxGCPauseMillis=100
> >>> -XX:G1ReservePercent=20
> >>>  )
> >>>
> >>> -set SYSTEM_PROPS=-Djava.security.egd=file:/dev/urandom
> >>> -Dtika.config=%JMETER_BIN%tika-config.xml
> >>> +set SYSTEM_PROPS=-Djava.security.egd=file:/dev/urandom
> >>>
> >>>  rem Always dump on OOM (does not cost anything unless triggered)
> >>>  set DUMP=-XX:+HeapDumpOnOutOfMemoryError
> >>> diff --git
> >>>
> a/src/protocol/http/src/main/java/org/apache/jmeter/protocol/http/gui/action/ParseCurlCommandAction.java
> >>>
> b/src/protocol/http/src/main/java/org/apache/jmeter/protocol/http/gui/action/ParseCurlCommandAction.java
> >>> index d610b52..d601618 100644
> >>> ---
> >>>
> a/src/protocol/http/src/main/java/org/apache/jmeter/protocol/http/gui/action/ParseCurlCommandAction.java
> >>> +++
> >>>
> b/src/protocol/http/src/main/java/org/apache/jmeter/protocol/http/gui/action/ParseCurlCommandAction.java
> >>> @@ -29,6 +29,7 @@ import java.io.IOException;
> >>>

Re: [jmeter] 01/02: Partly revert "Silence warning of tika about missing sqlite-jdbc dependency"

[Philippe Mouawad]

Hi Felix,
For simplicity and impact on Maven plugin , why not embed tika-config.xml
in core (src/main/resources) ?

Regards

On Fri, Jan 15, 2021 at 6:39 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> fschumacher pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/jmeter.git
>
> commit 803f69f8484aa34c78ab160d1474db56bf0aff47
> Author: Felix Schumacher 
> AuthorDate: Fri Jan 15 15:34:11 2021 +0100
>
> Partly revert "Silence warning of tika about missing sqlite-jdbc
> dependency"
>
> This reverts commit aa6c7633d6ff8125d588071cb4739930a847e1fa.
>
> Instead of using a system property and extending the shell scripts to
> start
> JMeter, we now configure Tika inside the client code directly. The used
> config file stays at the same location and has still the same content.
> ---
>  .gitignore|  2 +-
>  bin/jmeter|  2 +-
>  bin/jmeter.bat|  2 +-
>  .../protocol/http/gui/action/ParseCurlCommandAction.java  | 15
> ++-
>  4 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index 61df09b..21abad6 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -51,7 +51,7 @@
>  /bin/*.jmx
>  /bin/*.jtl
>  /bin/*.xml
> -# We need log4j2.xml even though we want to exclude xml created by batch
> tests
> +# We need log4j2.xml and tika-config.xml even though we want to exclude
> xml created by batch tests
>  !/bin/log4j2.xml
>  !/bin/tika-config.xml
>
> diff --git a/bin/jmeter b/bin/jmeter
> index fae82ff..5d5b949 100755
> --- a/bin/jmeter
> +++ b/bin/jmeter
> @@ -187,7 +187,7 @@ esac
>
>  # Always dump on OOM (does not cost anything unless triggered)
>  DUMP="-XX:+HeapDumpOnOutOfMemoryError"
> -SYSTEM_PROPS="-Djava.security.egd=file:/dev/urandom
> -Dtika.config=${JMETER_HOME}/bin/tika-config.xml"
> +SYSTEM_PROPS="-Djava.security.egd=file:/dev/urandom"
>  SERVER="-server"
>
>  if [ -z "${JMETER_COMPLETE_ARGS}" ]; then
> diff --git a/bin/jmeter.bat b/bin/jmeter.bat
> index 2c96b54..80fc534 100644
> --- a/bin/jmeter.bat
> +++ b/bin/jmeter.bat
> @@ -162,7 +162,7 @@ if not defined GC_ALGO (
>  set GC_ALGO=-XX:+UseG1GC -XX:MaxGCPauseMillis=100
> -XX:G1ReservePercent=20
>  )
>
> -set SYSTEM_PROPS=-Djava.security.egd=file:/dev/urandom
> -Dtika.config=%JMETER_BIN%tika-config.xml
> +set SYSTEM_PROPS=-Djava.security.egd=file:/dev/urandom
>
>  rem Always dump on OOM (does not cost anything unless triggered)
>  set DUMP=-XX:+HeapDumpOnOutOfMemoryError
> diff --git
> a/src/protocol/http/src/main/java/org/apache/jmeter/protocol/http/gui/action/ParseCurlCommandAction.java
> b/src/protocol/http/src/main/java/org/apache/jmeter/protocol/http/gui/action/ParseCurlCommandAction.java
> index d610b52..d601618 100644
> ---
> a/src/protocol/http/src/main/java/org/apache/jmeter/protocol/http/gui/action/ParseCurlCommandAction.java
> +++
> b/src/protocol/http/src/main/java/org/apache/jmeter/protocol/http/gui/action/ParseCurlCommandAction.java
> @@ -29,6 +29,7 @@ import java.io.IOException;
>  import java.net.MalformedURLException;
>  import java.net.URL;
>  import java.nio.charset.StandardCharsets;
> +import java.nio.file.Paths;
>  import java.text.MessageFormat;
>  import java.time.LocalDateTime;
>  import java.time.format.DateTimeFormatter;
> @@ -104,8 +105,11 @@ import org.apache.jorphan.collections.HashTree;
>  import org.apache.jorphan.gui.ComponentUtil;
>  import org.apache.jorphan.gui.JMeterUIDefaults;
>  import org.apache.tika.Tika;
> +import org.apache.tika.config.TikaConfig;
> +import org.apache.tika.exception.TikaException;
>  import org.slf4j.Logger;
>  import org.slf4j.LoggerFactory;
> +import org.xml.sax.SAXException;
>
>  /**
>   * Opens a popup where user can enter a cURL command line and create a
> test plan
> @@ -130,7 +134,16 @@ public class ParseCurlCommandAction extends
> AbstractAction implements MenuCreato
>  private JSyntaxTextArea cURLCommandTA;
>  private JLabel statusText;
>  private JCheckBox uploadCookiesCheckBox;
> -private final Tika tika = new Tika();
> +private final Tika tika = createTika();
> +
> +private Tika createTika() {
> +try {
> +return new Tika(new
> TikaConfig(Paths.get(JMeterUtils.getJMeterBinDir(), "tika-config.xml")));
> +} catch (TikaException | IOException | SAXException e) {
> +return new Tika();
> +}
> +}
> +
>  public ParseCurlCommandAction() {
>  super();
>  }
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.4.1 RC1

[Philippe Mouawad]

Thanks

On Fri, Jan 15, 2021 at 1:21 PM Milamber  wrote:

> Hi Philippe,
>
> Ok please ping me when is OK to start the RC2.
>
> Milamber
>
> On 15/01/2021 13:16, Philippe Mouawad wrote:
> > Hello Milamber,
> > Can you wait a bit, Felix wantes to commit another thing and we may want
> to
> > change a bit the tika fix
> >
> > Regards
> >
> > On Friday, January 15, 2021, Milamber  wrote:
> >
> >> Hello,
> >>
> >> Due of the issue (warning tika), I cancel the vote and start the next
> RC2
> >> asap.
> >>
> >> Milamber
> >>
> >> On 11/01/2021 16:33, Milamber wrote:
> >>
> >>> Hello,
> >>>
> >>> The first release candidate for JMeter 5.4.1 (032b55e3c8) has been
> >>> prepared, and your votes are solicited.
> >>>
> >>> This release is mainly a bugfix release.
> >>>
> >>> Please, test this release candidate (with load tests and/or functional
> >>> tests) using Java 8+ on Linux/Windows/macOS, especially on the changes.
> >>> Feedback is very welcome within the next 72 hours.
> >>>
> >>> You can read the New and Noteworthy section with some screenshots to
> >>> illustrate improvements and full list of changes at:
> >>> https://apache.github.io/jmeter-site-preview/site/changes.html
> >>>
> >>> JMeter is a Java desktop application designed to load test functional
> >>> behavior and measure performance. The current version targets Java 8+
> >>>
> >>> Download - Archives/hashes/sigs:
> >>> https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-5.4.1-rc1
> >>> (dist revision 45323)
> >>>
> >>> RAT report:
> >>> https://apache.github.io/jmeter-site-preview/rat/
> >>>
> >>> SHA512 hashes of archives for this vote: see footnote [1]
> >>>
> >>> Site preview is here:
> >>> https://apache.github.io/jmeter-site-preview/site/
> >>>
> >>> JavaDoc API preview is here:
> >>> https://apache.github.io/jmeter-site-preview/site/api/
> >>>
> >>> Maven staging repository is accessible here:
> >>> https://repository.apache.org/content/repositories/orgapache
> >>> jmeter-1069/org/apache/jmeter/
> >>>
> >>> Tag:
> >>> https://gitbox.apache.org/repos/asf?p=jmeter.git;a=tag;h=
> >>> refs/tags/v5.4.1-rc1
> >>>
> >>> Keys are here:
> >>> https://www.apache.org/dist/jmeter/KEYS
> >>>
> >>> N.B.
> >>> To create the distribution and test JMeter: "./gradlew build -Prelease
> >>> -PskipSign".
> >>>
> >>> JMeter 5.4.1 requires Java 8 or later to run.
> >>>
> >>> The artifacts were built with
> >>>Java(TM) SE Runtime Environment Oracle Corporation (build
> 1.8.0_221-b11)
> >>>Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build
> 25.221-b11,
> >>> mixed mode)
> >>>
> >>> Some known issues and incompatible changes are listed on changes page.
> >>> https://apache.github.io/jmeter-site-preview/site/changes.
> >>> html#Known%20problems%20and%20workarounds
> >>>
> >>>
> >>> All feedback and vote are welcome.
> >>>
> >>> [  ] +1  I support this release
> >>> [  ] +0  I am OK with this release
> >>> [  ] -0  OK, but
> >>> [  ] -1  I do not support this release (please indicate why)
> >>>
> >>> The vote will remain open for at least 72 hours.
> >>>
> >>> The PMC members please indicate the mention "(binding)" with your vote.
> >>>
> >>>
> >>> Note: If the vote passes, the intention is to release the archive files
> >>> and rename the RC tag as the release tag.
> >>>
> >>> Thanks in advance!
> >>>
> >>> Milamber
> >>>
> >>> ===
> >>> [1] SHA512 hashes of archives for this vote:
> >>>
> >>> 387e3c249e2b06cfe0b1b9417a17414f79337e8d0a0baec34afd9f16c009
> >>> 474bcec7773686ba438dd5c7bee70183222af62d694321c2f78ff18250fa690c0061
> >>> *apache-jmeter-5.4.1.tgz
> >>> f65c14073befc60ec4c46d4734cfbb0d081a385c395db65a4f933bf6629b
> >>> 46bbb9617f2139eb2e2c34bd99618c6d2309eee629107d87136c41e0ebd463441eff
> >>> *apache-jmeter-5.4.1.zip
> >>> 0cdd8e5024ed27ffe563eff9c393e703aa705858d11dfe6f7201a0e02cb2
> >>> 61858fe74d4e8990ad06e87d58e8f9449fe3a31f0e2389e6121f1d5cf9bc73649950
> >>> *apache-jmeter-5.4.1_src.tgz
> >>> ed78a896af42b49a0d65b2ec860a2902552f6a27077164e73f57f18a1de1
> >>> f31e8e53b967540bba6cfebd9b8d980526aca91700ceb4f9fda8b6178f819727587d
> >>> *apache-jmeter-5.4.1_src.zip
> >>>
> >>>
> >>>
> >>>
> >>>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.4.1 RC1

[Philippe Mouawad]

Hello Milamber,
Can you wait a bit, Felix wantes to commit another thing and we may want to
change a bit the tika fix

Regards

On Friday, January 15, 2021, Milamber  wrote:

> Hello,
>
> Due of the issue (warning tika), I cancel the vote and start the next RC2
> asap.
>
> Milamber
>
> On 11/01/2021 16:33, Milamber wrote:
>
>> Hello,
>>
>> The first release candidate for JMeter 5.4.1 (032b55e3c8) has been
>> prepared, and your votes are solicited.
>>
>> This release is mainly a bugfix release.
>>
>> Please, test this release candidate (with load tests and/or functional
>> tests) using Java 8+ on Linux/Windows/macOS, especially on the changes.
>> Feedback is very welcome within the next 72 hours.
>>
>> You can read the New and Noteworthy section with some screenshots to
>> illustrate improvements and full list of changes at:
>> https://apache.github.io/jmeter-site-preview/site/changes.html
>>
>> JMeter is a Java desktop application designed to load test functional
>> behavior and measure performance. The current version targets Java 8+
>>
>> Download - Archives/hashes/sigs:
>> https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-5.4.1-rc1
>> (dist revision 45323)
>>
>> RAT report:
>> https://apache.github.io/jmeter-site-preview/rat/
>>
>> SHA512 hashes of archives for this vote: see footnote [1]
>>
>> Site preview is here:
>> https://apache.github.io/jmeter-site-preview/site/
>>
>> JavaDoc API preview is here:
>> https://apache.github.io/jmeter-site-preview/site/api/
>>
>> Maven staging repository is accessible here:
>> https://repository.apache.org/content/repositories/orgapache
>> jmeter-1069/org/apache/jmeter/
>>
>> Tag:
>> https://gitbox.apache.org/repos/asf?p=jmeter.git;a=tag;h=
>> refs/tags/v5.4.1-rc1
>>
>> Keys are here:
>> https://www.apache.org/dist/jmeter/KEYS
>>
>> N.B.
>> To create the distribution and test JMeter: "./gradlew build -Prelease
>> -PskipSign".
>>
>> JMeter 5.4.1 requires Java 8 or later to run.
>>
>> The artifacts were built with
>>   Java(TM) SE Runtime Environment Oracle Corporation (build 1.8.0_221-b11)
>>   Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build 25.221-b11,
>> mixed mode)
>>
>> Some known issues and incompatible changes are listed on changes page.
>> https://apache.github.io/jmeter-site-preview/site/changes.
>> html#Known%20problems%20and%20workarounds
>>
>>
>> All feedback and vote are welcome.
>>
>> [  ] +1  I support this release
>> [  ] +0  I am OK with this release
>> [  ] -0  OK, but
>> [  ] -1  I do not support this release (please indicate why)
>>
>> The vote will remain open for at least 72 hours.
>>
>> The PMC members please indicate the mention "(binding)" with your vote.
>>
>>
>> Note: If the vote passes, the intention is to release the archive files
>> and rename the RC tag as the release tag.
>>
>> Thanks in advance!
>>
>> Milamber
>>
>> ===
>> [1] SHA512 hashes of archives for this vote:
>>
>> 387e3c249e2b06cfe0b1b9417a17414f79337e8d0a0baec34afd9f16c009
>> 474bcec7773686ba438dd5c7bee70183222af62d694321c2f78ff18250fa690c0061
>> *apache-jmeter-5.4.1.tgz
>> f65c14073befc60ec4c46d4734cfbb0d081a385c395db65a4f933bf6629b
>> 46bbb9617f2139eb2e2c34bd99618c6d2309eee629107d87136c41e0ebd463441eff
>> *apache-jmeter-5.4.1.zip
>> 0cdd8e5024ed27ffe563eff9c393e703aa705858d11dfe6f7201a0e02cb2
>> 61858fe74d4e8990ad06e87d58e8f9449fe3a31f0e2389e6121f1d5cf9bc73649950
>> *apache-jmeter-5.4.1_src.tgz
>> ed78a896af42b49a0d65b2ec860a2902552f6a27077164e73f57f18a1de1
>> f31e8e53b967540bba6cfebd9b8d980526aca91700ceb4f9fda8b6178f819727587d
>> *apache-jmeter-5.4.1_src.zip
>>
>>
>>
>>
>>
>

-- 
Cordialement.
Philippe Mouawad.

Re: [jmeter] branch master updated: Silence warning of tika about missing sqlite-jdbc dependency

[Philippe Mouawad]

Hello Felix,
Should we set it from within code ?
It seems it's triggered by ParseCurlCommandAction

Regards

On Thu, Jan 14, 2021 at 8:13 PM  wrote:

> This is an automated email from the ASF dual-hosted git repository.
>
> fschumacher pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/jmeter.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new aa6c763  Silence warning of tika about missing sqlite-jdbc
> dependency
> aa6c763 is described below
>
> commit aa6c7633d6ff8125d588071cb4739930a847e1fa
> Author: Felix Schumacher 
> AuthorDate: Thu Jan 14 20:13:13 2021 +0100
>
> Silence warning of tika about missing sqlite-jdbc dependency
> ---
>  .gitignore  |  1 +
>  bin/jmeter  |  2 +-
>  bin/jmeter.bat  |  2 +-
>  bin/tika-config.xml | 21 +
>  4 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index 1a0bc30..61df09b 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -53,6 +53,7 @@
>  /bin/*.xml
>  # We need log4j2.xml even though we want to exclude xml created by batch
> tests
>  !/bin/log4j2.xml
> +!/bin/tika-config.xml
>
>  build-local.properties
>  jmeter-fb.*
> diff --git a/bin/jmeter b/bin/jmeter
> index 5d5b949..fae82ff 100755
> --- a/bin/jmeter
> +++ b/bin/jmeter
> @@ -187,7 +187,7 @@ esac
>
>  # Always dump on OOM (does not cost anything unless triggered)
>  DUMP="-XX:+HeapDumpOnOutOfMemoryError"
> -SYSTEM_PROPS="-Djava.security.egd=file:/dev/urandom"
> +SYSTEM_PROPS="-Djava.security.egd=file:/dev/urandom
> -Dtika.config=${JMETER_HOME}/bin/tika-config.xml"
>  SERVER="-server"
>
>  if [ -z "${JMETER_COMPLETE_ARGS}" ]; then
> diff --git a/bin/jmeter.bat b/bin/jmeter.bat
> index 80fc534..2c96b54 100644
> --- a/bin/jmeter.bat
> +++ b/bin/jmeter.bat
> @@ -162,7 +162,7 @@ if not defined GC_ALGO (
>  set GC_ALGO=-XX:+UseG1GC -XX:MaxGCPauseMillis=100
> -XX:G1ReservePercent=20
>  )
>
> -set SYSTEM_PROPS=-Djava.security.egd=file:/dev/urandom
> +set SYSTEM_PROPS=-Djava.security.egd=file:/dev/urandom
> -Dtika.config=%JMETER_BIN%tika-config.xml
>
>  rem Always dump on OOM (does not cost anything unless triggered)
>  set DUMP=-XX:+HeapDumpOnOutOfMemoryError
> diff --git a/bin/tika-config.xml b/bin/tika-config.xml
> new file mode 100644
> index 000..f511df9
> --- /dev/null
> +++ b/bin/tika-config.xml
> @@ -0,0 +1,21 @@
> +
> +
> +
> +   
> +
> +
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.4.1 RC1

[Philippe Mouawad]

Hello,
First thanks for RM and sorry for detay.


When I start JMeter there is this warning which has no impact but which
should be fixed IMO:

Jan 14, 2021 1:33:44 PM
org.apache.tika.config.InitializableProblemHandler$3
handleInitializableProblem
WARNING: org.xerial's sqlite-jdbc is not loaded.
Please provide the jar on your classpath to parse sqlite files.
See tika-parsers/pom.xml for the correct version.

On Mon, Jan 11, 2021 at 4:33 PM Milamber  wrote:

> Hello,
>
> The first release candidate for JMeter 5.4.1 (032b55e3c8) has been
> prepared, and your votes are solicited.
>
> This release is mainly a bugfix release.
>
> Please, test this release candidate (with load tests and/or functional
> tests) using Java 8+ on Linux/Windows/macOS, especially on the changes.
> Feedback is very welcome within the next 72 hours.
>
> You can read the New and Noteworthy section with some screenshots to
> illustrate improvements and full list of changes at:
> https://apache.github.io/jmeter-site-preview/site/changes.html
>
> JMeter is a Java desktop application designed to load test functional
> behavior and measure performance. The current version targets Java 8+
>
> Download - Archives/hashes/sigs:
> https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-5.4.1-rc1
> (dist revision 45323)
>
> RAT report:
> https://apache.github.io/jmeter-site-preview/rat/
>
> SHA512 hashes of archives for this vote: see footnote [1]
>
> Site preview is here:
> https://apache.github.io/jmeter-site-preview/site/
>
> JavaDoc API preview is here:
> https://apache.github.io/jmeter-site-preview/site/api/
>
> Maven staging repository is accessible here:
>
> https://repository.apache.org/content/repositories/orgapachejmeter-1069/org/apache/jmeter/
>
> Tag:
>
> https://gitbox.apache.org/repos/asf?p=jmeter.git;a=tag;h=refs/tags/v5.4.1-rc1
>
> Keys are here:
> https://www.apache.org/dist/jmeter/KEYS
>
> N.B.
> To create the distribution and test JMeter: "./gradlew build -Prelease
> -PskipSign".
>
> JMeter 5.4.1 requires Java 8 or later to run.
>
> The artifacts were built with
>Java(TM) SE Runtime Environment Oracle Corporation (build 1.8.0_221-b11)
>Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build
> 25.221-b11, mixed mode)
>
> Some known issues and incompatible changes are listed on changes page.
>
> https://apache.github.io/jmeter-site-preview/site/changes.html#Known%20problems%20and%20workarounds
>
>
> All feedback and vote are welcome.
>
> [  ] +1  I support this release
> [  ] +0  I am OK with this release
> [  ] -0  OK, but
> [  ] -1  I do not support this release (please indicate why)
>
> The vote will remain open for at least 72 hours.
>
> The PMC members please indicate the mention "(binding)" with your vote.
>
>
> Note: If the vote passes, the intention is to release the archive files
> and rename the RC tag as the release tag.
>
> Thanks in advance!
>
> Milamber
>
> ===
> [1] SHA512 hashes of archives for this vote:
>
>
> 387e3c249e2b06cfe0b1b9417a17414f79337e8d0a0baec34afd9f16c009474bcec7773686ba438dd5c7bee70183222af62d694321c2f78ff18250fa690c0061
> *apache-jmeter-5.4.1.tgz
>
> f65c14073befc60ec4c46d4734cfbb0d081a385c395db65a4f933bf6629b46bbb9617f2139eb2e2c34bd99618c6d2309eee629107d87136c41e0ebd463441eff
> *apache-jmeter-5.4.1.zip
>
> 0cdd8e5024ed27ffe563eff9c393e703aa705858d11dfe6f7201a0e02cb261858fe74d4e8990ad06e87d58e8f9449fe3a31f0e2389e6121f1d5cf9bc73649950
> *apache-jmeter-5.4.1_src.tgz
>
> ed78a896af42b49a0d65b2ec860a2902552f6a27077164e73f57f18a1de1f31e8e53b967540bba6cfebd9b8d980526aca91700ceb4f9fda8b6178f819727587d
> *apache-jmeter-5.4.1_src.zip
>
>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: Release 5.4.1

[Philippe Mouawad]

Hello Milamber,
Ok by me.
Regards


On Mon, Jan 11, 2021 at 12:49 PM Milamber  wrote:

>
> I can start the release process for 5.4.1 today?
>
> On 09/01/2021 22:04, Felix Schumacher wrote:
> > Am 09.01.21 um 17:45 schrieb Philippe Mouawad:
> >> Hello Felix,
> >> My answers inline below.
> >>
> >> Regards
> >>
> >> On Sat, Jan 9, 2021 at 4:28 PM Felix Schumacher
> >>  >> <mailto:felix.schumac...@internetallee.de>> wrote:
> >>
> >>
> >>  Am 09.01.21 um 15:28 schrieb Philippe Mouawad:
> >>>  Hello,
> >>>  First best wishes for 2021 for all the team, I hope you're all
> >>>  doing fine !
> >>>
> >>>  Second, I think we should release a 5.4.1 now.
> >>>  On my side I've been testing it for few days on Mac OSX and I
> >>>  also made some tests on Windows, my colleague did it on Linux.
> >>>
> >>>  The last bug on JTree due to Darklaf
> >>>  (https://github.com/weisJ/darklaf/issues/228) was already there
> >>>  in 5.3 and it's not that problematic.
> >>>
> >>>  WDYT ?
> >>  I would like to hear your opinion on the bugs 65053 and 65034.
> >>
> >>  Bug 65053 is about downgrading JSONPath to 2.4.0 due to a bug with
> >>  regex parsing. I think we could go back to 2.4.0 without loosing
> >>  too much.
> >>
> >> Ok by me, sounds acceptable.
> >>
> >>  Bug 65034 is about an old bug(?) in handling reading of
> >>  binarytcpclient when no EOM is set. Those requests will always
> >>  fail (at least in my tests). I think we should change the
> >>  behaviour for the case when no EOM is given to not fail on
> >>  SocketTimeoutException.
> >>
> >>
> >> I looked at your patch, it looks good to me. Thanks
> > Both committed.
> >
> > Felix
> >
> >>  Apart from that, I am in favour of releasing soon (or even now :) )
> >>
> >>  Felix
> >>
> >>>  Regards
> >>>  Philippe
> >>>
> >>>  On Fri, Dec 11, 2020 at 12:27 PM Felix Schumacher
> >>>   >>>  <mailto:felix.schumac...@internetallee.de>> wrote:
> >>>
> >>>
> >>>
> >>>  Am 11. Dezember 2020 12:16:09 MEZ schrieb Philippe Mouawad
> >>>   philippe.moua...@gmail.com>>:
> >>>  >On Fri, Dec 11, 2020 at 12:09 PM Felix Schumacher <
> >>>  >felix.schumac...@internetallee.de
> >>>  <mailto:felix.schumac...@internetallee.de>> wrote:
> >>>  >
> >>>  >>
> >>>  >>
> >>>  >> Am 11. Dezember 2020 11:45:22 MEZ schrieb Philippe Mouawad
> <
> >>>  >> philippe.moua...@gmail.com
> >>>  <mailto:philippe.moua...@gmail.com>>:
> >>>  >> >Hello,
> >>>  >> >What is the level of UI test done after Darklaf upgrade ?
> >>>  >>
> >>>  >> Which level do you want to achieve?
> >>>  >>
> >>>  >> I have opened, saved an edited some simple test plans
> >>>  while working
> >>>  >on the
> >>>  >> recruiting issues. Nothing fancy. No problems seen on
> >>>  Ubuntu with
> >>>  >Darklaf
> >>>  >> (light intellij theme), that I have noticed.
> >>>  >>
> >>>  >
> >>>  >Has somebody done Windows 7 and 10 tests ?
> >>>  >This is where I saw most of the bugs.
> >>>  >I'll try to do that ,but for now I didn't find time to do it
> >>>  yet.
> >>>
> >>>  I haven't tested yet on windows, but had planned it for the
> rc.
> >>>
> >>>  >
> >>>  >I didn't yet have time to test on Mac OS.
> >>>
> >>>  I don't have that os :)
> >>>
> >>>  >
> >>>  >>
> >>>  >> >
> >>>  >> >Looks a bit too early for me.
> >>>  >>
> >

Re: Release 5.4.1

[Philippe Mouawad]

Hello Felix,
My answers inline below.

Regards

On Sat, Jan 9, 2021 at 4:28 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 09.01.21 um 15:28 schrieb Philippe Mouawad:
>
> Hello,
> First best wishes for 2021 for all the team, I hope you're all doing fine !
>
> Second, I think we should release a 5.4.1 now.
> On my side I've been testing it for few days on Mac OSX and I also made
> some tests on Windows, my colleague did it on Linux.
>
> The last bug on JTree due to Darklaf (
> https://github.com/weisJ/darklaf/issues/228) was already there in 5.3 and
> it's not that problematic.
>
>
> WDYT ?
>
> I would like to hear your opinion on the bugs 65053 and 65034.
>
> Bug 65053 is about downgrading JSONPath to 2.4.0 due to a bug with regex
> parsing. I think we could go back to 2.4.0 without loosing too much.
>
Ok by me, sounds acceptable.

> Bug 65034 is about an old bug(?) in handling reading of binarytcpclient
> when no EOM is set. Those requests will always fail (at least in my tests).
> I think we should change the behaviour for the case when no EOM is given to
> not fail on SocketTimeoutException.
>

I looked at your patch, it looks good to me. Thanks

> Apart from that, I am in favour of releasing soon (or even now :) )
>
> Felix
>
> Regards
> Philippe
>
> On Fri, Dec 11, 2020 at 12:27 PM Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
>>
>>
>> Am 11. Dezember 2020 12:16:09 MEZ schrieb Philippe Mouawad <
>> philippe.moua...@gmail.com>:
>> >On Fri, Dec 11, 2020 at 12:09 PM Felix Schumacher <
>> >felix.schumac...@internetallee.de> wrote:
>> >
>> >>
>> >>
>> >> Am 11. Dezember 2020 11:45:22 MEZ schrieb Philippe Mouawad <
>> >> philippe.moua...@gmail.com>:
>> >> >Hello,
>> >> >What is the level of UI test done after Darklaf upgrade ?
>> >>
>> >> Which level do you want to achieve?
>> >>
>> >> I have opened, saved an edited some simple test plans while working
>> >on the
>> >> recruiting issues. Nothing fancy. No problems seen on Ubuntu with
>> >Darklaf
>> >> (light intellij theme), that I have noticed.
>> >>
>> >
>> >Has somebody done Windows 7 and 10 tests ?
>> >This is where I saw most of the bugs.
>> >I'll try to do that ,but for now I didn't find time to do it yet.
>>
>> I haven't tested yet on windows, but had planned it for the rc.
>>
>> >
>> >I didn't yet have time to test on Mac OS.
>>
>> I don't have that os :)
>>
>> >
>> >>
>> >> >
>> >> >Looks a bit too early for me.
>> >>
>> >> How long should we calculate?
>> >>
>> >
>> >Just when we complete a minimum of tests on Mac and Windows, what do
>> >you
>> >think ?
>>
>> I thought, that those tests could be done on the rc, but if you want to
>> have a bit more than the minimal testing that has been performed by the
>> reporters of the last issues (all windows based I believe), then we should
>> wait a bit more and test actively on windows.
>>
>> Give us a shout, when you feel more comfortable with the level of
>> testing. I have no real pressure on this, Linux seems to work great ;) in
>> the mean time I will try to test on windows, too.
>>
>> Regards
>>  Felix
>>
>> >
>> >>
>> >> Regards
>> >>  Felix
>> >>
>> >>
>> >> >
>> >> >Thanks
>> >> >
>> >> >On Fri, Dec 11, 2020 at 10:58 AM Milamber 
>> >wrote:
>> >> >
>> >> >>
>> >> >> I can release version 5.4.1. Now?
>> >> >>
>> >> >> On 10/12/2020 21:17, Felix Schumacher wrote:
>> >> >> > Hi all,
>> >> >> >
>> >> >> > I think, we have waited long enough, to give people time for
>> >> >feedback on
>> >> >> > the last release.
>> >> >> >
>> >> >> > Let's do another release. Who would like to act as RM?
>> >> >> >
>> >> >> > Regards
>> >> >> >
>> >> >> >   Felix
>> >> >> >
>> >> >> > PS. I will test the next RC with Windows
>> >> >> >
>> >> >> > Am 07.12.20 um 16:06 schrie

Re: Release 5.4.1

[Philippe Mouawad]

Hello,
First best wishes for 2021 for all the team, I hope you're all doing fine !

Second, I think we should release a 5.4.1 now.
On my side I've been testing it for few days on Mac OSX and I also made
some tests on Windows, my colleague did it on Linux.

The last bug on JTree due to Darklaf (
https://github.com/weisJ/darklaf/issues/228) was already there in 5.3 and
it's not that problematic.

WDYT ?
Regards
Philippe

On Fri, Dec 11, 2020 at 12:27 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
>
> Am 11. Dezember 2020 12:16:09 MEZ schrieb Philippe Mouawad <
> philippe.moua...@gmail.com>:
> >On Fri, Dec 11, 2020 at 12:09 PM Felix Schumacher <
> >felix.schumac...@internetallee.de> wrote:
> >
> >>
> >>
> >> Am 11. Dezember 2020 11:45:22 MEZ schrieb Philippe Mouawad <
> >> philippe.moua...@gmail.com>:
> >> >Hello,
> >> >What is the level of UI test done after Darklaf upgrade ?
> >>
> >> Which level do you want to achieve?
> >>
> >> I have opened, saved an edited some simple test plans while working
> >on the
> >> recruiting issues. Nothing fancy. No problems seen on Ubuntu with
> >Darklaf
> >> (light intellij theme), that I have noticed.
> >>
> >
> >Has somebody done Windows 7 and 10 tests ?
> >This is where I saw most of the bugs.
> >I'll try to do that ,but for now I didn't find time to do it yet.
>
> I haven't tested yet on windows, but had planned it for the rc.
>
> >
> >I didn't yet have time to test on Mac OS.
>
> I don't have that os :)
>
> >
> >>
> >> >
> >> >Looks a bit too early for me.
> >>
> >> How long should we calculate?
> >>
> >
> >Just when we complete a minimum of tests on Mac and Windows, what do
> >you
> >think ?
>
> I thought, that those tests could be done on the rc, but if you want to
> have a bit more than the minimal testing that has been performed by the
> reporters of the last issues (all windows based I believe), then we should
> wait a bit more and test actively on windows.
>
> Give us a shout, when you feel more comfortable with the level of testing.
> I have no real pressure on this, Linux seems to work great ;) in the mean
> time I will try to test on windows, too.
>
> Regards
>  Felix
>
> >
> >>
> >> Regards
> >>  Felix
> >>
> >>
> >> >
> >> >Thanks
> >> >
> >> >On Fri, Dec 11, 2020 at 10:58 AM Milamber 
> >wrote:
> >> >
> >> >>
> >> >> I can release version 5.4.1. Now?
> >> >>
> >> >> On 10/12/2020 21:17, Felix Schumacher wrote:
> >> >> > Hi all,
> >> >> >
> >> >> > I think, we have waited long enough, to give people time for
> >> >feedback on
> >> >> > the last release.
> >> >> >
> >> >> > Let's do another release. Who would like to act as RM?
> >> >> >
> >> >> > Regards
> >> >> >
> >> >> >   Felix
> >> >> >
> >> >> > PS. I will test the next RC with Windows
> >> >> >
> >> >> > Am 07.12.20 um 16:06 schrieb Felix Schumacher:
> >> >> >> Am 07.12.20 um 13:58 schrieb Philippe Mouawad:
> >> >> >>> Hello,
> >> >> >>> It looks like we may need to release a 5.4.1 due to some
> >> >regressions
> >> >> and
> >> >> >>> issues with Darklaf.
> >> >> >> Yes, it certainly looks like a soon next release. I would like
> >to
> >> >wait a
> >> >> >> few days, to see, if more problems get reported (not weeks,
> >> >though).
> >> >> >>
> >> >> >>
> >> >> >>> Regarding Darklaf, we are having constantly since it was
> >> >introduced
> >> >> issues
> >> >> >>> with it on different platforms. Jannis is very reactive to fix
> >> >those
> >> >> issues
> >> >> >>> which is great.
> >> >> >>>
> >> >> >>> But the issues are very impacting in terms of UI experience
> >(at
> >> >least
> >> >> the
> >> >> >>> ones I faced in the past) and we are still not stable.
> >> >> >>>
> >> >> >>> How can we do to make our releases more robust ?
> >> >> >>> It looks like our automated test don't detect them. And the
> >> >manual
> >> >> tests me
> >> >> >>> wake as part of our release process neither.
> >> >> >>> I personally use JMeter mainly on MacOSX, only sometimes on
> >> >Windows 10.
> >> >> >>>
> >> >> >>> I faced many issues on Windows as I had to use it for one
> >> >customer,
> >> >> this is
> >> >> >>> how I reported them.
> >> >> >> That's what I thought, too. I think we need more automated
> >tests
> >> >for the
> >> >> >> GUI part, as one regression showed up on saving test plans on a
> >> >Windows
> >> >> OS.
> >> >> >>
> >> >> >> @All, do you have experience testing a (Swing) GUI? What would
> >be
> >> >a good
> >> >> >> way to introduce this, for at least some basic stuff like
> >opening
> >> >a test
> >> >> >> plan, creating one through the UI, saving it.
> >> >> >>
> >> >> >>> @Dev team, what are the OSes you use ?
> >> >> >> Linux (Ubuntu really)
> >> >> >>
> >> >> >>
> >> >> >>> If we are not able to improve this, maybe we should switch
> >back
> >> >to
> >> >> System
> >> >> >>> LAFs.
> >> >> >> That is always possible.
> >> >> >>
> >> >> >> Regards
> >> >> >>
> >> >> >>   Felix
> >> >> >>
> >> >> >>> Regards
> >> >>
> >> >>
> >>
>


-- 
Cordialement.
Philippe Mouawad.

Re: Setting better defaults for HTTP request

[Philippe Mouawad]

Hello,

I tried implementing it by modifying in those 2 methods the default value

   -
   
https://github.com/apache/jmeter/blob/master/src/protocol/http/src/main/java/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java#L838
   -
   
https://github.com/apache/jmeter/blob/master/src/protocol/http/src/main/java/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java#L846


But they are not taken into account, it looks like the method returns 0
because in this code:

public int getPropertyAsInt(String key, int defaultValue) {
JMeterProperty jmp = getRawProperty(key);
=> jmp is not NullProperty nor null, so jmp.getIntValue() is called leading
to 0
return jmp == null || jmp instanceof NullProperty ? defaultValue :
jmp.getIntValue();
}

Is this another bug surfacing ?

Regards

On Sun, Dec 20, 2020 at 7:14 PM Antonio Gomes Rodrigues 
wrote:

> Hi
>
> +1 to me to put default timeout
>
> Le dim. 20 déc. 2020 à 18:44, Graham Russell  a écrit :
>
> > I agree, setting those as defaults is much better than infinite and less
> > concerning than 10s/60s.
> >
> > They probably won't do much to stop people complaining about JMeter
> hanging
> > on shutdown,
> > was this lack of default timeout the root cause of those complaints or is
> > there something else we can do with that issue?
> >
> > On Sun, 20 Dec 2020, 13:02 Philippe Mouawad,  >
> > wrote:
> >
> > > Hello,
> > > Let’s do that
> > >
> > > Thanks for feedback
> > >
> > > On Sunday, December 20, 2020, Felix Schumacher <
> > > felix.schumac...@internetallee.de> wrote:
> > >
> > > > Am Samstag, den 19.12.2020, 17:10 +0100 schrieb Philippe Mouawad:
> > > > > Hello
> > > > >
> > > > > Currently we don't set neither connect nor read timeout which means
> > > > > they
> > > > > default to infinite.
> > > > > I don't think those are good defaults and users frequently think
> > > > > JMeter is
> > > > > hanging.
> > > > >
> > > > > Shouldn't we set better defaults ?
> > > > >
> > > > > - Connect  to 10s
> > > > > - Read to 60s
> > > >
> > > > I generally like the idea of setting a default timeout, as infinity
> is
> > > > a long time to wait for. The times are great, if you know, that
> > > > timeouts are set, but what about the old settings, where the plan
> > > > didn't take those into account?
> > > >
> > > > I think we can be a bit more generous on those timeouts, especially
> for
> > > > the read timeout. For a non-interactive site, those might be a bit
> > > > short.
> > > >
> > > > In my firefox's about:config the values for connection and response
> > > > timeout are 90 s and 300 s respectively. (I took
> > > > network.http.connection-timeout and network.http.response.timeout)
> > > >
> > > > I think those values should be conservative enough for most of our
> > > > users.
> > > >
> > > >
> > > > Felix
> > > >
> > > > >
> > > > > WDYT ?
> > > > > Thanks
> > > >
> > > >
> > >
> > > --
> > > Cordialement.
> > > Philippe Mouawad.
> > >
> >
>


-- 
Cordialement.
Philippe Mouawad.

Re: Setting better defaults for HTTP request

[Philippe Mouawad]

Hello,
Let’s do that

Thanks for feedback

On Sunday, December 20, 2020, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

> Am Samstag, den 19.12.2020, 17:10 +0100 schrieb Philippe Mouawad:
> > Hello
> >
> > Currently we don't set neither connect nor read timeout which means
> > they
> > default to infinite.
> > I don't think those are good defaults and users frequently think
> > JMeter is
> > hanging.
> >
> > Shouldn't we set better defaults ?
> >
> > - Connect  to 10s
> > - Read to 60s
>
> I generally like the idea of setting a default timeout, as infinity is
> a long time to wait for. The times are great, if you know, that
> timeouts are set, but what about the old settings, where the plan
> didn't take those into account?
>
> I think we can be a bit more generous on those timeouts, especially for
> the read timeout. For a non-interactive site, those might be a bit
> short.
>
> In my firefox's about:config the values for connection and response
> timeout are 90 s and 300 s respectively. (I took
> network.http.connection-timeout and network.http.response.timeout)
>
> I think those values should be conservative enough for most of our
> users.
>
>
> Felix
>
> >
> > WDYT ?
> > Thanks
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: Setting better defaults for HTTP request

[Philippe Mouawad]

On Sat, Dec 19, 2020 at 5:40 PM Graham Russell  wrote:

> I think it's a good idea, as long as we make it very obvious how to change
> it in the UI and failure/error message.
>
Yes

>
> Would it affect existing scripts? I can imagine some existing (and indeed
> new) tests might start failing with a 60s read timeout due to some slow
> calls.
>

Yes that's the impact but if we clearly document this, do you think it  is
a problem ?

>
> Graham
>
>
> On Sat, 19 Dec 2020, 16:10 Philippe Mouawad, <
> p.moua...@ubik-ingenierie.com>
> wrote:
>
> > Hello
> >
> > Currently we don't set neither connect nor read timeout which means they
> > default to infinite.
> > I don't think those are good defaults and users frequently think JMeter
> is
> > hanging.
> >
> > Shouldn't we set better defaults ?
> >
> > - Connect  to 10s
> > - Read to 60s
> >
> > WDYT ?
> > Thanks
> > --
> > Regards
> > Philippe M.
> >
>


-- 
Cordialement.
Philippe Mouawad.

Setting better defaults for HTTP request

[Philippe Mouawad]

Hello

Currently we don't set neither connect nor read timeout which means they
default to infinite.
I don't think those are good defaults and users frequently think JMeter is
hanging.

Shouldn't we set better defaults ?

- Connect  to 10s
- Read to 60s

WDYT ?
Thanks
-- 
Regards
Philippe M.

Re: [Bug 64954] Critical Section Controller causes waiting threads not to stop

[Philippe Mouawad]

Hello Felix,
Yes

Regards

On Saturday, December 19, 2020, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

> Hi Philippe,
>
> why did you set version to 2.12? Is this to indicate, that the behaviour
> is known since 2.12?
>
> Regards
>
>  Felix
>
> Am 19.12.20 um 00:39 schrieb bugzi...@apache.org:
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=64954
> >
> > Philippe Mouawad  changed:
> >
> >What|Removed |Added
> > 
> 
> >Hardware|PC  |All
> >  OS||All
> >  CC|
> |p.mouawad@ubik-ingenierie.c
> >|    |om
> > Version|unspecified |2.12
> >
>


-- 
Cordialement.
Philippe Mouawad.

Re: Release 5.4.1

[Philippe Mouawad]

Hello Mariusz,
Can you please do the following:

1) Find the line 151 of jmeter.bat:

=> set HEAP=-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m

Replace current value by:

=> set HEAP=-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m -Ddarklaf.treeRowPopup=false


If Linux, Find the line 166 of jmeter.sh:

Replace

: "${HEAP:="-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m"}"

by:

: "${HEAP:="-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m
-Ddarklaf.treeRowPopup=false"}"


3) Restart JMeter

4) test again


Thanks

On Thu, Dec 17, 2020 at 10:31 AM Mariusz W  wrote:

> The same situation on r1942-53c6db8676b868db10d668e7ede2ef36cf8241b9
> I think that adding "critical section controller" started problem. I added
> setUP/tearDown TG, and Jsr223 controller earlier without problem.
> Critical section controller (logical controller) was first element of this
> kind I added to this plan in 5.4.1-Snapshot. It was added to Test Fragment.
>
> Mariusz
>
> On Thu, 17 Dec 2020 at 10:01, Mariusz W  wrote:
>
>> Not, yet.
>> After restarting JMeter the error persist - I can't also click on most
>> disabled elements eg. TestFragments and disabled TestGroups - I can click
>> in enabled elements in disabled elements.
>> After opening the same plan in JM 5.3 everything works, so I think that
>> jmx is not damaged.
>> I will try new build.
>>
>> Mariusz
>>
>> On Thu, 17 Dec 2020 at 09:40, Philippe Mouawad <
>> philippe.moua...@gmail.com> wrote:
>>
>>> Hello,
>>> Did you try with latest nightly build also ?
>>>
>>> Thanks
>>>
>>> On Thu, Dec 17, 2020 at 9:38 AM Mariusz W  wrote:
>>>
>>>> Hi,
>>>> When I added "Critical section controller"  (Darklaf Intellij) - I am
>>>> not able to click on it.
>>>>
>>>> Mariusz
>>>>
>>>> On Fri, 11 Dec 2020 at 16:37, Mariusz W  wrote:
>>>>
>>>>> Hi,
>>>>> I wil try to test my scripts from 5.3 to 5.4.1 snapshot on Windows
>>>>> next week - I downloaded LATEST
>>>>> (r1936-5bb4fbe389204290c61afbd12bac66a8ca928755)  from
>>>>> https://ci.apache.org/projects/jmeter/nightlies/
>>>>> I will have some feedback I think. Now, as fast run I started my
>>>>> script with jdbc samplers + changed UI to Darklaf few times - it
>>>>> workes.
>>>>>
>>>>> Regards,
>>>>> Mariusz
>>>>>
>>>>> On Fri, 11 Dec 2020 at 12:27, Felix Schumacher <
>>>>> felix.schumac...@internetallee.de> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Am 11. Dezember 2020 12:16:09 MEZ schrieb Philippe Mouawad <
>>>>>> philippe.moua...@gmail.com>:
>>>>>> >On Fri, Dec 11, 2020 at 12:09 PM Felix Schumacher <
>>>>>> >felix.schumac...@internetallee.de> wrote:
>>>>>> >
>>>>>> >>
>>>>>> >>
>>>>>> >> Am 11. Dezember 2020 11:45:22 MEZ schrieb Philippe Mouawad <
>>>>>> >> philippe.moua...@gmail.com>:
>>>>>> >> >Hello,
>>>>>> >> >What is the level of UI test done after Darklaf upgrade ?
>>>>>> >>
>>>>>> >> Which level do you want to achieve?
>>>>>> >>
>>>>>> >> I have opened, saved an edited some simple test plans while working
>>>>>> >on the
>>>>>> >> recruiting issues. Nothing fancy. No problems seen on Ubuntu with
>>>>>> >Darklaf
>>>>>> >> (light intellij theme), that I have noticed.
>>>>>> >>
>>>>>> >
>>>>>> >Has somebody done Windows 7 and 10 tests ?
>>>>>> >This is where I saw most of the bugs.
>>>>>> >I'll try to do that ,but for now I didn't find time to do it yet.
>>>>>>
>>>>>> I haven't tested yet on windows, but had planned it for the rc.
>>>>>>
>>>>>> >
>>>>>> >I didn't yet have time to test on Mac OS.
>>>>>>
>>>>>> I don't have that os :)
>>>>>>
>>>>>> >
>>>>>> >>
>>>>>> >> >
>>>>>> >> >Looks a bit too early for me.
>>>>>> >>
>>>>>> >&

Re: [weisJ/darklaf] Unselectable element in a JTree (#225)

[Philippe Mouawad]

Hello Felix,
Do you think we should set this property in code or wait for Jannis ?

It looks like we need to release a new version not too far from now as we
are getting duplicated reports now on the main regression.

I have completed my tests on Mac and Windows

Thanks
Regards

On Thu, Dec 17, 2020 at 9:09 PM Felix Schumacher 
wrote:

> The OP states that the issue appears on a HiDPI display with resolution of
> 3240x2160 and a text size of 225%, only. OP can't reproduce it with 200%
> text size or a lower resolution of 1920x1080. (Can be looked up in the bug
> report Philippe has linked above.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> , or
> unsubscribe
> 
> .
>


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: Release 5.4.1

[Philippe Mouawad]

Hello,
Did you try with latest nightly build also ?

Thanks

On Thu, Dec 17, 2020 at 9:38 AM Mariusz W  wrote:

> Hi,
> When I added "Critical section controller"  (Darklaf Intellij) - I am not
> able to click on it.
>
> Mariusz
>
> On Fri, 11 Dec 2020 at 16:37, Mariusz W  wrote:
>
>> Hi,
>> I wil try to test my scripts from 5.3 to 5.4.1 snapshot on Windows next
>> week - I downloaded LATEST
>> (r1936-5bb4fbe389204290c61afbd12bac66a8ca928755)  from
>> https://ci.apache.org/projects/jmeter/nightlies/
>> I will have some feedback I think. Now, as fast run I started my script
>> with jdbc samplers + changed UI to Darklaf few times - it workes.
>>
>> Regards,
>> Mariusz
>>
>> On Fri, 11 Dec 2020 at 12:27, Felix Schumacher <
>> felix.schumac...@internetallee.de> wrote:
>>
>>>
>>>
>>> Am 11. Dezember 2020 12:16:09 MEZ schrieb Philippe Mouawad <
>>> philippe.moua...@gmail.com>:
>>> >On Fri, Dec 11, 2020 at 12:09 PM Felix Schumacher <
>>> >felix.schumac...@internetallee.de> wrote:
>>> >
>>> >>
>>> >>
>>> >> Am 11. Dezember 2020 11:45:22 MEZ schrieb Philippe Mouawad <
>>> >> philippe.moua...@gmail.com>:
>>> >> >Hello,
>>> >> >What is the level of UI test done after Darklaf upgrade ?
>>> >>
>>> >> Which level do you want to achieve?
>>> >>
>>> >> I have opened, saved an edited some simple test plans while working
>>> >on the
>>> >> recruiting issues. Nothing fancy. No problems seen on Ubuntu with
>>> >Darklaf
>>> >> (light intellij theme), that I have noticed.
>>> >>
>>> >
>>> >Has somebody done Windows 7 and 10 tests ?
>>> >This is where I saw most of the bugs.
>>> >I'll try to do that ,but for now I didn't find time to do it yet.
>>>
>>> I haven't tested yet on windows, but had planned it for the rc.
>>>
>>> >
>>> >I didn't yet have time to test on Mac OS.
>>>
>>> I don't have that os :)
>>>
>>> >
>>> >>
>>> >> >
>>> >> >Looks a bit too early for me.
>>> >>
>>> >> How long should we calculate?
>>> >>
>>> >
>>> >Just when we complete a minimum of tests on Mac and Windows, what do
>>> >you
>>> >think ?
>>>
>>> I thought, that those tests could be done on the rc, but if you want to
>>> have a bit more than the minimal testing that has been performed by the
>>> reporters of the last issues (all windows based I believe), then we should
>>> wait a bit more and test actively on windows.
>>>
>>> Give us a shout, when you feel more comfortable with the level of
>>> testing. I have no real pressure on this, Linux seems to work great ;) in
>>> the mean time I will try to test on windows, too.
>>>
>>> Regards
>>>  Felix
>>>
>>> >
>>> >>
>>> >> Regards
>>> >>  Felix
>>> >>
>>> >>
>>> >> >
>>> >> >Thanks
>>> >> >
>>> >> >On Fri, Dec 11, 2020 at 10:58 AM Milamber 
>>> >wrote:
>>> >> >
>>> >> >>
>>> >> >> I can release version 5.4.1. Now?
>>> >> >>
>>> >> >> On 10/12/2020 21:17, Felix Schumacher wrote:
>>> >> >> > Hi all,
>>> >> >> >
>>> >> >> > I think, we have waited long enough, to give people time for
>>> >> >feedback on
>>> >> >> > the last release.
>>> >> >> >
>>> >> >> > Let's do another release. Who would like to act as RM?
>>> >> >> >
>>> >> >> > Regards
>>> >> >> >
>>> >> >> >   Felix
>>> >> >> >
>>> >> >> > PS. I will test the next RC with Windows
>>> >> >> >
>>> >> >> > Am 07.12.20 um 16:06 schrieb Felix Schumacher:
>>> >> >> >> Am 07.12.20 um 13:58 schrieb Philippe Mouawad:
>>> >> >> >>> Hello,
>>> >> >> >>> It looks like we may need to release a 5.4.1 due to some
>>> 

Dependencies update

[Philippe Mouawad]

Hello,

There is something I don't understand, I updated dnsjava and the following
build succeeded:

   -
   
https://ci-builds.apache.org/blue/rest/organizations/jenkins/pipelines/JMeter/pipelines/JMeter-trunk/runs/167/log/?start=0

But we have a random failure in following builds whether on Jenkins or
Github actions::

   - org.apache.jmeter.protocol.http.control.DNSCacheManagerSpec > Valid
   DNS resolves and caches with custom resolve true

Is it the test that is flaky or a potential regression related to new
version ?
I reverted update.

Updating dependencies on projetc, I noticed we could also update:

   - jackson 2.11 but it was not clear for me if it was backward compatible
   - jodd 5.1.5 but I think there are breaking changes, so maybe in next
   release
   - saxon 9.10 but it was not clear for me if it was backward compatible
   - jtidy has a new version maintained in another repository and another
   group id (https://github.com/jtidy/jtidy), I guess we need to wait for
   another release


Please double check if I was not too agressive in my updates.

-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: Release 5.4.1

[Philippe Mouawad]

On Fri, Dec 11, 2020 at 12:09 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
>
> Am 11. Dezember 2020 11:45:22 MEZ schrieb Philippe Mouawad <
> philippe.moua...@gmail.com>:
> >Hello,
> >What is the level of UI test done after Darklaf upgrade ?
>
> Which level do you want to achieve?
>
> I have opened, saved an edited some simple test plans while working on the
> recruiting issues. Nothing fancy. No problems seen on Ubuntu with Darklaf
> (light intellij theme), that I have noticed.
>

Has somebody done Windows 7 and 10 tests ?
This is where I saw most of the bugs.
I'll try to do that ,but for now I didn't find time to do it yet.

I didn't yet have time to test on Mac OS.

>
> >
> >Looks a bit too early for me.
>
> How long should we calculate?
>

Just when we complete a minimum of tests on Mac and Windows, what do you
think ?

>
> Regards
>  Felix
>
>
> >
> >Thanks
> >
> >On Fri, Dec 11, 2020 at 10:58 AM Milamber  wrote:
> >
> >>
> >> I can release version 5.4.1. Now?
> >>
> >> On 10/12/2020 21:17, Felix Schumacher wrote:
> >> > Hi all,
> >> >
> >> > I think, we have waited long enough, to give people time for
> >feedback on
> >> > the last release.
> >> >
> >> > Let's do another release. Who would like to act as RM?
> >> >
> >> > Regards
> >> >
> >> >   Felix
> >> >
> >> > PS. I will test the next RC with Windows
> >> >
> >> > Am 07.12.20 um 16:06 schrieb Felix Schumacher:
> >> >> Am 07.12.20 um 13:58 schrieb Philippe Mouawad:
> >> >>> Hello,
> >> >>> It looks like we may need to release a 5.4.1 due to some
> >regressions
> >> and
> >> >>> issues with Darklaf.
> >> >> Yes, it certainly looks like a soon next release. I would like to
> >wait a
> >> >> few days, to see, if more problems get reported (not weeks,
> >though).
> >> >>
> >> >>
> >> >>> Regarding Darklaf, we are having constantly since it was
> >introduced
> >> issues
> >> >>> with it on different platforms. Jannis is very reactive to fix
> >those
> >> issues
> >> >>> which is great.
> >> >>>
> >> >>> But the issues are very impacting in terms of UI experience (at
> >least
> >> the
> >> >>> ones I faced in the past) and we are still not stable.
> >> >>>
> >> >>> How can we do to make our releases more robust ?
> >> >>> It looks like our automated test don't detect them. And the
> >manual
> >> tests me
> >> >>> wake as part of our release process neither.
> >> >>> I personally use JMeter mainly on MacOSX, only sometimes on
> >Windows 10.
> >> >>>
> >> >>> I faced many issues on Windows as I had to use it for one
> >customer,
> >> this is
> >> >>> how I reported them.
> >> >> That's what I thought, too. I think we need more automated tests
> >for the
> >> >> GUI part, as one regression showed up on saving test plans on a
> >Windows
> >> OS.
> >> >>
> >> >> @All, do you have experience testing a (Swing) GUI? What would be
> >a good
> >> >> way to introduce this, for at least some basic stuff like opening
> >a test
> >> >> plan, creating one through the UI, saving it.
> >> >>
> >> >>> @Dev team, what are the OSes you use ?
> >> >> Linux (Ubuntu really)
> >> >>
> >> >>
> >> >>> If we are not able to improve this, maybe we should switch back
> >to
> >> System
> >> >>> LAFs.
> >> >> That is always possible.
> >> >>
> >> >> Regards
> >> >>
> >> >>   Felix
> >> >>
> >> >>> Regards
> >>
> >>
>


-- 
Cordialement.
Philippe Mouawad.

Re: Release 5.4.1

[Philippe Mouawad]

Hello,
What is the level of UI test done after Darklaf upgrade ?

Looks a bit too early for me.

Thanks

On Fri, Dec 11, 2020 at 10:58 AM Milamber  wrote:

>
> I can release version 5.4.1. Now?
>
> On 10/12/2020 21:17, Felix Schumacher wrote:
> > Hi all,
> >
> > I think, we have waited long enough, to give people time for feedback on
> > the last release.
> >
> > Let's do another release. Who would like to act as RM?
> >
> > Regards
> >
> >   Felix
> >
> > PS. I will test the next RC with Windows
> >
> > Am 07.12.20 um 16:06 schrieb Felix Schumacher:
> >> Am 07.12.20 um 13:58 schrieb Philippe Mouawad:
> >>> Hello,
> >>> It looks like we may need to release a 5.4.1 due to some regressions
> and
> >>> issues with Darklaf.
> >> Yes, it certainly looks like a soon next release. I would like to wait a
> >> few days, to see, if more problems get reported (not weeks, though).
> >>
> >>
> >>> Regarding Darklaf, we are having constantly since it was introduced
> issues
> >>> with it on different platforms. Jannis is very reactive to fix those
> issues
> >>> which is great.
> >>>
> >>> But the issues are very impacting in terms of UI experience (at least
> the
> >>> ones I faced in the past) and we are still not stable.
> >>>
> >>> How can we do to make our releases more robust ?
> >>> It looks like our automated test don't detect them. And the manual
> tests me
> >>> wake as part of our release process neither.
> >>> I personally use JMeter mainly on MacOSX, only sometimes on Windows 10.
> >>>
> >>> I faced many issues on Windows as I had to use it for one customer,
> this is
> >>> how I reported them.
> >> That's what I thought, too. I think we need more automated tests for the
> >> GUI part, as one regression showed up on saving test plans on a Windows
> OS.
> >>
> >> @All, do you have experience testing a (Swing) GUI? What would be a good
> >> way to introduce this, for at least some basic stuff like opening a test
> >> plan, creating one through the UI, saving it.
> >>
> >>> @Dev team, what are the OSes you use ?
> >> Linux (Ubuntu really)
> >>
> >>
> >>> If we are not able to improve this, maybe we should switch back to
> System
> >>> LAFs.
> >> That is always possible.
> >>
> >> Regards
> >>
> >>   Felix
> >>
> >>> Regards
>
>

-- 
Cordialement.
Philippe Mouawad.

Release 5.4.1

[Philippe Mouawad]

Hello,
It looks like we may need to release a 5.4.1 due to some regressions and
issues with Darklaf.

Regarding Darklaf, we are having constantly since it was introduced issues
with it on different platforms. Jannis is very reactive to fix those issues
which is great.

But the issues are very impacting in terms of UI experience (at least the
ones I faced in the past) and we are still not stable.

How can we do to make our releases more robust ?
It looks like our automated test don't detect them. And the manual tests me
wake as part of our release process neither.
I personally use JMeter mainly on MacOSX, only sometimes on Windows 10.

I faced many issues on Windows as I had to use it for one customer, this is
how I reported them.

@Dev team, what are the OSes you use ?

If we are not able to improve this, maybe we should switch back to System
LAFs.

Regards
-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Re: [VOTE] Release JMeter 5.4 RC2

[Philippe Mouawad]

Thanks Milamber !

On Fri, Dec 4, 2020 at 10:10 PM Milamber  wrote:

> In few minutes
>
>
> On 12/4/20 8:09 PM, Philippe Mouawad wrote:
>
> Hello Milamber,
> Thanks for RM.
> When do you plan the official announcement ?
>
> Thanks
>
> On Thu, Dec 3, 2020 at 6:56 AM Milamber  
>  wrote:
>
>
> Hello,
>
> Thanks very much to all who voted for this release.
>
> The votes were as follows:
>
> === +1 vote (with *: binding) ===
>
> Felix Schumacher (fschumacher)*
> Philippe Mouawad (pmouawad)*
> Woonsan Ko (woonsan)
> Bruno Demion (milamber)*
>
> ===
>
> There were no other votes, so the vote passes.
>
> I will prepare the delivery of the release for having an official announce
> after the mirrors sync.
>
> Milamber
>
> On 11/29/20 4:55 PM, Milamber wrote:
>
> Hello,
>
> The second release candidate for JMeter 5.4 (079404a06a) has been
> prepared, and your votes are solicited.
>
> This release brings some new features and improvements, and also fixes
> bugs.
>
> Please, test this release candidate (with load tests and/or functional
> tests) using Java 8+ on Linux/Windows/macOS, especially on the changes.
> Feedback is very welcome within the next 72 hours.
>
> You can read the New and Noteworthy section with some screenshots to
> illustrate improvements and full list of changes 
> at:https://apache.github.io/jmeter-site-preview/site/changes.html
>
> JMeter is a Java desktop application designed to load test functional
> behavior and measure performance. The current version targets Java 8+
>
> Download - 
> Archives/hashes/sigs:https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-5.4-rc2
> (dist revision 44732)
>
> RAT report:https://apache.github.io/jmeter-site-preview/rat/
>
> SHA512 hashes of archives for this vote: see footnote [1]
>
> Site preview is here:https://apache.github.io/jmeter-site-preview/site/
>
> JavaDoc API preview is 
> here:https://apache.github.io/jmeter-site-preview/site/api/
>
> Maven staging repository is accessible here:
>
>
> https://repository.apache.org/content/repositories/orgapachejmeter-1068/org/apache/jmeter/
>
> Tag:
>
>
> https://gitbox.apache.org/repos/asf?p=jmeter.git;a=tag;h=refs/tags/v5.4-rc2
>
> Keys are here:https://www.apache.org/dist/jmeter/KEYS
>
> N.B.
> To create the distribution and test JMeter: "./gradlew build -Prelease
> -PskipSign".
>
> JMeter 5.4 requires Java 8 or later to run.
>
> The artifacts were built with
>   Java(TM) SE Runtime Environment Oracle Corporation (build
> 1.8.0_221-b11)
>   Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build
> 25.221-b11, mixed mode)
>
> Some known issues and incompatible changes are listed on changes page.
>
>
> https://apache.github.io/jmeter-site-preview/site/changes.html#Known%20problems%20and%20workarounds
>
> All feedback and vote are welcome.
>
> [  ] +1  I support this release
> [  ] +0  I am OK with this release
> [  ] -0  OK, but
> [  ] -1  I do not support this release (please indicate why)
>
> The vote will remain open for at least 72 hours.
>
> The PMC members please indicate the mention "(binding)" with your vote.
>
>
> Note: If the vote passes, the intention is to release the archive files
> and rename the RC tag as the release tag.
>
> Thanks in advance!
>
> Milamber
>
> ===
> [1] SHA512 hashes of archives for this vote:
>
>
>
> 47e4d6fe4ba327685636a0dd170a1732cf9010873a245c7e77dea42f579ebc8aabbab956f5087a9a16333b7ef964caaa3a187fead4825168decdfd4d1d2ae85a
>
>
> *apache-jmeter-5.4.tgz
>
>
> f2a1b98fb79224a97d8038660c97e390b798e0ba57b698bea8ae44f4061b86f7841ecb4165fc657684e89c9a0f8ec984d8a40a32a2f079a56953ce522ad9067a
>
>
> *apache-jmeter-5.4.zip
>
>
> c4f93e603c2aabdef0f26646bbcecda9d95988412ec3725c69eb3d409ddfa8686cca0b0a10f4a341ddc2632e0bc0c594bdd3279b32734a1b949bc24898b7a165
>
>
> *apache-jmeter-5.4_src.tgz
>
>
> c1ed92b63b9076bc802731b4ab5c82d76e16d74a04e40031f5fa6d828320f92374732210eddfc1fe8a1b14ad01893fa75855c4871949fee1781e3a350225b66f
>
>
> *apache-jmeter-5.4_src.zip
>
>
>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.4 RC2

[Philippe Mouawad]

Hello Milamber,
Thanks for RM.
When do you plan the official announcement ?

Thanks

On Thu, Dec 3, 2020 at 6:56 AM Milamber  wrote:

> Hello,
>
> Thanks very much to all who voted for this release.
>
> The votes were as follows:
>
> === +1 vote (with *: binding) ===
>
> Felix Schumacher (fschumacher)*
> Philippe Mouawad (pmouawad)*
> Woonsan Ko (woonsan)
> Bruno Demion (milamber)*
>
> ===
>
> There were no other votes, so the vote passes.
>
> I will prepare the delivery of the release for having an official announce
> after the mirrors sync.
>
> Milamber
>
> On 11/29/20 4:55 PM, Milamber wrote:
> > Hello,
> >
> > The second release candidate for JMeter 5.4 (079404a06a) has been
> > prepared, and your votes are solicited.
> >
> > This release brings some new features and improvements, and also fixes
> > bugs.
> >
> > Please, test this release candidate (with load tests and/or functional
> > tests) using Java 8+ on Linux/Windows/macOS, especially on the changes.
> > Feedback is very welcome within the next 72 hours.
> >
> > You can read the New and Noteworthy section with some screenshots to
> > illustrate improvements and full list of changes at:
> > https://apache.github.io/jmeter-site-preview/site/changes.html
> >
> > JMeter is a Java desktop application designed to load test functional
> > behavior and measure performance. The current version targets Java 8+
> >
> > Download - Archives/hashes/sigs:
> > https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-5.4-rc2
> > (dist revision 44732)
> >
> > RAT report:
> > https://apache.github.io/jmeter-site-preview/rat/
> >
> > SHA512 hashes of archives for this vote: see footnote [1]
> >
> > Site preview is here:
> > https://apache.github.io/jmeter-site-preview/site/
> >
> > JavaDoc API preview is here:
> > https://apache.github.io/jmeter-site-preview/site/api/
> >
> > Maven staging repository is accessible here:
> >
> https://repository.apache.org/content/repositories/orgapachejmeter-1068/org/apache/jmeter/
> >
> >
> > Tag:
> >
> https://gitbox.apache.org/repos/asf?p=jmeter.git;a=tag;h=refs/tags/v5.4-rc2
> >
> >
> > Keys are here:
> > https://www.apache.org/dist/jmeter/KEYS
> >
> > N.B.
> > To create the distribution and test JMeter: "./gradlew build -Prelease
> > -PskipSign".
> >
> > JMeter 5.4 requires Java 8 or later to run.
> >
> > The artifacts were built with
> >   Java(TM) SE Runtime Environment Oracle Corporation (build
> > 1.8.0_221-b11)
> >   Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build
> > 25.221-b11, mixed mode)
> >
> > Some known issues and incompatible changes are listed on changes page.
> >
> https://apache.github.io/jmeter-site-preview/site/changes.html#Known%20problems%20and%20workarounds
> >
> >
> >
> > All feedback and vote are welcome.
> >
> > [  ] +1  I support this release
> > [  ] +0  I am OK with this release
> > [  ] -0  OK, but
> > [  ] -1  I do not support this release (please indicate why)
> >
> > The vote will remain open for at least 72 hours.
> >
> > The PMC members please indicate the mention "(binding)" with your vote.
> >
> >
> > Note: If the vote passes, the intention is to release the archive files
> > and rename the RC tag as the release tag.
> >
> > Thanks in advance!
> >
> > Milamber
> >
> > ===
> > [1] SHA512 hashes of archives for this vote:
> >
> >
> 47e4d6fe4ba327685636a0dd170a1732cf9010873a245c7e77dea42f579ebc8aabbab956f5087a9a16333b7ef964caaa3a187fead4825168decdfd4d1d2ae85a
>
> >
> > *apache-jmeter-5.4.tgz
> >
> f2a1b98fb79224a97d8038660c97e390b798e0ba57b698bea8ae44f4061b86f7841ecb4165fc657684e89c9a0f8ec984d8a40a32a2f079a56953ce522ad9067a
>
> >
> > *apache-jmeter-5.4.zip
> >
> c4f93e603c2aabdef0f26646bbcecda9d95988412ec3725c69eb3d409ddfa8686cca0b0a10f4a341ddc2632e0bc0c594bdd3279b32734a1b949bc24898b7a165
>
> >
> > *apache-jmeter-5.4_src.tgz
> >
> c1ed92b63b9076bc802731b4ab5c82d76e16d74a04e40031f5fa6d828320f92374732210eddfc1fe8a1b14ad01893fa75855c4871949fee1781e3a350225b66f
>
> >
> > *apache-jmeter-5.4_src.zip
> >
> >
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.4 RC1

[Philippe Mouawad]

Hello Felix,

I am ok with your proposal

Regards

On Tuesday, November 24, 2020, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 24.11.20 um 17:04 schrieb Felix Schumacher:
> > Am 24.11.20 um 16:01 schrieb Philippe Mouawad:
> >> On Tue, Nov 24, 2020 at 3:52 PM Felix Schumacher <
> >> felix.schumac...@internetallee.de> wrote:
> >>
> >>> Am 24.11.20 um 15:37 schrieb Philippe Mouawad:
> >>>> On Mon, Nov 23, 2020 at 3:45 PM Felix Schumacher <
> >>>> felix.schumac...@internetallee.de> wrote:
> >>>>
> >>>>> Am 23.11.20 um 13:04 schrieb Philippe Mouawad:
> >>>>>> Hello,
> >>>>>> Thanks for the release !
> >>>>>>
> >>>>>> I notice a first problem with plugins manager , if we install it ,
> >>> jmeter
> >>>>>> does not start with this error:
> >>>>>>
> >>>>>>- First, I think we should not fail if 3rd party plugin has an
> issue
> >>>>>>- What should we do with this ? Reintroduce the class we removed
> ?
> >>> or
> >>>>>>propose a PR to plugins manager ?
> >>>>> Probably both (or all) :)
> >>>>>
> >>>>> Do we fail on JMeterMenuBar#findMenuCreators? The code catches
> >>>>> Exceptions, logs them and should work (stepping over the broken
> >>>>> MenuCreator). If not, it is not intended and should be fixed.
> >>>>>
> >>>> Yes but it's a NoClassDefFoundError that is thrown , I'll commit a
> fix.
> >>> +1
> >>>> We can provide a PR to PluginsManager but I guess there can be a lot
> of
> >>>> broken plugins by the change.
> >>> I have looked into providing a PR, but I think it will not be that
> easy.
> >>> PluginsManager builds for JMeter 2.13 upwards and some classes have
> >>> public or protected instances of org.apache.log.Logger (which seems to
> >>> be log-kit). Those classes would either have to change their
> >>> serializable id, or something would have to provide a Logger that is
> >>> compatible with the original class (and not generated by JMeters
> classes).
> >>>
> >> Can't we just replace LoggingManager with SLF4J ?
> > https://github.com/undera/jmeter-plugins/pull/426
> >
> > Let's see, what they say.
>
> Andrey reacted really quick and merged the PR, but will not release the
> plugins directly (which is understandable). He pointed out, that there
> will probably be a lot of old plugins, that will need the
> Logger/LoggingManager classes. So, I think we should re-add the classes
> org.apache.log.Logger and org.apache.jorphan.logging.LoggingManager for
> this release and postpone the removal for the next version of JMeter.
>
> Thoughts?
>
>  Felix
>
> >
> > Felix
> >
> >>> So, at the moment I tend to revert the removal of LoggingManager and
> the
> >>> facade for the Logger.
> >>>
> >>> Felix
> >>>
> >>>>> As I don't expect PluginManager to be fixed before a potential
> release,
> >>>>> I think we should add back the class (maybe with a warning message on
> >>>>> instantiation?)
> >>>>>
> >>>> Yes .
> >>>> Should we revert this commit completely :
> >>>>
> >>> https://github.com/apache/jmeter/commit/43217ec8086c8f2dc485936cd020c9
> c8107b698e
> >>>> or only the LoggingManager and Slf4jLogkitLogger
> >>>>
> >>>>
> >>>>
> >>>> Felix
> >>>>>> Details:
> >>>>>> java.lang.NoClassDefFoundError:
> >>> org/apache/jorphan/logging/LoggingManager
> >>>>>> at
> >>>>>>
> >>> org.jmeterplugins.repository.PluginManagerMenuCreator.(
> PluginManagerMenuCreator.java:10)
> >>>>>> ~[jmeter-plugins-manager-1.4.jar:?]
> >>>>>> at java.lang.Class.forName0(Native Method) ~[?:1.8.0_201]
> >>>>>> at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_201]
> >>>>>> at
> >>>>>>
> >>> org.apache.jmeter.gui.util.JMeterMenuBar.findMenuCreators(
> JMeterMenuBar.java:229)
> >>>>>> ~[ApacheJMeter_core.jar:5.4]at
> >>>>>> org.apache.jmeter.gui.util.JMete

Re: [VOTE] Release JMeter 5.4 RC1

[Philippe Mouawad]

On Tue, Nov 24, 2020 at 3:52 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 24.11.20 um 15:37 schrieb Philippe Mouawad:
> > On Mon, Nov 23, 2020 at 3:45 PM Felix Schumacher <
> > felix.schumac...@internetallee.de> wrote:
> >
> >> Am 23.11.20 um 13:04 schrieb Philippe Mouawad:
> >>> Hello,
> >>> Thanks for the release !
> >>>
> >>> I notice a first problem with plugins manager , if we install it ,
> jmeter
> >>> does not start with this error:
> >>>
> >>>- First, I think we should not fail if 3rd party plugin has an issue
> >>>- What should we do with this ? Reintroduce the class we removed ?
> or
> >>>propose a PR to plugins manager ?
> >> Probably both (or all) :)
> >>
> >> Do we fail on JMeterMenuBar#findMenuCreators? The code catches
> >> Exceptions, logs them and should work (stepping over the broken
> >> MenuCreator). If not, it is not intended and should be fixed.
> >>
> > Yes but it's a NoClassDefFoundError that is thrown , I'll commit a fix.
> +1
> >
> > We can provide a PR to PluginsManager but I guess there can be a lot of
> > broken plugins by the change.
>
> I have looked into providing a PR, but I think it will not be that easy.
> PluginsManager builds for JMeter 2.13 upwards and some classes have
> public or protected instances of org.apache.log.Logger (which seems to
> be log-kit). Those classes would either have to change their
> serializable id, or something would have to provide a Logger that is
> compatible with the original class (and not generated by JMeters classes).
>
Can't we just replace LoggingManager with SLF4J ?

>
> So, at the moment I tend to revert the removal of LoggingManager and the
> facade for the Logger.
>
> Felix
>
> >
> >
> >> As I don't expect PluginManager to be fixed before a potential release,
> >> I think we should add back the class (maybe with a warning message on
> >> instantiation?)
> >>
> > Yes .
> > Should we revert this commit completely :
> >
> https://github.com/apache/jmeter/commit/43217ec8086c8f2dc485936cd020c9c8107b698e
> >
> > or only the LoggingManager and Slf4jLogkitLogger
> >
> >
> >
> > Felix
> >>> Details:
> >>> java.lang.NoClassDefFoundError:
> org/apache/jorphan/logging/LoggingManager
> >>> at
> >>>
> >>
> org.jmeterplugins.repository.PluginManagerMenuCreator.(PluginManagerMenuCreator.java:10)
> >>> ~[jmeter-plugins-manager-1.4.jar:?]
> >>> at java.lang.Class.forName0(Native Method) ~[?:1.8.0_201]
> >>> at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_201]
> >>> at
> >>>
> >>
> org.apache.jmeter.gui.util.JMeterMenuBar.findMenuCreators(JMeterMenuBar.java:229)
> >>> ~[ApacheJMeter_core.jar:5.4]at
> >>> org.apache.jmeter.gui.util.JMeterMenuBar.createMenuBar(JMeterMenuBar.
> >>> java:196) ~[ApacheJMeter_core.jar:5.4]at
> >>> org.apache.jmeter.gui.util.JMeterMenuBar.(JMeterMenuBar.java:11
> >>> 7) ~[ApacheJMeter_core.jar:5.4]at
> >>> org.apache.jmeter.gui.MainFrame.init(MainFrame.java:514) ~[ApacheJMet
> >>> er_core.jar:5.4]
> >>> at org.apache.jmeter.gui.MainFrame.(MainFrame.java:231)
> >>> ~[ApacheJM
> >>> eter_core.jar:5.4]
> >>>
> >>> On Mon, Nov 23, 2020 at 12:20 PM Milamber  wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> The first release candidate for JMeter 5.4 (8f58074e67) has been
> >>>> prepared, and your votes are solicited.
> >>>>
> >>>> This release brings some new features and improvements, and also fixes
> >>>> bugs.
> >>>>
> >>>> Please, test this release candidate (with load tests and/or functional
> >>>> tests) using Java 8+ on Linux/Windows/macOS, especially on the
> changes.
> >>>> Feedback is very welcome within the next 72 hours.
> >>>>
> >>>> You can read the New and Noteworthy section with some screenshots to
> >>>> illustrate improvements and full list of changes at:
> >>>> https://apache.github.io/jmeter-site-preview/site/changes.html
> >>>>
> >>>> JMeter is a Java desktop application designed to load test functional
> >>>> behavior and measure performance. The current version targets 

Re: [jmeter] branch master updated: Bug 64935 - A broken plugin class should not prevent JMeter from starting

[Philippe Mouawad]

Ok by me if you want to change it

On Tue, Nov 24, 2020 at 3:57 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 24.11.20 um 15:50 schrieb pmoua...@apache.org:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > pmouawad pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/jmeter.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >  new 88be852  Bug 64935 - A broken plugin class should not prevent
> JMeter from starting
> > 88be852 is described below
> >
> > commit 88be852762cd5db86ecd7d8b035549a9782a5cb9
> > Author: pmouawad 
> > AuthorDate: Tue Nov 24 15:49:49 2020 +0100
> >
> > Bug 64935 - A broken plugin class should not prevent JMeter from
> > starting
> > ---
> >  .../src/main/java/org/apache/jmeter/gui/util/JMeterMenuBar.java | 6
> +-
> >  xdocs/changes.xml   | 1
> +
> >  2 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git
> a/src/core/src/main/java/org/apache/jmeter/gui/util/JMeterMenuBar.java
> b/src/core/src/main/java/org/apache/jmeter/gui/util/JMeterMenuBar.java
> > index f05d262..0091776 100644
> > ---
> a/src/core/src/main/java/org/apache/jmeter/gui/util/JMeterMenuBar.java
> > +++
> b/src/core/src/main/java/org/apache/jmeter/gui/util/JMeterMenuBar.java
> > @@ -232,8 +232,12 @@ public class JMeterMenuBar extends JMenuBar
> implements LocaleChangeListener {
> >  MenuCreator creator = (MenuCreator)
> commandClass.getDeclaredConstructor().newInstance();
> >  creators.add(creator);
> >  }
> > +} catch (NoClassDefFoundError e) {
> > +log.error("Exception registering implementation:{}
> of interface:{}, a dependency used by the plugin class is missing",
> > +strClassName, MenuCreator.class, e);
> >  } catch (Exception e) {
> > -log.error("Exception registering {} with
> implementation: {}", MenuCreator.class, strClassName, e);
> > +log.error("Exception registering implementation
> {} of interface:{}, a jar is probably missing",
> > +strClassName, MenuCreator.class, e);
>
> Should we really take a guess at the reason for the Exception?
>
> The messages are almost identical, except that the first has no spaces
> between the colon and the placeholders and the second one has one space
> instead of the colon (plus the guessed reasons). I think we should add a
> space after the colons and we might add parenthesis around the
> placeholders: ... implementation: [{}] of ...
>
> (Will do so in a moment ;))
>
> Felix
>
> >  }
> >  }
> >  } catch (IOException e) {
> > diff --git a/xdocs/changes.xml b/xdocs/changes.xml
> > index 05381dc..5ba3735 100644
> > --- a/xdocs/changes.xml
> > +++ b/xdocs/changes.xml
> > @@ -227,6 +227,7 @@ applications when JMeter is starting up.
> >  64453Darklaf: Save Test Plan as New Folder
> failure
> >  64625Darklaf: trying to select a folder in Browse
> leads to an error popup and stacktrace
> >  64711Textarea Colors are not good in dark modes.
> Contributed by Jannis Weis
> > +64935A broken plugin class should not prevent JMeter
> from starting
> >  
> >
> >   
> >
>


-- 
Cordialement.
Philippe Mouawad.

Re: [VOTE] Release JMeter 5.4 RC1

[Philippe Mouawad]

On Mon, Nov 23, 2020 at 3:45 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 23.11.20 um 13:04 schrieb Philippe Mouawad:
> > Hello,
> > Thanks for the release !
> >
> > I notice a first problem with plugins manager , if we install it , jmeter
> > does not start with this error:
> >
> >- First, I think we should not fail if 3rd party plugin has an issue
> >- What should we do with this ? Reintroduce the class we removed ? or
> >propose a PR to plugins manager ?
>
> Probably both (or all) :)
>
> Do we fail on JMeterMenuBar#findMenuCreators? The code catches
> Exceptions, logs them and should work (stepping over the broken
> MenuCreator). If not, it is not intended and should be fixed.
>

Yes but it's a NoClassDefFoundError that is thrown , I'll commit a fix.

We can provide a PR to PluginsManager but I guess there can be a lot of
broken plugins by the change.


> As I don't expect PluginManager to be fixed before a potential release,
> I think we should add back the class (maybe with a warning message on
> instantiation?)
>

Yes .
Should we revert this commit completely :
https://github.com/apache/jmeter/commit/43217ec8086c8f2dc485936cd020c9c8107b698e

or only the LoggingManager and Slf4jLogkitLogger



Felix
>
> >
> > Details:
> > java.lang.NoClassDefFoundError: org/apache/jorphan/logging/LoggingManager
> > at
> >
> org.jmeterplugins.repository.PluginManagerMenuCreator.(PluginManagerMenuCreator.java:10)
> > ~[jmeter-plugins-manager-1.4.jar:?]
> > at java.lang.Class.forName0(Native Method) ~[?:1.8.0_201]
> > at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_201]
> > at
> >
> org.apache.jmeter.gui.util.JMeterMenuBar.findMenuCreators(JMeterMenuBar.java:229)
> > ~[ApacheJMeter_core.jar:5.4]at
> > org.apache.jmeter.gui.util.JMeterMenuBar.createMenuBar(JMeterMenuBar.
> > java:196) ~[ApacheJMeter_core.jar:5.4]at
> > org.apache.jmeter.gui.util.JMeterMenuBar.(JMeterMenuBar.java:11
> > 7) ~[ApacheJMeter_core.jar:5.4]at
> > org.apache.jmeter.gui.MainFrame.init(MainFrame.java:514) ~[ApacheJMet
> > er_core.jar:5.4]
> > at org.apache.jmeter.gui.MainFrame.(MainFrame.java:231)
> > ~[ApacheJM
> > eter_core.jar:5.4]
> >
> > On Mon, Nov 23, 2020 at 12:20 PM Milamber  wrote:
> >
> >> Hello,
> >>
> >> The first release candidate for JMeter 5.4 (8f58074e67) has been
> >> prepared, and your votes are solicited.
> >>
> >> This release brings some new features and improvements, and also fixes
> >> bugs.
> >>
> >> Please, test this release candidate (with load tests and/or functional
> >> tests) using Java 8+ on Linux/Windows/macOS, especially on the changes.
> >> Feedback is very welcome within the next 72 hours.
> >>
> >> You can read the New and Noteworthy section with some screenshots to
> >> illustrate improvements and full list of changes at:
> >> https://apache.github.io/jmeter-site-preview/site/changes.html
> >>
> >> JMeter is a Java desktop application designed to load test functional
> >> behavior and measure performance. The current version targets Java 8+
> >>
> >> Download - Archives/hashes/sigs:
> >> https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-5.4-rc1
> >> (dist revision 44638)
> >>
> >> RAT report:
> >> https://apache.github.io/jmeter-site-preview/rat/
> >>
> >> SHA512 hashes of archives for this vote: see footnote [1]
> >>
> >> Site preview is here:
> >> https://apache.github.io/jmeter-site-preview/site/
> >>
> >> JavaDoc API preview is here:
> >> https://apache.github.io/jmeter-site-preview/site/api/
> >>
> >> Maven staging repository is accessible here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachejmeter-1067/org/apache/jmeter/
> >>
> >> Tag:
> >>
> https://gitbox.apache.org/repos/asf?p=jmeter.git;a=tag;h=refs/tags/v5.4-rc1
> >>
> >> Keys are here:
> >> https://www.apache.org/dist/jmeter/KEYS
> >>
> >> N.B.
> >> To create the distribution and test JMeter: "./gradlew build -Prelease
> >> -PskipSign".
> >>
> >> JMeter 5.4 requires Java 8 or later to run.
> >>
> >> The artifacts were built with
> >>Java(TM) SE Runtime Environment Oracle Corporation (build
> 1.8.0_221-b11)
> >>Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (b

Re: [VOTE] Release JMeter 5.4 RC1

[Philippe Mouawad]

Hello,
Thanks for the release !

I notice a first problem with plugins manager , if we install it , jmeter
does not start with this error:

   - First, I think we should not fail if 3rd party plugin has an issue
   - What should we do with this ? Reintroduce the class we removed ? or
   propose a PR to plugins manager ?

Details:
java.lang.NoClassDefFoundError: org/apache/jorphan/logging/LoggingManager
at
org.jmeterplugins.repository.PluginManagerMenuCreator.(PluginManagerMenuCreator.java:10)
~[jmeter-plugins-manager-1.4.jar:?]
at java.lang.Class.forName0(Native Method) ~[?:1.8.0_201]
at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_201]
at
org.apache.jmeter.gui.util.JMeterMenuBar.findMenuCreators(JMeterMenuBar.java:229)
~[ApacheJMeter_core.jar:5.4]at
org.apache.jmeter.gui.util.JMeterMenuBar.createMenuBar(JMeterMenuBar.
java:196) ~[ApacheJMeter_core.jar:5.4]at
org.apache.jmeter.gui.util.JMeterMenuBar.(JMeterMenuBar.java:11
7) ~[ApacheJMeter_core.jar:5.4]at
org.apache.jmeter.gui.MainFrame.init(MainFrame.java:514) ~[ApacheJMet
er_core.jar:5.4]
at org.apache.jmeter.gui.MainFrame.(MainFrame.java:231)
~[ApacheJM
eter_core.jar:5.4]

On Mon, Nov 23, 2020 at 12:20 PM Milamber  wrote:

> Hello,
>
> The first release candidate for JMeter 5.4 (8f58074e67) has been
> prepared, and your votes are solicited.
>
> This release brings some new features and improvements, and also fixes
> bugs.
>
> Please, test this release candidate (with load tests and/or functional
> tests) using Java 8+ on Linux/Windows/macOS, especially on the changes.
> Feedback is very welcome within the next 72 hours.
>
> You can read the New and Noteworthy section with some screenshots to
> illustrate improvements and full list of changes at:
> https://apache.github.io/jmeter-site-preview/site/changes.html
>
> JMeter is a Java desktop application designed to load test functional
> behavior and measure performance. The current version targets Java 8+
>
> Download - Archives/hashes/sigs:
> https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-5.4-rc1
> (dist revision 44638)
>
> RAT report:
> https://apache.github.io/jmeter-site-preview/rat/
>
> SHA512 hashes of archives for this vote: see footnote [1]
>
> Site preview is here:
> https://apache.github.io/jmeter-site-preview/site/
>
> JavaDoc API preview is here:
> https://apache.github.io/jmeter-site-preview/site/api/
>
> Maven staging repository is accessible here:
>
> https://repository.apache.org/content/repositories/orgapachejmeter-1067/org/apache/jmeter/
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=jmeter.git;a=tag;h=refs/tags/v5.4-rc1
>
> Keys are here:
> https://www.apache.org/dist/jmeter/KEYS
>
> N.B.
> To create the distribution and test JMeter: "./gradlew build -Prelease
> -PskipSign".
>
> JMeter 5.4 requires Java 8 or later to run.
>
> The artifacts were built with
>Java(TM) SE Runtime Environment Oracle Corporation (build 1.8.0_221-b11)
>Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build
> 25.221-b11, mixed mode)
>
> Some known issues and incompatible changes are listed on changes page.
>
> https://apache.github.io/jmeter-site-preview/site/changes.html#Known%20problems%20and%20workarounds
>
>
> All feedback and vote are welcome.
>
> [  ] +1  I support this release
> [  ] +0  I am OK with this release
> [  ] -0  OK, but
> [  ] -1  I do not support this release (please indicate why)
>
> The vote will remain open for at least 72 hours.
>
> The PMC members please indicate the mention "(binding)" with your vote.
>
>
> Note: If the vote passes, the intention is to release the archive files
> and rename the RC tag as the release tag.
>
> Thanks in advance!
>
> Milamber
>
> ===
> [1] SHA512 hashes of archives for this vote:
>
>
> ae1e2ecbde06ae6cd8f7af3d9f5f284ebdc4c2c462c917da9f34755d8cdc133c9371c4bc349fd3ec2f0bc431c6bfb8e5d8b00389f2eb037120804edf02042e9f
> *apache-jmeter-5.4.tgz
>
> 8f859d8121f2f54bc9b73885ab4cc9b5d86911c2bc498d22f0add13263c0039d5579d703f2db9f876d1a556128079fbf67a07f7d98dcfc87104da418ca181f84
> *apache-jmeter-5.4.zip
>
> e5bf807b13f08476c0808f2c0786da4e92d56ab6c63849eec47ae9a8862d7ac4ac635ff48baec8dcfab3528a97dbc6cc07f8341929c416e61fa3cb498e790e70
> *apache-jmeter-5.4_src.tgz
>
> 096b52420c08522a5a5f2492562e2ead301ff028ac46ac9b52f176f34221a0f24005d9529335d0ec850b105ff0aaa14b7522d0db2009c94b3977c784628e1f6b
> *apache-jmeter-5.4_src.zip
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: Release JMeter 5.4

[Philippe Mouawad]

Hello,
I think you can start starting from today.


Regards

On Thu, Nov 19, 2020 at 7:45 PM Milamber  wrote:

> Hello,
>
> When would you start the first RC ?
>
> Milamber
>
> On 11/18/20 2:31 PM, Felix Schumacher wrote:
> > Am 17.11.20 um 19:26 schrieb Milamber:
> >> I can act as Release Manager.
> > That would be awesome :)
> >
> > Felix
> >
> >
> >>
> >>
> >> On 11/16/20 12:34 PM, Felix Schumacher wrote:
> >>> Am 14.11.20 um 19:48 schrieb Philippe Mouawad:
> >>>> Hello folks,
> >>>>
> >>>> I merged the second PR.
> >>>> And tested the first one, it's not ready yet.
> >>>>
> >>>> So, if we are ok to release, is there a volunteer for Release
> >>>> Management ?
> >>> With the fix of Bug64915, I think a release would be OK (and should be
> >>> done, as we haven't released for a long time).
> >>>
> >>> Felix
> >>>
> >>>> Thanks
> >>>> Regards
> >>>>
> >>>> On Wednesday, October 21, 2020, Philippe Mouawad
> >>>> 
> >>>> wrote:
> >>>>
> >>>>> Hello Felix,
> >>>>> Thanks for your answer.
> >>>>> Yes all pending issues I am aware of have now been fixed.
> >>>>>
> >>>>> The two things we need to decide relate to whether we want to merge:
> >>>>>
> >>>>>  - Autocorrelation in Alpha:
> >>>>> https://github.com/apache/jmeter/pull/499
> >>>>>  - Raw InfluxDB BackendListener client:
> >>>>>  https://github.com/apache/jmeter/pull/544
> >>>>>
> >>>>>
> >>>>>
> >>>>> Regards
> >>>>>
> >>>>> On Wed, Oct 21, 2020 at 11:55 AM Felix Schumacher <
> >>>>> felix.schumac...@internetallee.de> wrote:
> >>>>>
> >>>>>> Am 17.10.20 um 15:18 schrieb Philippe Mouawad:
> >>>>>>> Hello,
> >>>>>>> I hope you’re all doing well.
> >>>>>>>
> >>>>>>> I am starting a new thread as the old one related to 5.3.1 seems to
> >>>>>> keep us
> >>>>>>> in a stuck state :) and we are now more in a position for a 5.4.
> >>>>>>>
> >>>>>>> So, what about releasing a 5.4 ?
> >>>>>> My last information was, that we were waiting on the fix in the
> >>>>>> darklaf
> >>>>>> implementation. Has that been fixed?
> >>>>>>
> >>>>>> I have no things left in my pipeline, that would block any release
> :)
> >>>>>>
> >>>>>> Felix
> >>>>>>
> >>>>>>> Regards
> >>>>>>> Philippe
> >>>>>>>
> >>>>>>>
> >>>>> --
> >>>>> Cordialement.
> >>>>> Philippe Mouawad.
> >>>>>
> >>>>>
> >>>>>
> >>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: "gradlew eclipse" is broken in master branch

[Philippe Mouawad]

Hello,
Deleting and importing again projects helped a bit, thanks Vladimir.
I guess the issue you mention leads to error in dependant project:
"ResourceKeyUsageTest cannot be resolved to a type"

I think I am using a too old version of Eclipse for the project state now.
I'll upgrade and give feedback.

Thanks
Regards
On Sun, Nov 15, 2020 at 10:48 PM Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Hello Felix,
> You are right, I didn't dig too much and I think I sent a mail too early.
>
> What version of Eclipse are you using ? And which Groovy plugin did you
> install ?
>
> Thanks
>
> On Sun, Nov 15, 2020 at 10:15 PM Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
>>
>> Am 14.11.20 um 19:47 schrieb Philippe Mouawad:
>> > Hello folks,
>> > I pulled latest version of JMeter and ran
>> > ./gradlew eclipse
>> >
>> > It is broken for me as it generates broken .classpath files.
>> > The path to dependencies contains an additional UUID :
>> >
>> > For example:
>> > > >
>> sourcepath="/Users/PhilM/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-lang3/3.11/24014867e470db3942db53b17a4902f4215d5ea8/commons-lang3-3.11-sources.jar"
>> > kind="lib"
>> >
>> path="/Users/PhilM/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-lang3/3.11/68e9a6adf7cf8eb7e9d31bbc554c7c75eeaac568/commons-lang3-3.11.jar">
>> > 
>> > > > value="main,test"/>
>> > 
>> > 
>> >
>> > Do you have the same issue ?
>>
>> While I have the same links, I believe it is not a problem, as those
>> files are on my disk - stored at the location thy point to.
>>
>> Why do you think this is problematic?
>>
>> I have another problem with the eclipse setup. It is because the class
>> JMeterTestCase is located in 'core' in the test classes, it is not
>> exported to the subprojects anymore and the tests in the subprojects are
>> marked as errors, because the parent classes can't be found.
>>
>> You can fix it by hand, if you go to "Configure build path -> Projects
>> -> core -> Without test code: Yes" and toggle it to "No".
>>
>> How can we fix this in a clean way? Move the classes to src/main? Export
>> the test classes to the tests of the subprojects? How?
>>
>> No real clue
>>
>>  Felix
>>
>>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: "gradlew eclipse" is broken in master branch

[Philippe Mouawad]

Hello Felix,
You are right, I didn't dig too much and I think I sent a mail too early.

What version of Eclipse are you using ? And which Groovy plugin did you
install ?

Thanks

On Sun, Nov 15, 2020 at 10:15 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 14.11.20 um 19:47 schrieb Philippe Mouawad:
> > Hello folks,
> > I pulled latest version of JMeter and ran
> > ./gradlew eclipse
> >
> > It is broken for me as it generates broken .classpath files.
> > The path to dependencies contains an additional UUID :
> >
> > For example:
> >  >
> sourcepath="/Users/PhilM/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-lang3/3.11/24014867e470db3942db53b17a4902f4215d5ea8/commons-lang3-3.11-sources.jar"
> > kind="lib"
> >
> path="/Users/PhilM/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-lang3/3.11/68e9a6adf7cf8eb7e9d31bbc554c7c75eeaac568/commons-lang3-3.11.jar">
> > 
> >  > value="main,test"/>
> > 
> > 
> >
> > Do you have the same issue ?
>
> While I have the same links, I believe it is not a problem, as those
> files are on my disk - stored at the location thy point to.
>
> Why do you think this is problematic?
>
> I have another problem with the eclipse setup. It is because the class
> JMeterTestCase is located in 'core' in the test classes, it is not
> exported to the subprojects anymore and the tests in the subprojects are
> marked as errors, because the parent classes can't be found.
>
> You can fix it by hand, if you go to "Configure build path -> Projects
> -> core -> Without test code: Yes" and toggle it to "No".
>
> How can we fix this in a clean way? Move the classes to src/main? Export
> the test classes to the tests of the subprojects? How?
>
> No real clue
>
>  Felix
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: Release JMeter 5.4

[Philippe Mouawad]

Hello folks,

I merged the second PR.
And tested the first one, it's not ready yet.

So, if we are ok to release, is there a volunteer for Release Management ?

Thanks
Regards

On Wednesday, October 21, 2020, Philippe Mouawad 
wrote:

> Hello Felix,
> Thanks for your answer.
> Yes all pending issues I am aware of have now been fixed.
>
> The two things we need to decide relate to whether we want to merge:
>
>- Autocorrelation in Alpha: https://github.com/apache/jmeter/pull/499
>- Raw InfluxDB BackendListener client:
>https://github.com/apache/jmeter/pull/544
>
>
>
> Regards
>
> On Wed, Oct 21, 2020 at 11:55 AM Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
>>
>> Am 17.10.20 um 15:18 schrieb Philippe Mouawad:
>> > Hello,
>> > I hope you’re all doing well.
>> >
>> > I am starting a new thread as the old one related to 5.3.1 seems to
>> keep us
>> > in a stuck state :) and we are now more in a position for a 5.4.
>> >
>> > So, what about releasing a 5.4 ?
>>
>> My last information was, that we were waiting on the fix in the darklaf
>> implementation. Has that been fixed?
>>
>> I have no things left in my pipeline, that would block any release :)
>>
>> Felix
>>
>> >
>> > Regards
>> > Philippe
>> >
>> >
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>

"gradlew eclipse" is broken in master branch

[Philippe Mouawad]

Hello folks,
I pulled latest version of JMeter and ran
./gradlew eclipse

It is broken for me as it generates broken .classpath files.
The path to dependencies contains an additional UUID :

For example:






Do you have the same issue ?
-- 
Regards.
Philippe M.

Re: Release JMeter 5.4

[Philippe Mouawad]

Hello Felix,
Thanks for your answer.
Yes all pending issues I am aware of have now been fixed.

The two things we need to decide relate to whether we want to merge:

   - Autocorrelation in Alpha: https://github.com/apache/jmeter/pull/499
   - Raw InfluxDB BackendListener client:
   https://github.com/apache/jmeter/pull/544



Regards

On Wed, Oct 21, 2020 at 11:55 AM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 17.10.20 um 15:18 schrieb Philippe Mouawad:
> > Hello,
> > I hope you’re all doing well.
> >
> > I am starting a new thread as the old one related to 5.3.1 seems to keep
> us
> > in a stuck state :) and we are now more in a position for a 5.4.
> >
> > So, what about releasing a 5.4 ?
>
> My last information was, that we were waiting on the fix in the darklaf
> implementation. Has that been fixed?
>
> I have no things left in my pipeline, that would block any release :)
>
> Felix
>
> >
> > Regards
> > Philippe
> >
> >
>


-- 
Cordialement.
Philippe Mouawad.

Release JMeter 5.4

[Philippe Mouawad]

Hello,
I hope you’re all doing well.

I am starting a new thread as the old one related to 5.3.1 seems to keep us
in a stuck state :) and we are now more in a position for a 5.4.

So, what about releasing a 5.4 ?

Regards
Philippe


-- 
Cordialement
Philippe M.
Ubik-Ingenierie

Thoughts and plan for PRs

[Philippe Mouawad]

Hello,
I hope you're all fine.

What's your thoughts on:

   - Add GraphQL/HTTP Request Sampler
   https://github.com/apache/jmeter/pull/627
   - Add: ElasticSearch backend listener
   https://github.com/apache/jmeter/pull/615
   - Add BackendListener that sends "raw" results to InfluxDB (
   https://github.com/apache/jmeter/pull/544)

Here are mine:

1) Add GraphQL/HTTP Request Sample:

   - I am in favor of integrating it to the next release
   - Testing GraphQL with JMeter looks really painful
   - The way it is done improves user experience for a technology which is
   gaining attraction without introducing new dependencies
   - Providing a plugin might be more complex


2) Add: ElasticSearch backend listener:

   - The drawbacks I see currently are:
   - For signing on AWS ElasticSearch, It introduces a dependency on
aws-java-sdk
  and google guava which might not be acceptable. This should be
available as
  a pluggable thing instead
  - We need to maintain in core a dependency on a 3rd party that has a
  faster pace in terms of releases
  - There is already a plugin which is maintained by the PR contributor
   , this plugin has users.
   - The addition looks really useful, but I am wondering if it's not
   better that this one remains as a plugin, as its pace of release can be
   faster than JMeter one.


3) Add BackendListener that sends "raw" results to InfluxDB

In the end  and after testing reactivity of the project Vladimir mentioned
as a better alternative, I tend to think this should be merged.
What the current listener does might not be acceptable in certain contexts.


What's your thoughts ?
Thanks
-- 
Regards
Philippe M.

Re: Release a new version 5.3.1 ?

[Philippe Mouawad]

Hello Felix,
Ok.
Well  we have to wait for Darklaf 2.4.10 as 2.4.9 fixed:
- https://github.com/weisJ/darklaf/issues/206
but introduced
- https://github.com/weisJ/darklaf/issues/210

Regards

On Wed, Sep 23, 2020 at 4:28 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
>
> Am 22. September 2020 23:16:59 MESZ schrieb UBIK LOAD PACK Support <
> supp...@ubikloadpack.com>:
> >Hello,
> >How about releasing a 5.3.1 or 5.4 ?
>
> It feels like a 5.3.1 to me. If you ask a tool for sem ver, it will tell
> you otherwise :)
>
> >
> >I think we now have a stable version and it seems urgent to me to
> >release
>
> I have nothing left on my list (except curating the changes.xml with our
> current changes)
>
> Felix
>
> >it.
> >Regards
> >
> >On Sun, Aug 30, 2020 at 12:48 PM Felix Schumacher <
> >felix.schumac...@internetallee.de> wrote:
> >
> >>
> >> Am 29.08.20 um 21:53 schrieb UBIK LOAD PACK Support:
> >> > On Thu, Aug 27, 2020 at 4:41 PM Felix Schumacher <
> >> > felix.schumac...@internetallee.de> wrote:
> >> >
> >> >>
> >> >> Am 27. August 2020 15:53:31 MESZ schrieb Philippe Mouawad <
> >> >> philippe.moua...@gmail.com>:
> >> >>> Hello,
> >> >>> Oups previous mail was sent too fast.
> >> >>>
> >> >>> I hope you're all fine and have spent  nice holidays if you did.
> >> >>>
> >> >>> I think we are ready for a release right ?
> >> >>> Pending issues are:
> >> >>> - https://github.com/apache/jmeter/pull/608 for bug 64553
> >> >
> >> >>> - https://bz.apache.org/bugzilla/show_bug.cgi?id=64624 which has
> >a
> >> >>> patch
> >> >> >from Felix waiting for confirmation
> >> >>
> >> >> Here it would be nice, if you could have a look at it, as you did
> >the
> >> >> original implementation, if I recall correctly.
> >> >>
> >> > I had a look, and left a comment on bugzilla, it LGTM.
> >>
> >> Committed
> >>
> >>
> >> >
> >> >
> >> >> Another pr (#595) that could probably be merged is the one about
> >> freestyle
> >> >> naming for samples recorded by the proxy.
> >> >>
> >> > Same for me, LGTM
> >>
> >> Committed
> >>
> >> Especially MacOS users should have a look at the refactored UI
> >elements,
> >> as I changed a few lines, that had a reference to a UI bug, that was
> >> visible on MacOS, only.
> >>
> >> Felix
> >>
> >> >
> >> >> And what about #593?
> >> >>
> >> > ok by me
> >> >
> >> >>> Since 5.3 has some regressions, it would be nice to release a
> >version
> >> >>> soon.
> >> >> +1
> >> >>
> >> >> Felix
> >> >>
> >> >>> Thanks
> >> >
> >>
>


-- 
Cordialement.
Philippe Mouawad.