Re: [VOTE] Release JMeter 5.6.3 RC2

[Felix Schumacher]

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












OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Require Java 17 in JMeter 6

[Felix Schumacher]

Am 1. Dezember 2023 12:01:57 MEZ schrieb Vladimir Sitnikov 
:
>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: Running tests after gradle update

[Felix Schumacher]

Am 29.04.23 um 15:44 schrieb Vladimir Sitnikov:

Felix> That is what I thought, too. But even changing the source of the
test (with something, I know will break it), didn't work. Spock tests in
the same package (src/components) will run just fine.

It turns out that junit5 tests were not executed since there was no
junit-jupiter engine on the test classpath.
junit4 worked because the vintage engine was there.

I've fixed the issue in
https://github.com/apache/jmeter/commit/e52305d6a4a867ad96e374fadeffe0b67e514894


Yes, works again.

Thanks for fixing this.

Felix



Vladimir



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Running tests after gradle update

[Felix Schumacher]

Am 29.04.23 um 10:59 schrieb Vladimir Sitnikov:

I guess the reason is that execute tests several times. Gradle caches
test results.
In other words, if you execute the same tests with the same source,
then the build does not execute tests again.
However, if you modify test code and/or change dependency, then tests
would be re-executed.


That is what I thought, too. But even changing the source of the test 
(with something, I know will break it), didn't work. Spock tests in the 
same package (src/components) will run just fine.


Another strange thing is, that intellij shows the test as runnable 
(green triangle) and starts running tests, when I press that button, but 
afterwards it reports, that no tests are found:


 Execution failed for task ':src:components:test'.
 > No tests found for given includes: 
[org.apache.jmeter.assertions.TestJSONPathAssertion.testGetExpectedValue](--tests 
filter)


 * Try:
 > Run with --stacktrace option to get the stack trace.
 > Run with --info or --debug option to get more log output.



batchTests are not cached though since they depend on external systems,
so if you execute ./gradlew batchTests, then it will take some time
(batch tests are executed sequentially for now).

I think it is expected that we cache test results.
If we have randomized tests and or tests that depend on external
systems, we should configure them accordingly
so Gradle does not cache them.

WDYT?


I have nothing against caching tests, as long as it works :)

  There are only two hard problems in computer science:

   * Naming things
   * Cache invalidation
   * One off problems

Felix



Vladimir


OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Running tests after gradle update

[Felix Schumacher]

Hi all,

I tried to rebase pr 723 to the current main trunk and it seems to me, 
that most tests are not run anymore. Maybe I am doing something wrong.


I usually do

> ./gradlew test

inside the checked out directory and it runs a lot of tests for a few 
minutes.


Now it is ready after 6s and it seems to run only a few of our tests. It 
reports the following at the end:


BUILD SUCCESSFUL in 6s
205 actionable tasks: 62 executed, 82 from cache, 61 up-to-date

Is this expected?

Felix



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [GitHub] [jmeter] FSchumacher commented on a diff in pull request #5812: Bug #5807 - Fix an ArrayIndexOutOfBoundsException on HTTP parameters …

[Felix Schumacher]

I used the Pair class from org.apache.commons.lang3.tuple.Pair, which 
implements Map.Entry


Am 23.04.23 um 12:50 schrieb Milamber:

Pair class seems no existe in java8?

Le dim. 23 avr. 2023, 11:47, FSchumacher (via GitHub)  a
écrit :


FSchumacher commented on code in PR #5812:
URL:https://github.com/apache/jmeter/pull/5812#discussion_r117438


##

src/protocol/http/src/test/java/org/apache/jmeter/protocol/http/visualizers/RequestViewHTTPQueryMapTest.java:
##
@@ -0,0 +1,45 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to you under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.jmeter.protocol.http.visualizers;
+
+import java.util.Map;
+import java.util.stream.Stream;
+
+import org.junit.jupiter.api.Assertions;
+import org.junit.jupiter.params.ParameterizedTest;
+import org.junit.jupiter.params.provider.Arguments;
+import org.junit.jupiter.params.provider.MethodSource;
+
+class RequestViewHTTPQueryMapTest {
+
+private static Stream data() {
+return Stream.of(
+Arguments.of("k1=v1&==v2", 2),
+Arguments.of("=", 0),
+Arguments.of("k1=v1&=value=v2", 3));
+}
+
+@ParameterizedTest
+@MethodSource("data")
+public void testGetQueryMapWithEmptyKeyAndValue(String query, int
numParamExpect) {
+Map params = RequestViewHTTP.getQueryMap(query);
+Assertions.assertNotNull(params);
+Assertions.assertEquals(numParamExpect, params.size());

Review Comment:
My example code, can be used with Java 8. With Java 11, we could have
used `Map.of(key, value, key2, value2, ...)`.



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




OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

[Felix Schumacher]

Am 11.07.22 um 17:50 schrieb Vladimir Sitnikov:

I've made progress on Bugzilla -> GitHub migration.

Frankly speaking, I'm not comfortable refactoring/maintaining Python code
(which is what many projects use to migrate off Bugzilla),
so I created Kotlin-based project so the data and fields are typed:
https://github.com/vlsi/bugzilla2github

For now, it can download bugs and it can parse XML.
It stores the summary in a local database (
https://github.com/JetBrains/xodus), so it can skip bugs based on change
date.
It is tempting to spawn a web UI that would serve the received bugs from
the same database :)

The next steps I plan to follow are:
* Implement batched downloader (ASF imposes 45 requests per 180 seconds
limit), so it downloads 100 or 500 bugs in a single HTTP request
I'm going to use multi-bug requests like
https://bz.apache.org/bugzilla/show_bug.cgi?id=59681=48542=xml
* Add authorization (Bugzilla returns truncated results for unauthorized
requests)
* Add regexp processing so JMeter bugs look better in GitHub formatting.
* Do something with attachments. We could either link files via
bz.apache.org/... URLs (I don't know if it would work),
or we could create a separate jmeter-bug-attachments repository, we could
migrate Bugzilla attachments there,
and then we reference the images and files from that repository via
raw.githubusercontent.com.
Creating jmeter-bug-attachments repo would require slightly more work,
however, then we lose nothing if Bugzilla dies.

Let me know if you want to get your hands dirty on that.


* Maybe we could dump the data from the MySQL database, import in into a 
clone and work from that instance instead through the UI?


* What kind of processing do you want to do on the text with regexps?

* What type of attachements can be used on Github directly (I am really 
lazy, haven't used it before and haven't tried)?


Felix



Vladimir



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Release JMeter 5.5 RC2

[Felix Schumacher]

Am 27.04.22 um 13:23 schrieb Milamber:

Hello,

The second release candidate for JMeter 5.5 (ce94f0db8a) 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-rc2
(dist revision 54112)

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-1077/org/apache/jmeter/ 



Tag:
https://gitbox.apache.org/repos/asf?p=jmeter.git;a=tag;h=refs/tags/v5.5-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.5 requires Java 8 or later to run.

The artifacts were built with
  Java(TM) SE Runtime Environment Oracle Corporation (build 
1.8.0_331-b09)
  Java HotSpot(TM) 64-Bit Server VM Oracle Corporation (build 
25.331-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
[x] -1  I do not support this release (please indicate why)


* The splash screen doesn't show correctly with Java 11 and 17 on Linux 
and Windows (Bug 66044)


* Philippe reported a regression on the report feature

While a fix for Bug 66044 is in trunk (and waits for feedback), I am not 
sure, how we should handle the reporting regression.


Felix



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:

252474b2cd347df2779ef76cdc299e0ebe96bf015997934f1f4e57c14d5487686a992c229e34a8288dad20a7b306b1482aaf631178a39e09cb49e8a11b293ee2 


*apache-jmeter-5.5.tgz
bdea559eff760df5978b436a3af929b55ef4e2691e96f09378c3215374cf84667c3630dae0dd4273adc9da1e2d3ce807f88ce7e195d8f5ca0380efec2aba3cec 


*apache-jmeter-5.5.zip
aa2be2d34bdb711ca1ff7a425812b94373760f3ea685d27263191fec101acea426176ce4233dc7a4fb19b30adfbfd7a9048783fd07e2fb59b4aa9719bbc0647c 


*apache-jmeter-5.5_src.tgz
a7f448ffc519fb089383c3b6eab8eeb34d543e8705a4503adc927d967c79ff4239b0ca848620b823b679b0db40ca84e16f603ad6028b5640b1abe98ffdf860f0 


*apache-jmeter-5.5_src.zip




OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Release JMeter 5.5 RC1

[Felix Schumacher]

We have another reason to cancel the vote (bug 66044). I will submit a 
fix soon.


Felix

Am 28.04.22 um 10:43 schrieb Milamber:

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.







OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Release JMeter 5.5 RC1

[Felix Schumacher]

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







OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Jenkins build is back to normal : JMeter » JMeter-trunk #420

[Felix Schumacher]

According to https://jmeter.apache.org/mail2.html#JMeterDev and the mail 
headers in all mails sent by this mailing list:


Send an email to dev-unsubscr...@jmeter.apache.org

Be sure to use the same sender address as the one, you get the mails 
sent to.


Felix

Am 31.03.22 um 21:28 schrieb Afsaneh Abouei:

How to unsubscribe?

On Wed, 9 Mar 2022, 20:34 Apache Jenkins Server,
wrote:


See <
https://ci-builds.apache.org/job/JMeter/job/JMeter-trunk/420/display/redirect



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Release JMeter 5.5 RC1

[Felix Schumacher]

Am 20.03.22 um 16:35 schrieb Felix Schumacher:



Am 16.03.22 um 18:14 schrieb Vladimir Sitnikov:

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?
While I don't think, that setting this has introduced a regression (I 
disabled the line, that would enable the hack), I think I might have 
another alternative to our problem:


https://github.com/apache/jmeter/pull/706

This will disable word/line wrapping (when the result is bigger than 
10.000 chars; should probably be made configurable). That hack will 
speed up the rendering a lot. My tests with the biggish result, are 
showing no noticeable delay while switching between the results.


Note, that this will fix the text view, only. When switching to regex 
tester (or any other view), the problem of long loading times will 
reappear. (I think, that we can use the same hack for most of our views).


Felix

To answer your question. If disabling the kerning makes the result 
appear faster on your setup, I am +1 to setting this to 0 for all Java 
versions (or all Java versions <17).


Felix


Vladimir



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Release JMeter 5.5 RC1

[Felix Schumacher]

Am 16.03.22 um 18:14 schrieb Vladimir Sitnikov:

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?
While I don't think, that setting this has introduced a regression (I 
disabled the line, that would enable the hack), I think I might have 
another alternative to our problem:


https://github.com/apache/jmeter/pull/706

This will disable word/line wrapping (when the result is bigger than 
10.000 chars; should probably be made configurable). That hack will 
speed up the rendering a lot. My tests with the biggish result, are 
showing no noticeable delay while switching between the results.


To answer your question. If disabling the kerning makes the result 
appear faster on your setup, I am +1 to setting this to 0 for all Java 
versions (or all Java versions <17).


Felix



Vladimir



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Slow "view results in tree" in 5.5 with Java11 (was [VOTE] Release JMeter 5.5 RC1)

[Felix Schumacher]

Am 16.03.22 um 09:04 schrieb Vladimir Sitnikov:

Felix, thank you.

I went over the stacktrace and found an interesting case:

8231084: Large performance regression in SwingMark TextArea in 14-b13
https://github.com/openjdk/jdk/commit/007a0fb2321f1691d341a3ceb9d321cd01d506c8
https://mail.openjdk.java.net/pipermail/swing-dev/2019-November/009850.html

I'm not sure it is the same issue we are running into.


I am not sure, as it happens on JDK 8 and it doesn't throw errors or 
compute wrong sizes, but is "just" slow.


Felix



Vladimir



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Release JMeter 5.5 RC1

[Felix Schumacher]

Well, Vincent seemed to be happy with the new setting for kerning tuning.

I would say, that my issue is not a regression and therefore should be 
not a blocker.


Felix

Am 16.03.22 um 16:22 schrieb 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.





OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Release JMeter 5.5 RC1

[Felix Schumacher]

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


I tried the attached file.

It samples heise.de/newsticker <http://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.




OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Release JMeter 5.5 RC1

[Felix Schumacher]

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



  

  
  false
  true
  false
  

  
  


  
continue

  false
  1

1
1
false


true
  
  

  false
  
saveConfig

  true
  true
  true
  true
  true
  true
  true
  true
  true
  false
  true
  true
  false
  false
  false
  true
  false
  false
  false
  true
  0
  true
  true
  true
  true
  true
  true

  
  



  

  
  heise.de/newsticker
  
  
  
  
  GET
  true
  false
  true
  false
  
  
  


  

  



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Release JMeter 5.5 RC1

[Felix Schumacher]

For the documentation? No, but for the other issue, I would think.

Am 15.03.22 um 09:21 schrieb Milamber:

Felix, need a RC2 for this?

On 14/03/2022 20:16, Felix Schumacher wrote:


Thanks, has been updated.

Felix

Am 14.03.22 um 17:51 schrieb Vincent Daburon:

Hi,

I find a little bug in the help manual

The JSON JMESPath don't extract values from XML but from JSON
JSON JMESPath Extractor
This test element allows the user to extract value(s) from structured
response - XML or (X)HTML - using JMESPath query language

Regards.
Vincent DABURON

Le lun. 14 mars 2022 à 13:19, Vincent Daburon  a 
écrit :



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





OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Release JMeter 5.5 RC1

[Felix Schumacher]

What about setting the setting as default?

In my case (switching from an empty sampler to a biggish sampler under 
windows), the setting has not solved the long delay. Maybe I did a 
mistake and will look further into it. (Could anyone confirm, that 
switching between 0 and biggish (200-600 KByte) samples will inflict an 
unresponsive GUI?)


But either way, I think we should not release rc1 as it will not look 
good on windows with Java 11.


Felix

Am 15.03.22 um 09:23 schrieb Milamber:

Vincent, Vladimir,

Need to add this solve to the section "Known problems and workarounds" 
in changes page? and do a RC2?


Milamber

On 14/03/2022 17:51, Vincent Daburon wrote:

Hi,

I find a little bug in the help manual

The JSON JMESPath don't extract values from XML but from JSON
JSON JMESPath Extractor
This test element allows the user to extract value(s) from structured
response - XML or (X)HTML - using JMESPath query language

Regards.
Vincent DABURON

Le lun. 14 mars 2022 à 13:19, Vincent Daburon  a 
écrit :



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





OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Release JMeter 5.5 RC1

[Felix Schumacher]

Thanks, has been updated.

Felix

Am 14.03.22 um 17:51 schrieb Vincent Daburon:

Hi,

I find a little bug in the help manual

The JSON JMESPath don't extract values from XML but from JSON
JSON JMESPath Extractor
This test element allows the user to extract value(s) from structured
response - XML or (X)HTML - using JMESPath query language

Regards.
Vincent DABURON

Le lun. 14 mars 2022 à 13:19, Vincent Daburon  a écrit :


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



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Slow "view results in tree" in 5.5 with Java11 (was [VOTE] Release JMeter 5.5 RC1)

[Felix Schumacher]

On Linux a delay is noticeable, when switching from empty to biggish, 
but seems only like 1 to 2 seconds.


Tested with an old Oracle JDK and OpenJDK 8, 11 and 17.

Felix

Am 14.03.22 um 15:07 schrieb Felix Schumacher:
This slowness happens on Windows 10 with Java 11 and OpenJDK 8 (282), 
whenever I switch from an "empty" sample to a "biggish" sample. 
Switching from a "biggish" sample to another "biggish" sample has no 
real performance impact (below 1 second, I would say).


Will try with Linux later.

Felix

Am 14.03.2022 14:51, schrieb Felix Schumacher:

I think I can reproduce it. I sampled a biggish page. It recorded
three sub samples. Two redirects and the actual page.
Clicking on the main sample takes one or two seconds. Changing to the
redirect is fast, but changing back to the main sample or the sub
sample with the page is incredibly slow.

Gui is not responding, as the awt thread is calculating the preferred
view size and is almost all the time in
sun.font.SunLayoutEngine.shape.

Felix

Am 14. März 2022 13:40:46 MEZ schrieb Vladimir Sitnikov
:

When i clique to display the resultat data (html boy) the JMeter is
very slow to show the page.
I need to wait 4 sec to 8 sec between click and the http sampler and
the display in text format.


Vincent, do you think you could create a reproducer for the issue? 
(e.g.

share HTML contents)
Do you think you could gather thread dumps (e.g. jstack 
) while

clicking the "view results" tab?

Vladimir


OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Slow "view results in tree" in 5.5 with Java11 (was [VOTE] Release JMeter 5.5 RC1)

[Felix Schumacher]

This slowness happens on Windows 10 with Java 11 and OpenJDK 8 (282), 
whenever I switch from an "empty" sample to a "biggish" sample. 
Switching from a "biggish" sample to another "biggish" sample has no 
real performance impact (below 1 second, I would say).


Will try with Linux later.

Felix

Am 14.03.2022 14:51, schrieb Felix Schumacher:

I think I can reproduce it. I sampled a biggish page. It recorded
three sub samples. Two redirects and the actual page.
Clicking on the main sample takes one or two seconds. Changing to the
redirect is fast, but changing back to the main sample or the sub
sample with the page is incredibly slow.

Gui is not responding, as the awt thread is calculating the preferred
view size and is almost all the time in
sun.font.SunLayoutEngine.shape.

Felix

Am 14. März 2022 13:40:46 MEZ schrieb Vladimir Sitnikov
:

When i clique to display the resultat data (html boy) the JMeter is
very slow to show the page.
I need to wait 4 sec to 8 sec between click and the http sampler and
the display in text format.


Vincent, do you think you could create a reproducer for the issue? 
(e.g.

share HTML contents)
Do you think you could gather thread dumps (e.g. jstack ) 
while

clicking the "view results" tab?

Vladimir

Re: Slow "view results in tree" in 5.5 with Java11 (was [VOTE] Release JMeter 5.5 RC1)

[Felix Schumacher]

Am 14.03.2022 14:51, schrieb Felix Schumacher:

I think I can reproduce it. I sampled a biggish page. It recorded
three sub samples. Two redirects and the actual page.
Clicking on the main sample takes one or two seconds. Changing to the
redirect is fast, but changing back to the main sample or the sub
sample with the page is incredibly slow.

Gui is not responding, as the awt thread is calculating the preferred
view size and is almost all the time in
sun.font.SunLayoutEngine.shape.


Stacktrace is:

"AWT-EventQueue-0" #19 prio=6 os_prio=0 cpu=1196937.50ms 
elapsed=1688.37s tid=0x0207187f4800 nid=0x344c runnable  
[0x00b8f4efa000]

   java.lang.Thread.State: RUNNABLE
at sun.font.SunLayoutEngine.shape(java.desktop@11/Native Method)
	at 
sun.font.SunLayoutEngine.layout(java.desktop@11/SunLayoutEngine.java:176)
	at 
sun.font.GlyphLayout$EngineRecord.layout(java.desktop@11/GlyphLayout.java:687)

at sun.font.GlyphLayout.layout(java.desktop@11/GlyphLayout.java:468)
	at 
sun.font.ExtendedTextSourceLabel.createGV(java.desktop@11/ExtendedTextSourceLabel.java:329)
	at 
sun.font.ExtendedTextSourceLabel.getGV(java.desktop@11/ExtendedTextSourceLabel.java:315)
	at 
sun.font.ExtendedTextSourceLabel.createLogicalBounds(java.desktop@11/ExtendedTextSourceLabel.java:225)
	at 
sun.font.ExtendedTextSourceLabel.getAdvance(java.desktop@11/ExtendedTextSourceLabel.java:134)

at java.awt.font.TextLine.init(java.desktop@11/TextLine.java:281)
at java.awt.font.TextLine.(java.desktop@11/TextLine.java:129)
	at 
java.awt.font.TextLine.fastCreateTextLine(java.desktop@11/TextLine.java:978)
	at 
java.awt.font.TextLayout.fastInit(java.desktop@11/TextLayout.java:611)

at java.awt.font.TextLayout.(java.desktop@11/TextLayout.java:392)
at java.awt.Font.getStringBounds(java.desktop@11/Font.java:2612)
	at 
sun.swing.SwingUtilities2.getFontCharsWidth(java.desktop@11/SwingUtilities2.java:946)
	at 
sun.swing.SwingUtilities2.getFontCharWidth(java.desktop@11/SwingUtilities2.java:934)
	at 
javax.swing.text.Utilities.getTabbedTextOffset(java.desktop@11/Utilities.java:529)
	at 
javax.swing.text.Utilities.getTabbedTextOffset(java.desktop@11/Utilities.java:458)
	at 
javax.swing.text.WrappedPlainView.calculateBreakPosition(java.desktop@11/WrappedPlainView.java:366)
	at 
javax.swing.text.WrappedPlainView$WrappedLine.breakLines(java.desktop@11/WrappedPlainView.java:920)
	at 
javax.swing.text.WrappedPlainView$WrappedLine.getPreferredSpan(java.desktop@11/WrappedPlainView.java:692)

at javax.swing.text.View.getMaximumSpan(java.desktop@11/View.java:267)
	at 
javax.swing.text.BoxView.calculateMajorAxisRequirements(java.desktop@11/BoxView.java:874)
	at 
javax.swing.text.BoxView.checkRequests(java.desktop@11/BoxView.java:931)
	at 
javax.swing.text.BoxView.setSpanOnAxis(java.desktop@11/BoxView.java:330)

at javax.swing.text.BoxView.layout(java.desktop@11/BoxView.java:710)
at javax.swing.text.BoxView.setSize(java.desktop@11/BoxView.java:398)
	at 
javax.swing.text.WrappedPlainView.setSize(java.desktop@11/WrappedPlainView.java:519)
	at 
javax.swing.plaf.basic.BasicTextUI$RootView.setSize(java.desktop@11/BasicTextUI.java:1821)
	at 
javax.swing.plaf.basic.BasicTextUI.getPreferredSize(java.desktop@11/BasicTextUI.java:948)
	at 
com.github.weisj.darklaf.ui.text.DarkTextUI.getPreferredSize(DarkTextUI.java:223)
	at 
javax.swing.JComponent.getPreferredSize(java.desktop@11/JComponent.java:1680)
	at 
javax.swing.JEditorPane.getPreferredSize(java.desktop@11/JEditorPane.java:1345)
	at 
javax.swing.JViewport.getViewSize(java.desktop@11/JViewport.java:1119)
	at 
javax.swing.plaf.basic.BasicScrollPaneUI.syncScrollPaneWithViewport(java.desktop@11/BasicScrollPaneUI.java:330)
	at 
javax.swing.plaf.basic.BasicScrollPaneUI$Handler.stateChanged(java.desktop@11/BasicScrollPaneUI.java:1126)
	at 
javax.swing.JViewport.fireStateChanged(java.desktop@11/JViewport.java:1490)

at javax.swing.JViewport.setView(java.desktop@11/JViewport.java:1089)
	at 
javax.swing.JScrollPane.setViewportView(java.desktop@11/JScrollPane.java:980)
	at 
org.apache.jmeter.visualizers.RenderAsText.showTextResponse(RenderAsText.java:36)
	at 
org.apache.jmeter.visualizers.RenderAsText.renderResult(RenderAsText.java:29)
	at 
org.apache.jmeter.visualizers.ViewResultsFullVisualizer.valueChanged(ViewResultsFullVisualizer.java:400)
	at 
org.apache.jmeter.visualizers.ViewResultsFullVisualizer.valueChanged(ViewResultsFullVisualizer.java:373)

at javax.swing.JTree.fireValueChanged(java.desktop@11/JTree.java:2967)
	at 
javax.swing.JTree$TreeSelectionRedirector.valueChanged(java.desktop@11/JTree.java:3456)
	at 
javax.swing.tree.DefaultTreeSelectionModel.fireValueChanged(java.desktop@11/DefaultTreeSelectionModel.java:641)
	at 
javax.swing.tree.DefaultTreeSelectionModel.notifyPathChange(java.desktop@11/DefaultTreeSelectionModel.java:)
	at 
javax.swing.tree.DefaultTreeSelectionModel.setSelectionPaths(java.

Re: Slow "view results in tree" in 5.5 with Java11 (was [VOTE] Release JMeter 5.5 RC1)

[Felix Schumacher]

I think I can reproduce it. I sampled a biggish page. It recorded three sub 
samples. Two redirects and the actual page.
Clicking on the main sample takes one or two seconds. Changing to the redirect 
is fast, but changing back to the main sample or the sub sample with the page 
is incredibly slow.

Gui is not responding, as the awt thread is calculating the preferred view size 
and is almost all the time in sun.font.SunLayoutEngine.shape.

Felix 

Am 14. März 2022 13:40:46 MEZ schrieb Vladimir Sitnikov 
:
>>When i clique to display the resultat data (html boy) the JMeter is
>>very slow to show the page.
>>I need to wait 4 sec to 8 sec between click and the http sampler and
>>the display in text format.
>
>Vincent, do you think you could create a reproducer for the issue? (e.g.
>share HTML contents)
>Do you think you could gather thread dumps (e.g. jstack ) while
>clicking the "view results" tab?
>
>Vladimir

Re: Adding a button to the Toolbar

[Felix Schumacher]

Am 13.03.22 um 10:14 schrieb Milamber:



On 13/03/2022 03:11, NaveenKumar wrote:
I was able to add the validate thread group action to the toolbar 
using the below properties in icons-toolbar.properties file.


But it is not picking up the custom icon from the `bin` directory. If 
I give the path as 
`org/apache/jmeter/images/toolbar//document-new-4.png` it is 
displaying the icon and validate is working fine.


Is there a way to map the custom icon? Any inputs, please?



You need to put the icon files (3 sizes) in this directory:
./src/core/src/main/resources/org/apache/jmeter/images/toolbar/(22x22 
32x32  48x48)/


After, build JMeter. You can find your new icons into 
/lib/ext/ApacheJMeter_core.jar


If I read the code at JMeterToolBar#getIconsMappings() right, you can 
add custom images for the buttons by providing your own properties file 
(look at icons-toolbar.properties for the format) and let the JMeter 
property jmeter.toolbar.icons point to it.


But even if it is working (haven't tested it), it feels cumbersome for 
third party plugin developers. If this is really the only way to extend 
the toolbar icons, it would make a good enhancement, don't you think?


And it seems, that you can use SVGs instead of PNGs, too.

Felix






toolbar=new,templates,open,save,|,undo,redo,cut,copy,paste,|,expand,collapse,toggle,|,test_start,test_start_notimers,test_stop,test_shutdown,validate_tg,|,test_clear,test_clear_all,|,search,search_reset,|,function_helper,help 




validate_tg=validate,VALIDATE_TG,validate.png


Thank you

On 3/12/2022 12:15:20 PM, NaveenKumar  
wrote:

Hi Team,

I am new to the JMeter core/plugin development ecosystem. I am trying 
to add a button to the toolbar.


Here is my repo 
[https://github.com/QAInsights/validate-thread-group]. But it is not 
displaying any option either in the menu or in the toolbar.


Could someone guide me, please?

Thank you!




OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Release JMeter 5.5 RC1

[Felix Schumacher]

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




OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Monthly Community Meetup

[Felix Schumacher]

Am 08.03.22 um 02:32 schrieb NaveenKumar:

Thanks, Felix and Ralf for your input.

Hi Felix,

I agree with your points. Could we just start a pilot meetup and see how it 
goes? I am positive that people will participate.

I think, we can, but I have no idea, how :)


Those who do not have the advantage to participate, can watch the recording and 
refer to the meeting notes.

The community meetings will bring more transparency and help to shape the 
future roadmap of JMeter.


As long, as we remember, that we can not 'decide' anything on those 
meetings, as that would have to be discussed and decided on the mailing 
list.


Felix



Thank you,
NaveenKumar
On 3/7/2022 2:24:08 PM, Ralf Roeber  wrote:
Hi Felix and Naveen,

This is a beautiful idea to create some user experience meetups around
jMeter. This is a really cool idea.

We as "Powerusers" don't need that.

But ... I would be happy to assist in setting up and supporting such a
thing for "new" users.

I wonder 樂 why this idea  is not mine? This could be something really
cool.

Cheers
Ralf

---
 sent from mobile ... excuse my brevity.

El lun., 7 mar. 2022 18:30, Felix Schumacher <
felix.schumac...@internetallee.de> escribió:


Hi Naveen,

I now of no such monthly meetup and while being a nice addition, meetups
tend to have a few draw backs, that we should be aware of

* time constraint (we all live (potentially) in different time zones, so
finding a good time might be hard

* language barriers (not all (most?) of us are not native speakers and
might find it hard to express/understand our thoughts in a live/spoken
situation)

* maybe not everyone interested can talk/hear

* high bandwidth (not everyone might have the luxury of a decent enough
internet connection for an online meetup)

That means, that all decisions/(crucial information that lead to a
decision) on the development of JMeter have to take place on the mailing
list.

But apart from that, it might be a nice format to learn more about the
usage of JMeter or the needs of our users.

Felix
Am 06.03.22 um 20:46 schrieb NaveenKumar:

Hi Team,

Do we have any monthly community meetup which is public and recorded? If not, 
could we create a practice to meet, discuss the features, enhancements and more?

Please share your thoughts.

Thank you,




OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Let's release JMeter 5.5 ?

[Felix Schumacher]

Am 09.03.22 um 16:24 schrieb OUFDOU Anas:

+1

Hello,

Where we can find a preview  release note? or it's not started yet?


It is not yet started, but you can render the page for yourself :)

$ ./gradlew previewSite

and then open ./src/dist/build/site/changes.html

Felix


Best regards

Anas

On Wed, Mar 9, 2022 at 2:45 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:



Am 9. März 2022 14:42:46 MEZ schrieb Vladimir Sitnikov <
sitnikov.vladi...@gmail.com>:

I think we should mergehttps://github.com/apache/jmeter/pull/696  before

we

release.

OK, can do that.


I am wondering, if the new notice I placed at the end of the Readme would

be better placed in the notice file

NOTICE is highly sensitive to "legal stuff", so I would refrain from
modifying NOTICE unless there's an explicit need to do that.
In the long-term, it would be great if we could replace the dependency

with

something less legal-confusing :)

OK, so we will keep it in Readme.

Felix

Vladimir




OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Let's release JMeter 5.5 ?

[Felix Schumacher]

Am 09.03.22 um 14:45 schrieb Felix Schumacher:


Am 9. März 2022 14:42:46 MEZ schrieb Vladimir 
Sitnikov:

I think we should mergehttps://github.com/apache/jmeter/pull/696  before we
release.

OK, can do that.


Done

Felix



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Let's release JMeter 5.5 ?

[Felix Schumacher]

Am 9. März 2022 14:42:46 MEZ schrieb Vladimir Sitnikov 
:
>I think we should merge https://github.com/apache/jmeter/pull/696 before we
>release.

OK, can do that. 

>
>>I am wondering, if the new notice I placed at the end of the Readme would
>be better placed in the notice file
>
>NOTICE is highly sensitive to "legal stuff", so I would refrain from
>modifying NOTICE unless there's an explicit need to do that.
>In the long-term, it would be great if we could replace the dependency with
>something less legal-confusing :)

OK, so we will keep it in Readme. 

Felix 
>
>Vladimir

Re: Let's release JMeter 5.5 ?

[Felix Schumacher]

I would be more than OK with that.

I am wondering, if the new notice I placed at the end of the Readme would be 
better placed in the notice file. But either way, I am fine.

Felix 

Am 9. März 2022 13:24:29 MEZ schrieb Milamber :
>Hi,
>
>If you are OK, I can start a release process now.
>
>Milamber
>
>On 05/03/2022 17:57, NaveenKumar wrote:
>> +1 for 5.5
>> On 3/5/2022 11:54:57 AM, Philippe Mouawad  
>> wrote:
>> 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
>>
>> [41509c74-ffe9-4cff-b3e3-bfc4830f7b03]
>

Re: Monthly Community Meetup

[Felix Schumacher]

Hi Naveen,

I now of no such monthly meetup and while being a nice addition, meetups 
tend to have a few draw backs, that we should be aware of


 * time constraint (we all live (potentially) in different time zones, 
so finding a good time might be hard


 * language barriers (not all (most?) of us are not native speakers and 
might find it hard to express/understand our thoughts in a live/spoken 
situation)


 * maybe not everyone interested can talk/hear

 * high bandwidth (not everyone might have the luxury of a decent 
enough internet connection for an online meetup)


That means, that all decisions/(crucial information that lead to a 
decision) on the development of JMeter have to take place on the mailing 
list.


But apart from that, it might be a nice format to learn more about the 
usage of JMeter or the needs of our users.


Felix

Am 06.03.22 um 20:46 schrieb NaveenKumar:

Hi Team,

Do we have any monthly community meetup which is public and recorded? If not, 
could we create a practice to meet, discuss the features, enhancements and more?

Please share your thoughts.

Thank you,


OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Let's release JMeter 5.5 ?

[Felix Schumacher]

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



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Unclear licenses for dependent libraries currently used

[Felix Schumacher]

Am 05.03.22 um 12:40 schrieb Vladimir Sitnikov:

Ok, where do you think would be a good place? changes.xml? NOTICE? README?

README sounds good.


Added a notice to README.md

I wonder, if we would have had to include such a notice for xpp3, too. 
According to https://x-stream.github.io/download.html mxparser is a fork 
of xpp3.


Felix



Vladimir



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Unclear licenses for dependent libraries currently used

[Felix Schumacher]

Am 05.03.22 um 12:28 schrieb Vladimir Sitnikov:

CC0 (http://creativecommons.org/publicdomain/zero/1.0/)

CC0 should be allowed. It looks like a bug in the license-gather plugin if
it marks CC0 as unknown.


Indiana University Extreme! Lab Software License

They have #3 which requires an explicit mention in the documentation
or in the "third-party acknowledgments" screen:

  "This product includes software developed by the Indiana
  University Extreme! Lab.  For further information please visit
  http://www.extreme.indiana.edu/;


I think we miss that.


Ok, where do you think would be a good place? changes.xml? NOTICE? README?

Felix



Vladimir



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Unclear licenses for dependent libraries currently used

[Felix Schumacher]

Hi all,

builiding JMeter currently produces the warning below:

"""

> Task :src:licenses:renderLicenseForBinary
Dependencies of license category UNKNOWN are not allowed for BINARY 
artifacts
= 



CC0 (http://creativecommons.org/publicdomain/zero/1.0/)
* org.reactivestreams:reactive-streams:1.0.3

Indiana University Extreme! Lab Software License 
(https://raw.githubusercontent.com/x-stream/mxparser/master/LICENSE.txt)

* io.github.x-stream:mxparser:1.2.2
"""

The reactive-streams comes through the neo4j library and is OK (I 
believe), as we are not distributing it in the sources and are 
attributing it in our generated list of licenses/products.


The mxparser comes with xstream (it was always included in xstream, but 
with last release got attributed by them, while resurrecting the 
sources). I think the license is OK, as we are attributing Indiana 
University in our generated list of licenses/products and are not 
modifying and only place it in the convenience builds.


What do you think?

Felix



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Question on testing properties in JMeter

[Felix Schumacher]

Am 01.03.22 um 12:03 schrieb Vladimir Sitnikov:

When I run ./gradlew test -Djmeter.use_java_regex=true, it seems to have
more effect

I have no idea how it works now, however, there are three JVMs:
1) The first JVM evaluates the build script (it basically runs
build.gradle.kts, and it is the JVM that parses the build command-line)
2) The second JVM runs @Test classes
3) Then a test class might fork another JVM with JMeter


Or would I have to add a
passProperty("jmeter.use_java_regex"|"jmeter.regex_engine" ) call?

passProperty is needed to pass properties (sorry for duplication) between
#1 and #2 above.
If @Test class forks a JVM for JMeter, then it should somehow pass
properties on its own.

Of course, we can follow the "defer to System.properties by default"
approach, and we could ensure
all JVM forks pass jmeter.regex_engine (e.g. all jmeter.* properties) to
the forked JVMs via their system.properties.
I am afraid it would create tight coupling on System.properties, thus it
would make it harder to
launch JMeter instances in "isolation" within a single JVM.

On the other hand, if we prefer that System.properties contain no
JMeter-specific properties,
then we might end up with a better design, where all the properties could
be passed explicitly (via the constructor or whatever),
and it would make it easier to test: test parallelism is easier to manage
when tests do not require mutating the global state like System.properties.

So I am inclined we should favor designs where all the properties are
passed explicitly (e.g. via mask),
instead of "all properties occurring in System.properties automagically".


I have implemented a passing of system properties that match those with 
"jmeter.properties." as prefix in PR 700.


With that I can provide a system property named "jmeter.use_java_regex" 
to the unit tests run by gradle with


./gradlew test -Djmeter.properties.jmeter.use_java_regex=true

I believe, that is what you tried to explain to me.

Felix



WDYT?

Vladimir



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Question on testing properties in JMeter

[Felix Schumacher]

Am 28.02.22 um 19:15 schrieb Felix Schumacher:


Am 28.02.22 um 17:20 schrieb Vladimir Sitnikov:

We need to add a convention so launching Gradle with a property
`jmeter.property.key=value` would pass
`key=value` JMeter property (it should remove jmeter.property. 
prefix, and

the prefix is there to avoid ambiguity)
The relevant bits are here:
https://github.com/apache/jmeter/blob/1d573158f2af7be882674e59c02490836abd0cde/build.gradle.kts#L599-L606 


The command would be like ./gradlew test
-Pjmeter.property.jmeter.regex_engine=oro


JMeterProperties default to SystemProperties. So currently I could 
start the test with -Djmeter.use_java_regex=true, right?


When I run ./gradlew test -Djmeter.use_java_regex=true, it seems to have 
more effect, than to add the property to bin/system.property. Now more 
tests fail and I will look into those.


Felix



Or would I have to add a 
passProperty("jmeter.use_java_regex"|"jmeter.regex_engine" ) call?


The code in lines 599-606 seem to be able to set those, but how would 
I pass it as a JMeterProperty (so it could potentially overwrite a 
system property)? I have to admit, that I am really not a Gradle expert.




Then the engine variation could be added into the CI matrix builder:
https://github.com/apache/jmeter/pull/693
Of course, it does not answer what should we do with test coverage, 
however:

a) We could ensure CI always has both variations, and we could merge the
coverage (Codecov supports it)
b) It might make sense to create a targeted parameterized test (e.g. 
a test

that parameterizes with regex_engine).
I think we should not invest much time in building a specialized 
test. If

there's a test that can easily be converted to a parameterized,
then it is fine. If adding such a test is time-consuming, I would 
just go

with a command-line property and the CI randomizer.


My original thought was to go by the route of parameterized tests, as 
they are something I have done before and know how to do :)


I will try to add a passProperty() call with the new property and add 
another build step to the CI system(s), even if it does a lot of work 
twice. That way, the tests will at least run with both settings.


Felix



Vladimir



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Question on testing properties in JMeter

[Felix Schumacher]

Am 28.02.22 um 17:20 schrieb Vladimir Sitnikov:

We need to add a convention so launching Gradle with a property
`jmeter.property.key=value` would pass
`key=value` JMeter property (it should remove jmeter.property. prefix, and
the prefix is there to avoid ambiguity)
The relevant bits are here:
https://github.com/apache/jmeter/blob/1d573158f2af7be882674e59c02490836abd0cde/build.gradle.kts#L599-L606
The command would be like ./gradlew test
-Pjmeter.property.jmeter.regex_engine=oro


JMeterProperties default to SystemProperties. So currently I could start 
the test with -Djmeter.use_java_regex=true, right?


Or would I have to add a 
passProperty("jmeter.use_java_regex"|"jmeter.regex_engine" ) call?


The code in lines 599-606 seem to be able to set those, but how would I 
pass it as a JMeterProperty (so it could potentially overwrite a system 
property)? I have to admit, that I am really not a Gradle expert.




Then the engine variation could be added into the CI matrix builder:
https://github.com/apache/jmeter/pull/693
Of course, it does not answer what should we do with test coverage, however:
a) We could ensure CI always has both variations, and we could merge the
coverage (Codecov supports it)
b) It might make sense to create a targeted parameterized test (e.g. a test
that parameterizes with regex_engine).
I think we should not invest much time in building a specialized test. If
there's a test that can easily be converted to a parameterized,
then it is fine. If adding such a test is time-consuming, I would just go
with a command-line property and the CI randomizer.


My original thought was to go by the route of parameterized tests, as 
they are something I have done before and know how to do :)


I will try to add a passProperty() call with the new property and add 
another build step to the CI system(s), even if it does a lot of work 
twice. That way, the tests will at least run with both settings.


Felix



Vladimir



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Question on testing properties in JMeter

[Felix Schumacher]

Hi All,

with https://github.com/apache/jmeter/pull/700 we will introduce a new 
property, that lets us choose whether JMeter uses Oro or Java based 
regexes. Currently the Oro path should be handled by our test cases and 
I would like to extend it to the Java based one. For testing I set the 
property in bin/system.properties and let Gradle run the tests, but that 
is not optimal, as it tests places twice, that are not related to the 
change and will probably not be handled correctly by our coverage reports.


Some of the changed classes need (well, are implemented using) static 
variables to implement the feature flag. Setting those (private 
static/private) fields via reflection can be done, but is probably not 
the best style. I could put the feature flag into another class and give 
it a interface, so that the behaviour could be switched at runtime (test 
runtime that is), or add helper methods on the changed classes, that are 
only useful for the unit tests.


Currently I think that it would be best to add a new class which would 
be specific to this feature flag (regex mode) and would be added into 
core or jorphan. (I would transfer the regex pattern cache from 
JMeterUtils into such a class, too)


What do you think?

Felix



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Extending JMeter

[Felix Schumacher]

Are you looking for 
https://docs.oracle.com/javase/tutorial/uiswing/events/propertychangelistener.html 
?


Maybe you could describe in more detail, what you have already tried and 
where you want to listen for changed values?


Felix

Am 22.02.22 um 09:32 schrieb 张天赐:

When i use https://jmeter.apache.org/usermanual/jmeter_tutorial.html#testbean 
to extending JMeter. I want listen field value change. How can i do?


OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Let's release JMeter 5.5 ?

[Felix Schumacher]

Am 21.02.22 um 11:17 schrieb Philippe Mouawad:

Hello,

What do you think of releasing version 5.5 ?


I think it would be a good idea :)

 Felix



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


Regards
Philippe M.



OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Trouble upload file with special characters (french accents) in the multi part

[Felix Schumacher]

I think you stumbled upon 
https://bz.apache.org/bugzilla/show_bug.cgi?id=61669


I believe, the filename could be added in correct spelling in the 
parameter named filename* encoded something like 
utf8''classif_r%c3%a9r%c3%a9fence.csv as shown in 
https://www.ietf.org/rfc/rfc6266.txt (Chapter 5. Examples).


It would help, if you could take a look at some modern browsers and 
report back, if and how they encode the filenames.


Felix

Am 15.02.22 um 12:27 schrieb Vincent Daburon:

Hi,
I can't upload file with a file name contains special characters on
Windows 10 and keep the file name in the multi-part filename

I use the java client implementation or the HttpClient4.

For example :
File path and file name :
C:/data/multi_part_upload_files/classif_référence.csv

For the demonstration, i use the "HTTP Mirror Server"
It is a POST
Path : /upload
hostname : localhost
port : 8081
Content Encoding :  UTF-8

1 parameter :
Name : param1
Value : value1

File upload :
File Path : C:/data/multi_part_upload_files/classif_référence.csv
Parameter name : file_0
Mime type : tex/plain

Client implementation Java (but the same behaviour with httpClient4)

Post request:
=
POST http://localhost:8081/upload

POST data:
-7d159c1302d0y0
Content-Disposition: form-data; name="param1"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

value1
-7d159c1302d0y0
Content-Disposition: form-data; name="file_0"; filename="classif_r?f?rence.csv"
Content-Type: tex/plain
Content-Transfer-Encoding: binary


-7d159c1302d0y0--

=
The name is now : filename="classif_r?f?rence.csv
and not : classif_référence.csv

In the java client implementation
In the PostWriter
  public static final String ENCODING = StandardCharsets.ISO_8859_1.name();

but i put some trace and i see that encoding will be cp1252 (windows)

So there is confusion between sampler encoding set to UTF-8 in the
sampler GUI, the default charset set to cp1252 for Windows for file
encoding and the initial ENCODING set to
StandardCharsets.ISO_8859_1.name() for the defaut http sampler
encoding.

For me in the Java client implementation the charset must be the UTF-8
set manually in sampler GUI or the sampleresult.default.encoding=UTF-8
properties.

Some think like in the PostWriter  :
public static final String DEFAULT_HTTP_ENCODING =
StandardCharsets.ISO_8859_1.name();

 protected static final String DEFAULT_ENCODING =
JMeterUtils.getPropDefault("sampleresult.default.encoding",
DEFAULT_HTTP_ENCODING);
 private static final String ENCODING = DEFAULT_ENCODING;
 System.out.println("PostWriter ENCODING=" + ENCODING)

Regards.
Vincent DAB.


OpenPGP_0xEA6C3728EA91C4AF.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: JMeter 5.5 release

[Felix Schumacher]

I would like to see the pr for graphql incorporated before a 5.5 release. I 
don't think there are any showstoppers in there, do you? 

Felix 

Am 21. Dezember 2021 16:33:25 MEZ schrieb Vladimir Sitnikov 
:
>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

Re: [VOTE] Release JMeter 5.4.2 RC1

[Felix Schumacher]

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:
>
> 5eaf0ad4ef8941080c0cf1d7fb732c6d14e3d16ac900885b912a62bea24210adcc9c9a09cb0f028f0253e3f6f785800aec2f3dda92121d0259dcda09223a0de1
>
> *apache-jmeter-5.4.2.tgz
> 968e2b8c6b8ea393ae83d021c67adf36657a561b37e577ca499bc73becc3a4fd49989069d94fdc2d26f23fd223b3c769426a39d5a928502f16f3a2889955bbdc
>
> *apache-jmeter-5.4.2.zip
> 98c75f3151990d94951dc46051d8382a60766455344528ea021638913ee9731a60534ba53167723255aa03e41f6621f5be4a2eb36692b42642dc8e406bf2bb4b
>
> *apache-jmeter-5.4.2_src.tgz
> 8443ee884e06d121201aaeb47e623da5a5f4a3054cf030c3cce454d700dc13cc676f3d3e44279afd1463f40382551ad42e8faae1388f6617f543a354282bab08
>
> *apache-jmeter-5.4.2_src.zip
>
>
>
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: JMeter versions and release dates

[Felix Schumacher]

A 5.4.2 would be great.

A 5.5 could be harder, as there are usually some smaller things, that pop up.

Felix 

Am 15. Dezember 2021 09:06:39 MEZ schrieb Milamber :
>Hi,
>
>5.5 is ready to release or need some commits?
>
>I will prepare 5.4.2 (just fix Log4J)
>
>Milamber
>
>On 15/12/2021 09:04, Philippe Mouawad wrote:
>> 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
>>>>>
>>>
>

Re: JMeter versions and release dates

[Felix Schumacher]

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
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: JMeter versions and release dates

[Felix Schumacher]

I would be fine with both versions 5.5 and 6.0.

For a 5.5 would speak two things.

* Adding features can be done with a minor version update (so a 6.0 is
not necessarily needed)

* and more important a major version could be a good point to drop old
stuff (mongodb sampler, which can't be used for modern mongodb servers,
ftp sampler?, fill in your wishes, ...)

But on the other hand a version is still a number, only.

As asked on another thread, the more urging question would be, when and
what do we want to release next ;)

Felix

Am 03.12.21 um 10:54 schrieb Vladimir Sitnikov:
> 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
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: [Jmeter] Enhancement , Disable component using attributes

[Felix Schumacher]

Am 25.11.21 um 21:44 schrieb Vladimir Sitnikov:
> By the way, in order to make enabled/disabled state dynamic, TreeCloner
> should
> automatically convert "enabled expressions" into
> IfController(condition="enabled expression") { originalComponent(...) }
>
> Then we won't need to touch executor logic, and we would get automatic
> support for all the plugins.
> WDYT?

I have no idea, how TreeCloner works, so maybe a good idea (maybe not
:)). Are we doing such stuff already?

Felix

>
> 
>
>> How would you trigger those modes? Another checkbox?
> It could be a checkbox in the menu.
> Here's one of the discussions on that:
> https://lists.apache.org/thread/lzdoljpwr9kzm4kqns9cyz1v45ppo19d
>
>> I think it is important to have the two boolean states plus a third form
>> to be able to convert older checkboxes to such a new ui element without
>> breaking the old save format.
> If checkbox + edit is UI only feature, then
> "boolProp" => boolean value
> string "true" => true
> string "false" => false
> else => treat as expression (third state)
>
> So far it looks ok. We should be able to read old files, and as we save we
> could save it as "stringProp" always.
>
> Vladimir
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: [Jmeter] Code compilation

[Felix Schumacher]

Am 26.11.21 um 08:12 schrieb OUFDOU Anas:
> Thanks,
>
> I don't have a firewall on my machine, what is the destination IP address?

localhost

It starts a local ftp server on port  (or at least tries to)

Felix

>
> On Thu, Nov 25, 2021 at 5:36 PM Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
>> I have never seen an error in this part of our test suite. Do you have a
>> firewall, that filters ftp access, or any other server that is already
>> listening on port ?
>>
>> You can safely ignore the error for now and disable the corresponding test
>>
>>  ./gradlew -x :src:dist-check:batchFTP_TESTS test
>>
>> Felix
>> Am 25.11.21 um 07:22 schrieb OUFDOU Anas:
>>
>> Hello,
>>
>> Error log is in attachment.
>>
>> thanks for your help
>>
>>
>> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H50d8ClumV2nhDP05sOfY78Eyi2C71h7kfUBQfP4BQjrCZCtvfjIH0__06sMX98JTpw==>
>>
>>
>> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H5_O9YaWlk4nBKUHhaZ1phej_QXSutzSvDX6YXlPu8rPc>
>>
>>
>> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H50ufVx8dW6gZtUFvZ1gMVIvbJOeuljB2LWaLJI8NlhGlKD921mmu9UHBGPvb6ZuPGw==>
>>
>>
>> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H5-jpVnIV_are3Z-m5blBfs6qRL1kX_L0DRlcirdCgINiQ_Y62P6vso5Oi8QshaN52w==>
>>
>>
>> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H50d8ClumV2nhDP05sOfY78Eyi2C71h7kfUBQfP4BQjrC71_qMKBe73RCHKRjGeDsE68U-TmlvnN27_c7uQRHayw=>
>>
>> Anas Oufdou
>>
>> Technical expert
>>
>> aouf...@sqli.com
>> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H57Cwsks_wvHOp7OaK36PwiZ1WXD24t4ovd5t4eGFMTS5>
>>
>> T.
>>
>> M. 070 31 96 40
>>
>> www.sqli.com
>> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H57vyBkJAMjiVOosPWFU_7Z4=>
>> - www.sqli-carrieres.com
>> <https://cloud.letsignit.com/collect/bc/60019ff35acb71000a109fcc?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H5z4siItpRerryTmLr0LvuqjHGeDYPIxxNs1sMlZTnBbArxT5OaW-c3bv9zu5BEdrLA==>
>>
>>
>>
>> <https://cloud.letsignit.com/collect/b/6148b0e305b7e6c73bb28748?p=QoDw98WtVPFQnVpBof9hD3eHAKdbCrcDexhDKhehSTRuOfJQWfXJGenv4iLtpqwku7jF9geEZtqJwUXC1m2H50d8ClumV2nhDP05sOfY78Eyi2C71h7kfUBQfP4BQjrC71_qMKBe73RCHKRjGeDsE68U-TmlvnN27_c7uQRHayw=>
>>
>>
>> On Thu, Nov 25, 2021 at 7:06 AM Vladimir Sitnikov <
>> sitnikov.vladi...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> Please prefer sending error messages as text (e.g. copy-paste from
>>> terminal), as it makes the errors searchable.
>>> For instance, https://lists.apache.org/list.html?dev@jmeter.apache.org is
>>> not able to search for text in images.
>>>
>>> What you see are flaky tests.
>>> There are tests that use real-life servers in order to verify JMeter's
>>> ability to work with modern systems.
>>> In other words, some of the tests attempt to access apache.org to verify
>>> if
>>> HTTP sampler is still able to talk
>>> to the modern HTTPS, and so on.
>>>
>>> It turns out, the responses are not 100% reliable, and sometimes DNS fails
>>> to resolve the host, sometimes
>>> the server responds with a slightly different error and so on.
>>>
>>> I have seen the errors you mention, and the errors are transient. They
>>> appear and disappear at random.
>>> If you like, you can analyze the nature of the failure and try to make the
>>> tests more reliable,
>>> however, the key nature of the tests is they use true systems that have
>>> inherent failures.
>>>
>>> In other words, we could rework the tests to use Docker-based HTTP
>>> servers,
>>> however, that would kill
>>> the idea. Then we would keep testing JMeter with a canned version of some
>>> HTTP server, and we would
>>> never know the sampler no longer works with the modern web.
>>>
>>> Vladimir
>>>



OpenPGP_signature
Description: OpenPGP digital signature

Re: [Jmeter] Code compilation

[Felix Schumacher]

Am 26.11.21 um 09:51 schrieb Vladimir Sitnikov:
> Anas,
>
> Here's the failure message:
>
>> Failures detected while testing
> /mnt/Linux2T/work/anasoid/repo/jmeter/bin/testfiles/FTP_TESTS.jmx
>
> Could you please try opening the test file in JMeter and see what that
> script is doing?
> In theory, you should be able to reproduce the failure when running the
> same script from GUI.
>
> We have not touched the script for 3+years, so I think nobody remembers the
> details.

I certainly don't remember the details (I am sure, I have never looked
at it before :)),
but I tried it locally.

It does start a local ftp server on port  and tries to talk to it
with the ftp sampler.

That is, why I asked, if there was a firewall blocking ftp or something
already listens on port  (a ssh server maybe).

If you want to try it without gradle, then you have to make sure, that
the libraries lib/opt/ftp* and lib/opt/mina* are in the
classpath for JMeter. (You might want to copy them to lib/ and delete
them again after your tests). Another peculiarity of the
jmx file is, that it creates a directory at a specific  place in the
file system and sometimes assumes, that you are in the bin directory
(where that directory has been created).

So to run it:

cp lib/opt/ftp* lib/opt/mina* lib/
cd bin
./jmeter -t testfiles/FTP_TESTS.jmx
cd ..
rm lib/ftp* lib/mina*

Felix

>
> Feel free to submit PRs that make test scripts and error messages easier to
> understand.
>
> Vladimir
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: [Jmeter] Enhancement , Disable component using attributes

[Felix Schumacher]

Am 25.11.21 um 20:14 schrieb Vladimir Sitnikov:
>> The second variant would hide the expression text in the two static cases.
> I thought behind those lines as well. It might be we could add a small
> marker that
> informs the user that checkbox is configurable.
>
> 
>
> I just attended a talk by
> https://www.smashingmagazine.com/author/vitaly-friedman/
> I asked Vitaly for the ideas for this "crazy checkbox" UI element.
>
> As expected, Vitaly was quite puzzled, so unfortunately I got no ideas :)
>
> ---
>
> One more idea would be having "regular" and "expert" modes, where regular
> mode looks like checkbox,
> and in expert mode, all "supercheckboxes" always show their "text fields".
>
> Vitaly said regular/expert modes are a good pattern for UI.
>
> In other words, "the first variant" by Felix could be "expert mode", and
> "the second variant" could be "regular mode".

How would you trigger those modes? Another checkbox?

(I sometimes think, we should try to make all those properties we have
available in a GUI somewhere)

>
> ---
>
> One more option is to show the text field in a popup/tooltip:
> [ ] ▼ enable element
>
> When you click on ▼ (triangle down or whatever), a popup appears that
> overlays extra controls for the checkbox in question.
> As an extra, it could contain extra information like JMeterProperty name,
> option for configuring the field from a command line, etc
>
> It could be a right triangle, so it "folds/unfolds" the text field (and
> "global expert mode" unfolds all the folded fields)

Yes, that would make it more clear, that there are more possibilities to
use the checkbox.

Would the "enable element" text be visible or is it a marker to
higlight, that the triangle would be used to enable the element?

I think it is important to have the two boolean states plus a third form
to be able to convert older checkboxes to such a new ui element without
breaking the old save format.

Felix

>
> Vladimir
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: [Jmeter] Enhancement , Disable component using attributes

[Felix Schumacher]

I think it would be nice to have a general UI component, that is a
tristate checkbox, where the clicking on the checkbox in front would
toggle a possibly hidden text field, where an expression could be placed.

A text representation of the three states might be either

[_] expression

[x] expression

[#] expression

or

[_]

[x]

[#] expression

The states would mean [_] => false, [x] => true, [#] => result of
expression at runtime

The first variant would display the expression text in all cases, but
indicate, that the expression can't be edited and won't be used.

The second variant would hide the expression text in the two static cases.

Felix

Am 25.11.21 um 15:37 schrieb OUFDOU Anas:
> The screen UI will look like this,
>
> image.png
> I prefer using simple text input to not be the preferable way when
> it's a  static value true or false, in this case the enabled from menu
> is preferable as the component will be grayed ..and skip is not to
> used to replace the old enabled case, only to be used when value it's
> dynamic.
>
>
> best Regards
>
>
> 
>
>   
>
> 
>
>   
>
> 
>
>   
>
> 
>
>   
>
> 
>
>   
>
> Anas Oufdou
>
> Technical expert
>
> aouf...@sqli.com
> 
>
> T. 
>
>   
>
> M. 070 31 96 40
>
>
> www.sqli.com
> 
> - www.sqli-carrieres.com
> 
>
>
>
> 
>
>  
>
>
> On Thu, Nov 25, 2021 at 3:00 PM Vladimir Sitnikov
> mailto:sitnikov.vladi...@gmail.com>> wrote:
>
> Frankly speaking, I would start with UI first (mockup or something).
>
> Do you know how the screen would look like?
> Can you share it?
>
> ---
>
> I think that "enabled/disabled" should look like a checkbox so one can
> enable-disable even without a context menu,
> and there should be an option to "convert" the textbox into an
> editable
> field for typing ${...} expressions.
>
> I do not mean full-blown control with autocomplete and things like
> that.
> Just a checkbox-like component with ability to turn it into a editable
> field or something like that.
>
> In other words, there might be a "JConfigurableCheckbox" component
> that can
> be used for "enabled-disabled" control, and for other controls.
> For instance, the combo-box you show for "ignore first line only"
> is too
> verbose for "follow redirects" case.
> Of course, components would have to use this control explicitly,
> however,
> having such control would make JMeter UI more consistent.
>
> Vladimir
>
>
> чт, 25 нояб. 2021 г. в 15:53, OUFDOU Anas  >:
>
> > It's not clear for me what do you mean by generic solution??
> >
> > Can you detail more what you expect to have ?
> >
> > On Thu, Nov 25, 2021 at 12:15 PM Vladimir Sitnikov <
> > sitnikov.vladi...@gmail.com
> > wrote:
> >
> > > >if any boolean or integer who doesn't support using the
> expression , i
> > > think it should be corrected at component level like CSV dataset
> > >
> > > JMeter should 

Re: [Jmeter] Code compilation

[Felix Schumacher]

I have never seen an error in this part of our test suite. Do you have a
firewall, that filters ftp access, or any other server that is already
listening on port ?

You can safely ignore the error for now and disable the corresponding test

 ./gradlew -x :src:dist-check:batchFTP_TESTS test

Felix

Am 25.11.21 um 07:22 schrieb OUFDOU Anas:
> Hello,
>
> Error log is in attachment.
>
> thanks for your help
>
> 
>
>   
>
> 
>
>   
>
> 
>
>   
>
> 
>
>   
>
> 
>
>   
>
> Anas Oufdou
>
> Technical expert
>
> aouf...@sqli.com
> 
>
> T. 
>
>   
>
> M. 070 31 96 40
>
>
> www.sqli.com
> 
> - www.sqli-carrieres.com
> 
>
>
>
> 
>
>  
>
>
> On Thu, Nov 25, 2021 at 7:06 AM Vladimir Sitnikov
> mailto:sitnikov.vladi...@gmail.com>> wrote:
>
> Hello,
>
> Please prefer sending error messages as text (e.g. copy-paste from
> terminal), as it makes the errors searchable.
> For instance,
> https://lists.apache.org/list.html?dev@jmeter.apache.org
>  is
> not able to search for text in images.
>
> What you see are flaky tests.
> There are tests that use real-life servers in order to verify JMeter's
> ability to work with modern systems.
> In other words, some of the tests attempt to access apache.org
>  to verify if
> HTTP sampler is still able to talk
> to the modern HTTPS, and so on.
>
> It turns out, the responses are not 100% reliable, and sometimes
> DNS fails
> to resolve the host, sometimes
> the server responds with a slightly different error and so on.
>
> I have seen the errors you mention, and the errors are transient. They
> appear and disappear at random.
> If you like, you can analyze the nature of the failure and try to
> make the
> tests more reliable,
> however, the key nature of the tests is they use true systems that
> have
> inherent failures.
>
> In other words, we could rework the tests to use Docker-based HTTP
> servers,
> however, that would kill
> the idea. Then we would keep testing JMeter with a canned version
> of some
> HTTP server, and we would
> never know the sampler no longer works with the modern web.
>
> Vladimir
>


OpenPGP_signature
Description: OpenPGP digital signature

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

[Felix Schumacher]

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



OpenPGP_signature
Description: OpenPGP digital signature

Re: Move "precise throughput computation" to thread group

[Felix Schumacher]

I would be OK with addition of Kotlin to the core, when we are certain
(and are on the same side that) JMeter will still be usable with
"normal" Java (that seems to be the case, as I read it)

But it is yet another language added to our growing list of languages
(Java, Groovy, Ant, Gradle, JS, XSLT, XML, Velocity, Markdown, HTML, ...)

Felix

Am 25.11.21 um 10:06 schrieb Vladimir Sitnikov:
> 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
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: DISCUSS: Bugzilla vs JIRA vs GitHub issues

[Felix Schumacher]

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
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: Build failed in Jenkins: JMeter » JMeter-trunk #332

[Felix Schumacher]

I changed the used repo from gitbox.apache.org to the github mirror.

That seems to work fine.

Felix

Am 20.11.21 um 18:30 schrieb Felix Schumacher:
> I have temporarily disabled the scm change trigger on that build, as it
> keeps getting started and fails.
>
> Felix
>
> Am 20.11.21 um 17:31 schrieb Felix Schumacher:
>> Infra says, that jenkins is currently being blocked from accessing
>> gitbox. I think the failed builds will be back to green, once that issue
>> has been solved.
>>
>> Felix
>>
>> Am 20.11.21 um 17:29 schrieb Apache Jenkins Server:
>>> See 
>>> <https://ci-builds.apache.org/job/JMeter/job/JMeter-trunk/332/display/redirect>
>>>
>>> Changes:
>>>
>>>
>>> --
>>> Started by an SCM change
>>> Running as SYSTEM
>>> [EnvInject] - Loading node environment variables.
>>> Building remotely on H29 (ubuntu) in workspace 
>>> <https://ci-builds.apache.org/job/JMeter/job/JMeter-trunk/ws/>
>>> [WS-CLEANUP] Deleting project workspace...
>>> [WS-CLEANUP] Done
>>> The recommended git tool is: NONE
>>> No credentials specified
>>>  > git rev-parse --resolve-git-dir 
>>> <https://ci-builds.apache.org/job/JMeter/job/JMeter-trunk/ws/.git> # 
>>> timeout=10
>>> Fetching changes from the remote Git repository
>>>  > git config remote.origin.url 
>>> https://gitbox.apache.org/repos/asf/jmeter.git # timeout=10
>>> Fetching upstream changes from 
>>> https://gitbox.apache.org/repos/asf/jmeter.git
>>>  > git --version # timeout=10
>>>  > git --version # 'git version 2.17.1'
>>>  > git fetch --tags --progress -- 
>>> https://gitbox.apache.org/repos/asf/jmeter.git 
>>> +refs/heads/*:refs/remotes/origin/* # timeout=10
>>> ERROR: Error fetching remote repo 'origin'
>>> hudson.plugins.git.GitException: Failed to fetch from 
>>> https://gitbox.apache.org/repos/asf/jmeter.git
>>> at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:1000)
>>> at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1241)
>>> at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1301)
>>> at hudson.scm.SCM.checkout(SCM.java:505)
>>> at hudson.model.AbstractProject.checkout(AbstractProject.java:1211)
>>> at 
>>> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:636)
>>> at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
>>> at 
>>> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:508)
>>> at hudson.model.Run.execute(Run.java:1906)
>>> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
>>> at hudson.model.ResourceController.execute(ResourceController.java:97)
>>> at hudson.model.Executor.run(Executor.java:429)
>>> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
>>> --progress -- https://gitbox.apache.org/repos/asf/jmeter.git 
>>> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
>>> stdout: 
>>> stderr: fatal: unable to access 
>>> 'https://gitbox.apache.org/repos/asf/jmeter.git/': Failed to connect to 
>>> gitbox.apache.org port 443: Connection timed out
>>>
>>> at 
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2661)
>>> at 
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2086)
>>> at 
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:86)
>>> at 
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:608)
>>> at 
>>> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:160)
>>> at 
>>> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:153)
>>> at hudson.remoting.UserRequest.perform(UserRequest.java:211)
>>> at hudson.remoting.UserRequest.perform(UserRequest.java:54)
>>> at hudson.remoting.Request$2.run(Request.java:376)
>>> at 
>>> hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>> at 
>>> java.util.

Re: JMeter DSL discussion

[Felix Schumacher]

Am 21.11.21 um 10:47 schrieb Vladimir Sitnikov:
>> Can the kotlin templating mechanism be switched off in that case?
> Unfortunately, there's no way to switch it off yet.
> The issue is known as https://youtrack.jetbrains.com/issue/KT-2425
>
>> I don't understand it, can you give an example?
> testPlan {
> var orderId by variables.regex()
> http {
> url = "example.com"
> extractRegex {
> storeTo(orderId)
> // or variable = orderId
> }
> }
> http("example.com/orders/$orderId")
> http(".../${orderId.random}")
>
> In other words, orderId "allocates" a variable name (e.g. orderIdVar), then
> regex extractor is configured to store the value to "orderIdVar"
> Later, $orderId is Kotlin expression that calls orderId.toString() which
> would return the variable name "orderIdVar"

Given this example I can understand, how $orderId will be rendered to
${orderIdVar} and I think same feature (#toString) can be used to
introduce JMeter functions.

What I don't get yet, is why or how the variables.regex() would be
needed. What would it do at that place? I would understand the
declaration of a general variable, but (at the moment) not a special
regex one. At the same time I fail to understand the usage of
${orderId.random} (probably for the same reason).

With respect to naming `extractRegex`:

 * we are not extracting a regex, but something using a regex. Should we
make that more clear by using something like `extractByRegex`?

 * we have a lot of different extractors, can/should these be made more
unified by using something like `extractor(regex) { storeTo(orderId) ... }`?

>
>> I wanted to ask about the intended usage. How should those possibilities
> map to the elements?
>
> That is the key question :)
> They all will be useful.

>
>> Currently we get the JMeterContext by a static function and everyone
> would get the same context. That is no problem when used inside the GUI,
> but might be a problem, when used by developers in other circumstances
> (and not aware of this)
>
> That is sad indeed, yet it it does not block DSL implementation. It would
> be great to lift that restriction and make JMeter less static in the future.

Yes, it has nothing directly to do with this discussion of a DSL, but I
think it might be more dangerous, when people start using it.

Felix

> Vladimir
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: Build failed in Jenkins: JMeter » JMeter-trunk #332

[Felix Schumacher]

I have temporarily disabled the scm change trigger on that build, as it
keeps getting started and fails.

Felix

Am 20.11.21 um 17:31 schrieb Felix Schumacher:
> Infra says, that jenkins is currently being blocked from accessing
> gitbox. I think the failed builds will be back to green, once that issue
> has been solved.
>
> Felix
>
> Am 20.11.21 um 17:29 schrieb Apache Jenkins Server:
>> See 
>> <https://ci-builds.apache.org/job/JMeter/job/JMeter-trunk/332/display/redirect>
>>
>> Changes:
>>
>>
>> --
>> Started by an SCM change
>> Running as SYSTEM
>> [EnvInject] - Loading node environment variables.
>> Building remotely on H29 (ubuntu) in workspace 
>> <https://ci-builds.apache.org/job/JMeter/job/JMeter-trunk/ws/>
>> [WS-CLEANUP] Deleting project workspace...
>> [WS-CLEANUP] Done
>> The recommended git tool is: NONE
>> No credentials specified
>>  > git rev-parse --resolve-git-dir 
>> <https://ci-builds.apache.org/job/JMeter/job/JMeter-trunk/ws/.git> # 
>> timeout=10
>> Fetching changes from the remote Git repository
>>  > git config remote.origin.url 
>> https://gitbox.apache.org/repos/asf/jmeter.git # timeout=10
>> Fetching upstream changes from https://gitbox.apache.org/repos/asf/jmeter.git
>>  > git --version # timeout=10
>>  > git --version # 'git version 2.17.1'
>>  > git fetch --tags --progress -- 
>> https://gitbox.apache.org/repos/asf/jmeter.git 
>> +refs/heads/*:refs/remotes/origin/* # timeout=10
>> ERROR: Error fetching remote repo 'origin'
>> hudson.plugins.git.GitException: Failed to fetch from 
>> https://gitbox.apache.org/repos/asf/jmeter.git
>>  at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:1000)
>>  at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1241)
>>  at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1301)
>>  at hudson.scm.SCM.checkout(SCM.java:505)
>>  at hudson.model.AbstractProject.checkout(AbstractProject.java:1211)
>>  at 
>> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:636)
>>  at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
>>  at 
>> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:508)
>>  at hudson.model.Run.execute(Run.java:1906)
>>  at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
>>  at hudson.model.ResourceController.execute(ResourceController.java:97)
>>  at hudson.model.Executor.run(Executor.java:429)
>> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
>> --progress -- https://gitbox.apache.org/repos/asf/jmeter.git 
>> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
>> stdout: 
>> stderr: fatal: unable to access 
>> 'https://gitbox.apache.org/repos/asf/jmeter.git/': Failed to connect to 
>> gitbox.apache.org port 443: Connection timed out
>>
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2661)
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2086)
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:86)
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:608)
>>  at 
>> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:160)
>>  at 
>> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:153)
>>  at hudson.remoting.UserRequest.perform(UserRequest.java:211)
>>  at hudson.remoting.UserRequest.perform(UserRequest.java:54)
>>  at hudson.remoting.Request$2.run(Request.java:376)
>>  at 
>> hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
>>  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>  at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>  at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>  at java.lang.Thread.run(Thread.java:748)
>>  Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
>> H29
>>  at 
>> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1800)
>>  at 
>> hudson.remoting.UserRequest$ExceptionRes

Re: Build failed in Jenkins: JMeter » JMeter-trunk #332

[Felix Schumacher]

Infra says, that jenkins is currently being blocked from accessing
gitbox. I think the failed builds will be back to green, once that issue
has been solved.

Felix

Am 20.11.21 um 17:29 schrieb Apache Jenkins Server:
> See 
> 
>
> Changes:
>
>
> --
> Started by an SCM change
> Running as SYSTEM
> [EnvInject] - Loading node environment variables.
> Building remotely on H29 (ubuntu) in workspace 
> 
> [WS-CLEANUP] Deleting project workspace...
> [WS-CLEANUP] Done
> The recommended git tool is: NONE
> No credentials specified
>  > git rev-parse --resolve-git-dir 
>  # 
> timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url 
> https://gitbox.apache.org/repos/asf/jmeter.git # timeout=10
> Fetching upstream changes from https://gitbox.apache.org/repos/asf/jmeter.git
>  > git --version # timeout=10
>  > git --version # 'git version 2.17.1'
>  > git fetch --tags --progress -- 
> https://gitbox.apache.org/repos/asf/jmeter.git 
> +refs/heads/*:refs/remotes/origin/* # timeout=10
> ERROR: Error fetching remote repo 'origin'
> hudson.plugins.git.GitException: Failed to fetch from 
> https://gitbox.apache.org/repos/asf/jmeter.git
>   at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:1000)
>   at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1241)
>   at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1301)
>   at hudson.scm.SCM.checkout(SCM.java:505)
>   at hudson.model.AbstractProject.checkout(AbstractProject.java:1211)
>   at 
> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:636)
>   at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
>   at 
> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:508)
>   at hudson.model.Run.execute(Run.java:1906)
>   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
>   at hudson.model.ResourceController.execute(ResourceController.java:97)
>   at hudson.model.Executor.run(Executor.java:429)
> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
> --progress -- https://gitbox.apache.org/repos/asf/jmeter.git 
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> stdout: 
> stderr: fatal: unable to access 
> 'https://gitbox.apache.org/repos/asf/jmeter.git/': Failed to connect to 
> gitbox.apache.org port 443: Connection timed out
>
>   at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2661)
>   at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2086)
>   at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:86)
>   at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:608)
>   at 
> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:160)
>   at 
> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:153)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:211)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:54)
>   at hudson.remoting.Request$2.run(Request.java:376)
>   at 
> hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
>   Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
> H29
>   at 
> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1800)
>   at 
> hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:356)
>   at hudson.remoting.Channel.call(Channel.java:1001)
>   at 
> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
>   at sun.reflect.GeneratedMethodAccessor777.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
>   at com.sun.proxy.$Proxy150.execute(Unknown Source)
>   at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:998)
>   at 

Re: JMeter DSL discussion

[Felix Schumacher]

Am 20.11.21 um 14:28 schrieb Vladimir Sitnikov:
>> 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.

Well, maybe we see use cases, when we see the first implementation of
the generating function (`http`, `aggregateReport` in your example).

I thought it might help developers of plugins to get started on
integration into the dsl.

>
>> 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.
My idea was to use it to explicitly hinder us from re-using the code :)
but we could try with an annotation and see how it works out.
>
> 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
If you have a clear idea, of a structure, we could use that, but if not,
it is (in my opinion) valid to start with such a mess.
>
>> 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 (no) idea what would work the best to resolve it.
> Changing syntax to %{..} might work.
I think, we already use %{..} inside JMeter, too. (Template language for
the https script recorder naming logic)
> Changing syntax to explicit expr("__javaScript(...)") might work as well.
Can the kotlin templating mechanism be switched off in that case?
> 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

I don't understand it, can you give an example? Something like a
dsl-function (`http(jmVar("host))` and `http("""${jmFunc("upper",
jmVar("hostname"))}""")` (not sure, if it is valid kotlin))


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

I wanted to ask about the intended usage. How should those possibilities
map to the elements?

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

Currently we get the JMeterContext by a static function and everyone
would get the same context. That is no problem when used inside the GUI,
but might be a problem, when used by developers in other circumstances
(and not aware of this)

Felix

>
> Vladimir
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: JMeter DSL discussion

[Felix Schumacher]

Am 20.11.21 um 12:46 schrieb Vladimir Sitnikov:
>> Do you have a rough idea, what the dsl would look like, or how the
>> elements get mapped/detected to be a part of the dsl?
> Commonly used elements have to be mapped manually for consistency reasons.
> There might be a generic (string-like) approach to allow fine-tuning.

I wondered, whether we could add annotations and a annotations processor
to generate code/classes, that could be used to setup dsl components.
The annotations could be used for scanning for TestPlan elements on
startup, too.

>
>> Could you elaborate a bit more on your plan, or would the extra module
>> be really an add-on?
> I am not sure yet.
> It might be that it would be good enough to keep the dsl classes side by
> side with the corresponding elements.
> In other words, creating a module for a couple of classes might not be that
> justified.

When we try to get our code into modules, it might be a good idea to
have this sorted out, before (but that should not let us keep from
experimenting).

Maybe start with a global org.apache.jmeter.experimental.dsl
package/module name, and mash everything in there for a start?

>
>> Do you have a rough idea, what the dsl would look like
> Something behind the lines of
>
> val plan = testPlan {
> aggregateReport {
> outputFile = File("...")
> }
> openModelThreadGroup {
> schedule {
> rate(50.0 / second)
> random_arrivals(10.minutes)
> }
> transaction("hello") {
> http("http://hello.example;)
> http("http://world.example;)
> }
> }
> }
>
> println(plan.toJxm())
> plan.execute()

Kotlin has a very similar string template format to JMeter, is there a
good way to distinguish those, or guard the JMeter ones?

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?

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?

Felix

>
> Vladimir
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: JMeter DSL discussion

[Felix Schumacher]

Am 20.11.21 um 10:20 schrieb Vladimir Sitnikov:
>> I think it's important to slowly isolate the Jmeter core from GUI,
> If anybody wants to contribute that, please do so.
>
> Antonio>I think it's a good idea to add DSL in core is a good idea
>
> The immediate question is do we put classes for DSL right into the
> current ApacheJMeter_core, ApacheJMeter_http, ApacheJMeter_jdbc,
> or do we create a new set of modules like ApacheJMeter_core_dsl,
> ApacheJMeter_http_dsl, and so on?
>
> It might be that in the future ApacheJMeter_http would become
> ApacheJMeter_http, ApacheJMeter_http_gui, ApacheJMeter_http_dsl.
> That would triple the number of folders in src/protocols.
>
> If there are no objections, I would try adding DSL via extra modules.

Could you elaborate a bit more on your plan, or would the extra module
be really an add-on?

Do you have a rough idea, what the dsl would look like, or how the
elements get mapped/detected to be a part of the dsl?

Felix

>
> Vladimir
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: Should we drop TestSaveService.testFILEVERSION test and SaveService.FILEVERSION field?

[Felix Schumacher]

Am 14.11.21 um 09:28 schrieb Vladimir Sitnikov:
> Hi,
>
> I see that TestSaveService > testFILEVERSION fails on every update of
> saveservice.properties.
> What is the purpose of testFILEVERSION?

I believe it is intended to nag the developers to keep the too files
SaveService.java and saveservice.properties in sync.

So, in a sense, it is being used. (No idea, if it is useful enough. Has
it done its purpose and reminded you to edit both files at once?)

Felix

>
> I suggest we just remove SaveService#FILEVERSION field as it is not really
> used.
>
>
> The failure looks as follows:
>
> FAILURE   0.0sec, org.apache.jmeter.save.TestSaveService > testFILEVERSION()
> org.junit.ComparisonFailure: SaveService class and
> saveservice.properties must be aligned. Please ensure you have edited both
> files, and update SaveService.FILEVERSION
> expected:<6[6ea47f7da884dff1c42ccede75113971c5c11f3]> but
> was:<6[74d875c816319b93445640a35045b316f7d7456]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at
> org.apache.jmeter.save.TestSaveService.testFILEVERSION(TestSaveService.java:94)
>
> Vladimir
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: Move "precise throughput computation" to thread group

[Felix Schumacher]

Hi,

I was a bit silent on the last discussion, so I try to combine my
opinions on some of the points in this mail.

* Deprecating the "old" ThreadGroup.

I think the old ThreadGroup has a nice and simple interface, that can be
understood in a short time (my opinion :)). The new one should be as
easy for easy use cases.

Removing it would not be a good idea until the new one catches on (and
even then might better be kept)

* Semantic of the DSL

That should probably be run on some users and hear their feedback. For
me it was not clear, why "rate(0/min) even_arrivals(10m) rate(60/m)"
would result in a continuous ramp up and not a sharp edged one.

Maybe we could include the new Thread Group with a big *experimental*
label for a while.

* Including Kotlin and using it for further development

I once tried Scala and liked it for my simple tests. I haven't really
tried out Kotlin now, but I believe I could work with it.

However I really like Eclipse as my IDE and don't know the state of
usability it has reached regarding Kotlin. (I know, that I don't like
working on the gradle files for exactly that reason).

* Including lets-plot

The examples on the github repo are looking really nice and a nice
looking graphics is always a good way to attract more users. Therefore
it would be cool to have it. But as Vladimir explained, it would add a
lot of unwanted dependecies in the core. Could we work around this anyway?

* Moving to a newer Java baseline

That was  a topic I wanted to ask for a long time. More and more
libraries are 9+ or 11+ nowadays and we should follow up. I am
uncertain, whether to jump to 17 or 11, but either way, I would really
like to switch to something more modern.

* Using the Java Module system

I think it would be a lot of work to switch to the module system. We
would have to clean up our jars to be exclusive owner of their packages,
define the dependencies more explicit, look at our extensive usage of
reflection, ...

Is it possible to keep going on without the module system in newer Java
versions? I have no idea.

* New contributors falling out of the sky

I would like to see that happen, but haven't observed it, yet :)

Felix

Am 05.11.21 um 22:35 schrieb Vladimir Sitnikov:
>> I said that as scheduleParser.kt, scheduleTokenizer.kt are related to DSL,
>> I am ok with them being in Kotlin.
> Then it is a misunderstanding.
> They implement a typical textbook regular-expression-based tokenizer and
> parser.
>
> The files have nothing to do with Kotlin DSL for programmatic test plan
> generation so far.
>
> Of course, DSL is a very broad term, however, the key aim of
> scheduleParser.kt, scheduleTokenizer.kt
> is to parse **string** with load profile configuration (e.g. "rate(5/sec)
> random_arrivals(2 min) rate(10/sec)")
> and convert it to Java objects or throw a parse error (e.g. in case a user
> types an invalid time unit).
>
> That parsing logic can be implemented in Java, however, it would be
> cumbersome taking into account Java 8.
>
>> Now if you don't work in Kotlin
> My job is ~90% PL/SQL though.
>
>>> Philippe>Finalizing move to Java 11 without all the flags might be a
> first
>> step.
> Philippe>What about this ?
>
> TL;DR: I would support that, however, I am not keen on spending my time on
> doing the migration.
>
> Frankly speaking, I think Java 11 is out of date now, and, we, as an
> application can move to Java 17 right away.
> Here's Elasticsearch moving to Java 17:
> https://twitter.com/xeraa/status/1455980076001071106
> Upgrading Java baseline is probably worth doing, however, it is not clear
> what features does it bring.
>
> If we bump the baseline to Java 11 (or 17, does not really matter much),
> then we probably can have access to a broader set of libraries.
> For instance, https://github.com/kirill-grouchnikov/radiance is Java 9+.
>
> However, I am much more fascinated by creating the improved thread group,
> creating Kotlin-based DSL for test plan generation,
> creating in-core parallel controller, trying async clients (for HTTP/gRPC),
> etc.
> Java 11 does not seem to make those tasks significantly easier.
>
> Vladimir
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: Suggestion: It would be more convenient if adding function of jumping to the api node directly from View Results Tree by double clicking

[Felix Schumacher]

I think that idea has already been proposed in
https://bz.apache.org/bugzilla/show_bug.cgi?id=51818

It could be helpful. Would you like to implement it?

Felix

Am 04.11.21 um 12:41 schrieb Di Guo (US):
>   Hello Jmeter team,
>
>       I am a Jmeter user and always use Jmeter to do
> functional/performance testing. I like its rich functions and good
> user experience.
>       But these days I have found that there is one problem for me. I
> like to use the View Results Tree to check the response of each api,
> and when there are more and more api calls in one test scenario while
> debugging, I found that it would take some time to find the
> correlating api call in test script from the View Results Tree when
> there are many duplicated ones in test script(Please check the
> screenshot in attachment). The best way I have thought over is to add
> one double click function in the View Results Tree node that can
> directly navigate to the source api node. 
>       That's all my suggestion, if there is any workaround for this,
> would you please also let me know about that? 
>       Thank you so much!
>
>
> The information transmitted, including any attachments, is intended
> only for the person or entity to which it is addressed and may contain
> confidential and/or privileged material. Any review, retransmission,
> dissemination or other use of, or taking of any action in reliance
> upon, this information by persons or entities other than the intended
> recipient is prohibited, and all liability arising therefrom is
> disclaimed. If you received this in error, please contact the sender
> and delete the material from any computer. 
>
>
> In the event the content of this email includes Tax advice, the
> content of this email is limited to the matters specifically addressed
> herein and is not intended to address other potential tax consequences
> or the potential application of tax penalties to this or any other matter.
>
>
> PricewaterhouseCoopers LLP is a Delaware limited liability
> partnership.  This communication may come from PricewaterhouseCoopers
> LLP or one of its subsidiaries.
>


OpenPGP_signature
Description: OpenPGP digital signature

Re: JMeter Runtime Issue

[Felix Schumacher]

This seems to be a question about the usage of JMeter, so users@ would
have been a better mailing list to use (see
https://jmeter.apache.org/mail2.html#JMeterUser for more information on
how to subscribe).

Apart from this. Have you started the test plan?

Felix

Am 08.10.21 um 15:25 schrieb Dayana R:
> Hi Team,
>
> I have faced  issues while using JMeter.I have installed the
> application and proceed the following steps to run the application but
> I'm not getting output.Here I'm attaching the steps that
> followed.kindly help.
>
> Regards,
>
> Dayana Raju
>
>
>
>
> *Disclaimer: *
> *This message and any attachment(s) contained here are information
> that is confidential, proprietary to Unimity Solutions Pvt. Ltd. and
> its clients. *
> *
> *
> *Contents may be privileged or otherwise protected by law. The
> information is solely intended for the individual or the entity it is
> addressed to. If you are not the intended recipient of this message,
> you are not authorized to read, forward, print, retain, copy or
> disseminate this message or any part of it. If you have received this
> e-mail in error, please notify the sender immediately by return e-mail
> and delete it from your computer. *
> *
> *
> *This email and attachments are scanned for viruses.* 


OpenPGP_signature
Description: OpenPGP digital signature

Re: Broken links in Documentation section of README.md file

[Felix Schumacher]

Hi Niranjan,

can you tell us, what you tried to fix it, or which links are broken
(your expectation and your observation)?

Felix

Am 27.09.21 um 19:58 schrieb Niranjan Ghule:
> Hi,
>
> The links of printable docs and index.html are broken in the Documentation
> section of the README.md file.
>
> I couldn't fix it. Can somebody look into this?
>
> Thanks & Regards,
> Niranjan
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: Darklaf - A themeable swing Look and Feel based on Darcula-Laf

[Felix Schumacher]

Am 01.04.20 um 18:30 schrieb Antonio Gomes Rodrigues:
> Hi
>
> Good job, JMeter is much more beautiful now
>
> I have tested the last nighty in a fresh Ubuntu linux and I have two
> warnings when I launch JMeter
>
> Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
> WARNING: Could not create font Arial
> Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
> WARNING: Could not create font Arial
> Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
> WARNING: Could not create font Arial
> Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
> WARNING: Could not create font Arial
> Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
> WARNING: Could not create font Arial
> Apr 01, 2020 5:25:35 PM com.kitfox.svg.Text buildText
> WARNING: Could not create font Arial
>
> I need to install Arial font with:
> sudo apt install ttf-mscorefonts-installer
>
> Gtk-Message: 17:25:36.748: Failed to load module "canberra-gtk-module"
> I need to insyall the module with:
> sudo apt install libcanberra-gtk-module

And only about one year later, we got rid of the warnings ;)

The svg had some references to the Arial font embedded, which it didn't
need.

Felix

>
>
>
> Le dim. 8 mars 2020 à 14:27, sebb  a écrit :
>
>> On Thu, 5 Mar 2020 at 17:28, Vladimir Sitnikov
>>  wrote:
 Properties, XML, etc are not executed by the JVM; they are effectively
 just data.
>>> BeanShell, JavaScript, and Groovy are not "just data", but it is code
>> which
>>> is a part of JMeter.
>>>
>>> So far I see no technical justification for requiring all transitive
>>> dependencies to be written in Java language only.
>> I'll try again.
>>
>> + The main reason is portability.
>>
>> Compiled Java source is portable to all systems that have a suitable JVM.
>>
>> Native code is inherently not portable.
>>
>> + Another reason is that compiled Java byte code cannot cause a JVM crash.
>> Native code can (and does) cause crashes, and these are generally very
>> difficult to debug.
>>
>> + A third reason is that Java source code only needs a JDK to compile it.
>> There is no need to install additional compilers.
>> Indeed you can compile the code on one OS and deploy on another.
>>
>> Native code usually means installing a C-compiler.
>> Unfortunately, there are lots of varieties of C-compilers with
>> incompatible options and syntax.
>> This make compiling native code rather difficult and error-prone
>> Also compilation generally has to be done on the same OS version.
>>
>> ===
>>
>> As far as JMeter is concerned, it is the first two reasons that are
>> most important.
>> The 3rd reason is of more concern to creators of distributions.
>>
>> ===
>>
>> Note that BeanShell, JavaScript (Rhino) and Groovy are themselves pure
>> Java - that is why the same jar can be used on all OSes.
>>
>> ===
>>
>> I hope you now understand what 100% Pure Java is about and why it is
>> important to JMeter?
>>
>>> Vladimir



OpenPGP_signature
Description: OpenPGP digital signature

Re: Starting Jmeter without the logo

[Felix Schumacher]

Am 10.04.21 um 12:07 schrieb 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 ?

No, I don't think, we need it. As Adrian wrote, the splash screen is not
the problem. We should strive to make the startup of JMeter that fast,
that you hardly notice the splash screen :)


Felix

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



OpenPGP_signature
Description: OpenPGP digital signature

Re: Undocumented feature on Thread Group?

[Felix Schumacher]

Am 11.02.21 um 21:34 schrieb Noah Kuzas:
> Felix,
>
> I also tried the shorthand ./gradlew previewSite and still nothing. Checking 
> under the src/dist/build/site/usermanual/component_reference.xml
I would look at the generated HTML files, but the .xml is probably a
typo, right?
>
> Build does show as success. Few warnings below:
>
> Src:dist-check
> -certain tests will be skipped as they depend on external services...
>
> -Deprecated gradle features were used in this build, making them incompatible 
> with gradle 7.0.
>
> BUILD SUCCESS actionable tasks:17 executed, 1 from cache 56 up-to-date.
>
> Side note: on the jmeter website under Component Reference, there are notes 
> ( <\note>) under the Thread Group, but I don’t see this code in the 
> xdocs>usermanual>component_referene.xml file..

Do you mean the note about ramp up periods on line 6533?

What is "git diff" showing?

Felix

>
>> On Feb 11, 2021, at 11:45 AM, Felix Schumacher 
>>  wrote:
>>
>> 
>>> Am 11.02.21 um 17:32 schrieb Noah Kuzas:
>>> Thanks for the info, I’ve added the “Same user on each Iteration” 
>>> documentation under the component_reference.xml file and executed:
>>> ./gradlew :src:dist:clean
>>> ./gradlew :src:dist:build
>>> ./gradlew :src:dist:previewSite 
>>>
>>> And fresh html files are being built, but my change isn’t present under 
>>> them.. can you advise on what I’m doing wrong? 
>> Where did you look for the updated files?
>>
>> Where there any suspicious messages when running
>>
>> ./gradlew :src:dist:previewSite
>>
>> (Note, I always execute "./gradlew previewSite" as shown by "./gradlew
>> tasks")
>>
>> It should print out "BUILD SUCCESSFUL" at the end of the run.
>>
>> Felix
>>
>>>>> On Feb 8, 2021, at 12:36 AM, Jmeter Tea  wrote:
>>>> Hi Noah,
>>>>
>>>> This is the contribution page https://jmeter.apache.org/building.html
>>>> See also building JMeter
>>>> https://jmeter.apache.org/usermanual/jmeter_tutorial.html#building
>>>> JMeter generates its documentation from XMLs located in xdocs folder
>>>> You can execute ./gradlew :src:dist:previewSite to create the updated
>>>> documentation
>>>>
>>>>
>>>>
>>>>> On Sun, Feb 7, 2021 at 8:09 PM Noah Kuzas  wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I’d like to document this feature. Could someone refer a link to
>>>>> documentation standards and pull request etiquette?
>>>>>
>>>>>>> On Feb 7, 2021, at 7:10 AM, Jmeter Tea  wrote:
>>>>>> Created a documentation issue
>>>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=65128
>>>>>>
>>>>>>> On Sat, Feb 6, 2021 at 12:48 PM Felix Schumacher <
>>>>>>> felix.schumac...@internetallee.de> wrote:
>>>>>>>
>>>>>>> Patches are welcome :)
>>>>>>>
>>>>>>> Felix
>>>>>>>
>>>>>>>> Am 27.01.21 um 13:11 schrieb Jmeter Tea:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> This enhancement was added in *Bug 62861*
>>>>>>>> <https://bz.apache.org/bugzilla/show_bug.cgi?id=62861>- Thread Group:
>>>>>>>> Provide ability to configure whether a new iteration is a new user or
>>>>>>> same
>>>>>>>> user (Would be applied on Cookie Manager, Cache Manager and
>>>>>>>> httpclient.reset_state_on_thread_group_iteration)
>>>>>>>> Need to update documentation with that feature
>>>>>>>>
>>>>>>>>> On Wed, Jan 27, 2021 at 11:02 AM Milamber 
>>>>> wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> What is the behavior of the option "Same user on each iteration" on
>>>>>>>>> Thread Group element?
>>>>>>>>>
>>>>>>>>> I don't find the description in
>>>>>>>>>
>>>>>>>>>
>>>>> https://jmeter.apache.org/usermanual/component_reference.html#Thread_Group_parms1
>>>>>>>>> Milamber
>>>>>>>>>

Re: Undocumented feature on Thread Group?

[Felix Schumacher]

Am 11.02.21 um 17:32 schrieb Noah Kuzas:
> Thanks for the info, I’ve added the “Same user on each Iteration” 
> documentation under the component_reference.xml file and executed:
>  ./gradlew :src:dist:clean
>  ./gradlew :src:dist:build
>  ./gradlew :src:dist:previewSite 
>
> And fresh html files are being built, but my change isn’t present under 
> them.. can you advise on what I’m doing wrong? 

Where did you look for the updated files?

Where there any suspicious messages when running

./gradlew :src:dist:previewSite

(Note, I always execute "./gradlew previewSite" as shown by "./gradlew
tasks")

It should print out "BUILD SUCCESSFUL" at the end of the run.

Felix

>
>> On Feb 8, 2021, at 12:36 AM, Jmeter Tea  wrote:
>>
>> Hi Noah,
>>
>> This is the contribution page https://jmeter.apache.org/building.html
>> See also building JMeter
>> https://jmeter.apache.org/usermanual/jmeter_tutorial.html#building
>> JMeter generates its documentation from XMLs located in xdocs folder
>> You can execute ./gradlew :src:dist:previewSite to create the updated
>> documentation
>>
>>
>>
>>> On Sun, Feb 7, 2021 at 8:09 PM Noah Kuzas  wrote:
>>>
>>> Hi,
>>>
>>> I’d like to document this feature. Could someone refer a link to
>>> documentation standards and pull request etiquette?
>>>
>>>>> On Feb 7, 2021, at 7:10 AM, Jmeter Tea  wrote:
>>>> Created a documentation issue
>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=65128
>>>>
>>>>> On Sat, Feb 6, 2021 at 12:48 PM Felix Schumacher <
>>>>> felix.schumac...@internetallee.de> wrote:
>>>>>
>>>>> Patches are welcome :)
>>>>>
>>>>> Felix
>>>>>
>>>>>> Am 27.01.21 um 13:11 schrieb Jmeter Tea:
>>>>>> Hello,
>>>>>>
>>>>>> This enhancement was added in *Bug 62861*
>>>>>> <https://bz.apache.org/bugzilla/show_bug.cgi?id=62861>- Thread Group:
>>>>>> Provide ability to configure whether a new iteration is a new user or
>>>>> same
>>>>>> user (Would be applied on Cookie Manager, Cache Manager and
>>>>>> httpclient.reset_state_on_thread_group_iteration)
>>>>>> Need to update documentation with that feature
>>>>>>
>>>>>>> On Wed, Jan 27, 2021 at 11:02 AM Milamber 
>>> wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> What is the behavior of the option "Same user on each iteration" on
>>>>>>> Thread Group element?
>>>>>>>
>>>>>>> I don't find the description in
>>>>>>>
>>>>>>>
>>> https://jmeter.apache.org/usermanual/component_reference.html#Thread_Group_parms1
>>>>>>> Milamber
>>>>>>>

Re: About adding JSonPointer extractor

[Felix Schumacher]

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

Re: Undocumented feature on Thread Group?

[Felix Schumacher]

Patches are welcome :)

Felix

Am 27.01.21 um 13:11 schrieb Jmeter Tea:
> Hello,
>
> This enhancement was added in *Bug 62861*
> - Thread Group:
> Provide ability to configure whether a new iteration is a new user or same
> user (Would be applied on Cookie Manager, Cache Manager and
> httpclient.reset_state_on_thread_group_iteration)
> Need to update documentation with that feature
>
> On Wed, Jan 27, 2021 at 11:02 AM Milamber  wrote:
>
>> Hello,
>>
>> What is the behavior of the option "Same user on each iteration" on
>> Thread Group element?
>>
>> I don't find the description in
>>
>> https://jmeter.apache.org/usermanual/component_reference.html#Thread_Group_parms1
>>
>> Milamber
>>

Re: [VOTE] Release JMeter 5.4.1 RC2

[Felix Schumacher]

Am 17.01.21 um 14:20 schrieb Milamber:
> 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.
>
> [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.
>
>
> 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!

Thanks for RM!

Felix (binding)

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

Re: [VOTE] Release JMeter 5.4.1 RC1

[Felix Schumacher]

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

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

[Felix Schumacher]

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;
>>>  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;
>>> +i

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

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

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;
>>  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();
>>  }
>>
>>

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

[Felix Schumacher]

Am 14. Januar 2021 21:47:34 MEZ schrieb Philippe Mouawad 
:
>Hello Felix,
>Should we set it from within code ?

If you like it better, that should be possible, too.

But I have another patch in the pipeline, where tika is used, too. We would 
have to also add it there, I believe. 

>It seems it's triggered by ParseCurlCommandAction

At the moment, yes. 

Felix 

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

Re: [VOTE] Release JMeter 5.4.1 RC1

[Felix Schumacher]

Am 11.01.21 um 16:33 schrieb Milamber:
> 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.
>
> [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.
>
>
> 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!


Regards

 Felix (binding)

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

Re: [VOTE] Release JMeter 5.4.1 RC1

[Felix Schumacher]

Am 14.01.21 um 13:52 schrieb 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.

I thought we could ignore the warning, but OK :) googling after the
warning I found the SO question:
https://stackoverflow.com/questions/48970160/how-do-i-configure-the-pom-xml-of-tika-to-stop-getting-all-the-license-dependenc
which has the tipp to set the java system property tika.config to point
to a file containing

|That will silence
the warning. Regards Felix |

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

Re: Release 5.4.1

[Felix Schumacher]

Am 11. Januar 2021 12:49:53 MEZ schrieb Milamber :
>
>I can start the release process for 5.4.1 today?

That would be awesome

 Felix 

>
>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
>>>>  <mailto: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.
>>>>  >>
>>>>      >> How long should we calculate?
>>>>  >>
>>>>

Re: Release 5.4.1

[Felix Schumacher]

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

Re: Release 5.4.1

[Felix Schumacher]

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.

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.

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
> mailto: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.
> >>
> >> 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  <mailto:milam...@apache.org>>
> >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

Re: Setting better defaults for HTTP request

[Felix Schumacher]

Am 20.12.20 um 21:31 schrieb 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 ?

I think it is.

When the element gets cloned, all properties are copied (including the
empty ones), so we don't get a NullProperty, but an empty StringProperty.

I think it is safe to add

---
a/src/core/src/main/java/org/apache/jmeter/testelement/AbstractTestElement.java
+++
b/src/core/src/main/java/org/apache/jmeter/testelement/AbstractTestElement.java
@@ -27,6 +27,7 @@ import java.util.List;
 import java.util.Map;
 import java.util.Set;
 
+import org.apache.commons.lang3.StringUtils;
 import org.apache.jmeter.gui.Searchable;
 import org.apache.jmeter.testelement.property.BooleanProperty;
 import org.apache.jmeter.testelement.property.CollectionProperty;
@@ -240,7 +241,10 @@ public abstract class AbstractTestElement
implements TestElement, Serializable,
 @Override
 public int getPropertyAsInt(String key, int defaultValue) {
 JMeterProperty jmp = getRawProperty(key);
-    return jmp == null || jmp instanceof NullProperty ?
defaultValue : jmp.getIntValue();
+    if (jmp == null || jmp instanceof NullProperty ||
StringUtils.isBlank(jmp.getStringValue())) {
+    return defaultValue;
+    }
+    return jmp.getIntValue();
 }

to handle that case.

Question here is, should we add such logic to the other special handlers
(boolean, etc.), too?

Felix

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

Re: Setting better defaults for HTTP request

[Felix Schumacher]

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

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

[Felix Schumacher]

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
>

Re: Release 5.4.1

[Felix Schumacher]

Am 11. Dezember 2020 12:16:09 MEZ schrieb 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 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
>> >>
>> >>
>>

Re: Release 5.4.1

[Felix Schumacher]

Am 11. Dezember 2020 11:45:22 MEZ schrieb Philippe Mouawad 
:
>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. 

>
>Looks a bit too early for me.

How long should we calculate? 

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

Re: Release 5.4.1

[Felix Schumacher]

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

Re: Release 5.4.1

[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

Re: [VOTE] Release JMeter 5.4 RC2

[Felix Schumacher]

Am 29.11.20 um 17:55 schrieb Milamber:
> 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.
>
> [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.
There is one small markup error in the changes.xml, which has been
corrected and can by synced to the site later, so no real problem there.

Thanks for the RM

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

Re: [VOTE] Release JMeter 5.4 RC1

[Felix Schumacher]

Am 25.11.20 um 18:45 schrieb Milamber:
> Hello,
>
> Please ping me when I can start the RC2.

I think, we can try another round.

Felix

>
> Milamber
>
> On 11/25/20 4:59 PM, Felix Schumacher wrote:
>> Am 24.11.20 um 22:58 schrieb Vladimir Sitnikov:
>>> I wonder why all those plugins depend on LoggingManager.
>> I think that is a lot of historical baggage. The plugins from
>> jmeter-plugins repository are all cleaned up and will be released
>> sometime in the future.
>>
>>> Given the number of usages, we would have to keep the class forever, so we
>>> might want to add the related javadoc.
>> We can keep them, should we still mark those as deprecated?
>>> If the third-party plugins use the class for logging purposes, then we
>>> might even want to heal the class (e.g. divert all the logging calls to the
>>> current slf4j)
>> I think the healing will depend on the jars that the
>> plugin/plugin-manager brings to the table. If it uses our implementation
>> of LoggingManager it will get a LogKit-adapter that delegates all log
>> messages to SLF4J, does'nt it?
>>> It is sad I did not check the usages outside of JMeter :-(
>> No problem, I am happy, that we found this before we released a new version.
>>
>> Felix
>>
>>> Vladimir
>>>
>

Re: [VOTE] Release JMeter 5.4 RC1

[Felix Schumacher]

Am 26.11.20 um 01:48 schrieb Graham Russell:
> A small thing from me, I noticed that the Raw InfluxDB Backend
> Listener (https://github.com/apache/jmeter/pull/544) wasn't mentioned
> in the change log.
> Could someone add it before the RC2?

Has been added. Sorry for missing this out.

Felix

> Thanks!
>
> Graham
>
> On Wed, 25 Nov 2020 at 17:46, Milamber  wrote:
>> Hello,
>>
>> Please ping me when I can start the RC2.
>>
>> Milamber
>>
>> On 11/25/20 4:59 PM, Felix Schumacher wrote:
>>> Am 24.11.20 um 22:58 schrieb Vladimir Sitnikov:
>>>> I wonder why all those plugins depend on LoggingManager.
>>> I think that is a lot of historical baggage. The plugins from
>>> jmeter-plugins repository are all cleaned up and will be released
>>> sometime in the future.
>>>
>>>> Given the number of usages, we would have to keep the class forever, so we
>>>> might want to add the related javadoc.
>>> We can keep them, should we still mark those as deprecated?
>>>> If the third-party plugins use the class for logging purposes, then we
>>>> might even want to heal the class (e.g. divert all the logging calls to the
>>>> current slf4j)
>>> I think the healing will depend on the jars that the
>>> plugin/plugin-manager brings to the table. If it uses our implementation
>>> of LoggingManager it will get a LogKit-adapter that delegates all log
>>> messages to SLF4J, does'nt it?
>>>> It is sad I did not check the usages outside of JMeter :-(
>>> No problem, I am happy, that we found this before we released a new version.
>>>
>>> Felix
>>>
>>>> Vladimir
>>>>

Re: [VOTE] Release JMeter 5.4 RC1

[Felix Schumacher]

Has been merged. Thanks for the PR.

Felix

Am 26.11.20 um 17:14 schrieb Vincent Daburon:
> Hi,
> I open a pull request for image ratio modifications
> https://github.com/apache/jmeter/pull/635
>
> In the documentation, http request, the image don’t have correct ratio format
> img src="../../docs/images/screenshots/http-request-advanced-tab.png"
> width="951" height="284"
> The full image size is
> 1113px × 642px  => 1113/642=1,73364486
>
> The same ratio format is
> 951/548
> So change the height="284" to height="548"
>
> Images ratios changed
> src="../../docs/images/screenshots/http-request-advanced-tab.png"
> width="951" height="548"
> src="../../docs/images/screenshots/csvdatasetconfig.png" width="658"
> height="281"
> src="../../docs/images/screenshots/threadgroup.png" width="911" height="662 »
> src="../../docs/images/screenshots/curl/enter_command.png" width="767"
> height="443"
> src="../../docs/images/screenshots/curl/enter_command_from_file.png"
> width="767" height="449"
> src="../../docs/images/screenshots/curl/result.png" width="767" height="464"
> src="../../docs/images/screenshots/curl/http_request_warning.png"
> width="768" height="464"
>
> Regards.
>
> Vincent DABURON
>
>
> Le jeu. 26 nov. 2020 à 01:49, Graham Russell  a écrit :
>> A small thing from me, I noticed that the Raw InfluxDB Backend
>> Listener (https://github.com/apache/jmeter/pull/544) wasn't mentioned
>> in the change log.
>> Could someone add it before the RC2?
>>
>> Thanks!
>>
>> Graham
>>
>> On Wed, 25 Nov 2020 at 17:46, Milamber  wrote:
>>> Hello,
>>>
>>> Please ping me when I can start the RC2.
>>>
>>> Milamber
>>>
>>> On 11/25/20 4:59 PM, Felix Schumacher wrote:
>>>> Am 24.11.20 um 22:58 schrieb Vladimir Sitnikov:
>>>>> I wonder why all those plugins depend on LoggingManager.
>>>> I think that is a lot of historical baggage. The plugins from
>>>> jmeter-plugins repository are all cleaned up and will be released
>>>> sometime in the future.
>>>>
>>>>> Given the number of usages, we would have to keep the class forever, so we
>>>>> might want to add the related javadoc.
>>>> We can keep them, should we still mark those as deprecated?
>>>>> If the third-party plugins use the class for logging purposes, then we
>>>>> might even want to heal the class (e.g. divert all the logging calls to 
>>>>> the
>>>>> current slf4j)
>>>> I think the healing will depend on the jars that the
>>>> plugin/plugin-manager brings to the table. If it uses our implementation
>>>> of LoggingManager it will get a LogKit-adapter that delegates all log
>>>> messages to SLF4J, does'nt it?
>>>>> It is sad I did not check the usages outside of JMeter :-(
>>>> No problem, I am happy, that we found this before we released a new 
>>>> version.
>>>>
>>>> Felix
>>>>
>>>>> Vladimir
>>>>>

Re: [VOTE] Release JMeter 5.4 RC1

[Felix Schumacher]

Am 24.11.20 um 22:58 schrieb Vladimir Sitnikov:
> I wonder why all those plugins depend on LoggingManager.

I think that is a lot of historical baggage. The plugins from
jmeter-plugins repository are all cleaned up and will be released
sometime in the future.

> Given the number of usages, we would have to keep the class forever, so we
> might want to add the related javadoc.
We can keep them, should we still mark those as deprecated?
> If the third-party plugins use the class for logging purposes, then we
> might even want to heal the class (e.g. divert all the logging calls to the
> current slf4j)
I think the healing will depend on the jars that the
plugin/plugin-manager brings to the table. If it uses our implementation
of LoggingManager it will get a LogKit-adapter that delegates all log
messages to SLF4J, does'nt it?
>
> It is sad I did not check the usages outside of JMeter :-(

No problem, I am happy, that we found this before we released a new version.

Felix

>
> Vladimir
>

Re: [VOTE] Release JMeter 5.4 RC1

[Felix Schumacher]

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

Re: [VOTE] Release JMeter 5.4 RC1

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

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

Re: [VOTE] Release JMeter 5.4 RC1

[Felix Schumacher]

Am 24.11.20 um 16:10 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 ?
> For most classes this is no problem:
>
> find . -name "*.java" -type f \
>    | xargs -l1 grep -l "private static final Logger" \
>    | while read i; do
>    sed -i 's/private static final Logger \(LOGGER\|log\) =
> LoggingManager.getLoggerForClass();/private static final Logger \1 =
> LoggerFactory.getLogger('$(basename $i .java)'.class);/;
> s/org.apache.jorphan.logging.LoggingManager/org.slf4j.LoggerFactory/;
> s/org.apache.log.Logger/org.slf4j.Logger/;' $i;
>  done
>
> will get you going for most classes.
>
> Some references to LoggingManger#setPriority will have to be removed,
> but there are still some classes, that are like
>
> import org.apache.log.Logger;
> ...
> public class Something extends ConfigTestElement {
>    public static Logger log = LoggingManager.getLoggerForClass();
>    ...
> }
>
> If we change the Logger to a SLF4J implementation we would break the
> implicit serialization format of the class and every client that
> inherits from this class. I don't know, if this OK or not.
>
> If we keep it, we would have to change the generation of the Logger
> (i.e. the call to LoggingManager.getLoggerForClass()) to something, that
> generates an instance of a org.apache.log.Logger that in reality logs to
> SLF4J or log4j2 or ... That is basically what we removed from JMeter :)
>
> We could add that implementation to jmeter-plugins though.

Having tried that a moment ago, I realized, that we include an
org.apache.log.Logger class in JMeter that is different to the one on
avalon-logkit (which is used inside of the maven build by
jmeter-plugins). Our implementation differs in the visibility of the
default constructor and the override-ability of the methods. That means,
we can't simply copy our old Slf4jLogkitLogger into the commons project
of jmeter-plugins.

Felix

>
> The other thing we have to check is, whether that setup would work with
> JMeter 2.13 (as that is targeted by jmeter-plugins, too).
>
> 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/43217ec8086c8f2dc485936cd020c9c8107b698e