Hi,
It's been a long since JMeter 5.2.1, so I guess 5.3 is long overdue.
How about we release JMeter 5.3?
Vladimir
>https://github.com/JCTools/JCTools) instead of Dexx HashMap?
They serve for completely different use cases.
JCTool's map is for concurrent operation (like Java's ConecurrentHashMap).
That is when a map needs to be accessed from multiple threads, and each
thread should see updates that come from
>What do you mean by unsafe ?
Suppose the property in question is TestElement.gui_class
If the code reads it as <>, then the property can't be
modified,
so it is safe to use a shared property instance.
However, if the client code does <> then
we have no idea what will happen next. The code
>Custom scripts can also modify props (I guess you have this in mind, but
>just not to skip it)
That is true. I expect that all calls to "public JMeterProperty
getProperty(String key)" should be treated as unsafe.
Frankly speaking, it would probably be great if we could split
configuration and
>a) Implement copy-on-write like mode for properties.
>For instance, we can add `modifiedPropMap` for the properties that were
modified in the running version.
copy-on-write seems trivial to implement (e.g. replace Map with Dexx
HashMap: https://github.com/andrewoma/dexx ),
however, there's a
Philippe,
Thanks for doing the cleanup. I deliberately refrained from touching
individual components :)
However, can you please clarify what is the value of those one-time
Bugzilla issues?
They do appear in the email notifications, so they produce some noise.
Later the end-users would crawl
+mainPanel.add(createScopePanel(true, true, true),
BorderLayout.NORTH);
+ <-- trailing whitespace
+JPanel panel = new JPanel(new MigLayout("fillx, wrap 2",
"[][fill,grow]"));
Phillippe, just wondering: I guess there's EditorConfig plugin for your IDE
(or a setting to trim
> +conditionPanel.setBorder(BorderFactory.createEtchedBorder()); //
$NON-NLS-1$
Philippe, please remove the etched border.
It adds visual noise for no reason.
I'm inclined that we should forbid the use of
BorderFactory.createEtchedBorder()
Vladimir
Hi,
I've noticed that we have just a few cases when NoThreadClone is used.
It results in enormous memory consumption since the test plan is
effectively duplicated for each and every thread.
Just in case: my testcase is 1 thread group (100'000 threads), 10
transaction controllers (each has one
Philippe>It's really nice, beautiful, clean , it's a big improvement for
JMeter
Philippe>design, thanks for your works Vladimir and Jannis.
Thanks!
Philippe>when you select it or
Philippe>the View Results Tree under it the selected element name is
unreadable.
In my experience, Darklaf has quite
>Is there somewhere we can host them, like netlify or S3, instead of git?
Well, we can try Netlify, however, I'm not sure we are OK within their
limits.
A year ago I've raised https://issues.apache.org/jira/browse/INFRA-18102 for
use of Netlify for documentation preview, and the infra response
Hi,
AFAIK, the version of Groovy we use 2.4.18 does not support Java 14.
Should we upgrade?
There are two options: 2.5.10 (see
http://groovy-lang.org/changelogs/changelog-2.5.10.html ) and 3.0.2 (
http://groovy-lang.org/changelogs/changelog-3.0.2.html )
Does anybody have any preference?
I
>Nice work for a first shot !
Thanks. I think I'll merge it shortly.
So far it looks good to me, and it invalidates the history as the tree
selection is changed.
Frankly speaking, I have no idea on the generic way to associate the fields
to components yet.
In other words, if we want to
Just in case, I've added a workaround to TristateCheckBox so it no longer
fails with NPE.
Vladimir
I've created a draft undo/redo implementation for text fields:
https://github.com/apache/jmeter/pull/576
Of course, it needs special treatment when tree selection changes, however,
even just the very basic ctrl+z
would be way better than nothing.
Any thoughts?
Vladimir
Hi,
We provide a menu option to select Look and Feel.
I'm not sure which of them are used often, however, multiple LaFs come at a
cost.
For example, TCP Sampler UI
uses org.apache.jmeter.gui.util.TristateCheckBox which has multiple hacks
for different LaFs.
TristateCheckBox relies on
>a) when component UI is created, we can scan the component hierarchy, and
add the listeners to all JTextField-like objects in the tree
>I'm inclined to #a because changing all new JTextField with new
JMeterTextField would look like changing 100500 files out of thin air.
It looks like there's yet
Hi,
JMeter heavily relies on the UI, and would probably be nice if we could
have machinery for automated screenshot generation.
I see the following issues with the current screenshots:
1) They are often out of date
2) Image quality is not always good (e.g. LowDPI image does not work for
HiDPI
There might be yet another option.
It might be that Nashorn would be moved to a community-managed library
(e.g. like JavaFx became OpenJFX).
>Is Nashorn or its replacment needed for *all* test plans?
Some of the plans depend on Nashorn, and some of them do not.
Vladimir
>Indeed, undo is only within current active selection.
Ok. I just thought we could start with `undo for edit fields within the
current tree selection`.
In other words, reset all undo history when the test plan element is
re-selected.
I guess we could be able to release that activated by default,
sebb>My point was that the working copy of the test plan is complicated and
fragile
Well, the solution is to add synchronization (e.g. read-write locks) and
forbid non-synchronized access to the model.
That, however, is an orthogonal story.
Vladimir
>Scripting elements like JSR223 and all elements using RSyntaxTextArea
>already support this.
Not quite.
Suppose the following:
1) Create JSR223 Sampler
2) Type "hello" into the script field
3) Switch to Test Plan
4) Switch back to JSR223 Sampler
ctrl+z does nothing. I would expect that history
sebb>For example, even detecting whether the test plan has been changed
I don't see why change detection is needed for undo.
Philippe>Do you think it will be feasible to implement per-element undo/redo
?
Philippe>ok by me anyway to have something in this field
Yet another approach could be
up.
Graal.JS seems to be mature now.
It can run on any Java machine:
https://github.com/graalvm/graaljs/blob/master/docs/user/RunOnJDK.md#run-graalvm-javascript-on-a-stock-jdk
The licenses there are MIT and/or UPL (both are permissible for Apache)
The sad thing is that Graal.JS is ~20 megabytes
Ok, great.
Now's a more tricky question: should we patch all the multiline fields or
should we do it case by case?
For instance: how about JSR223 code editors?
Vladimir
Hi,
Every JMeter component has Name and Comments.
"Comments" is a multi-line field (which is nice for writing comments), but
it does not play well with moving focus via tab and shift+tab.
If you hit `tab` inside Comments field, then you just add a tab character
(like an indentation).
Of course,
Hi,
I see undo was added ~6 years ago, however, it is still disabled by default
:(
The lack of undo can easily be the top priority issue for the users.
>From what I understand, the current implementation is to build a global
history across all test plan elements.
It does not feel right, because
>-Document document = bd.parse(file.getAbsolutePath());
>+Document document = bd.parse(file.toURI().toString());
Felix, is there a reason why bd.parse(file) is not used?
Vladimir
>interpretation of LocalTime addition operations and parsing
Well, the function itself does a lot of time parsing, so I am nowhere sure
if it contains bug or not.
Did you mean the test fails at the specific date only?
However, the concurrent execution of tests that alter timezone is not
Felix> new 1673248 Apply autostyle to make spotbugs happy
1) Technically speaking, this has nothing to do with spotbugs.
2) If you install editorconfig plugin, it would likely insert the final
newline automatically (see insert_final_newline in .editorconfig)
Vladimir
I guess the issue there is the test relies on TimeZone.getDefault(),
however,
there's
org.apache.jmeter.functions.TestDateTimeConvertFunction#testDateTimeConvertEpochTime
which alters the default time zone.
Let's see if something like https://github.com/apache/jmeter/pull/560 can
workaround
>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
>No, that's not exactly what 100% pure Java code means
Pure Java means nothing.
JMeter has lots of Properties, XML, XSLT, CSS, Groovy, BeanShell, and even,
holy cow, JavaScript files.
There's no point in making "100% pure X" without having a good definition
of that.
>The Java code must of
>Huh?
Ok, so you mean Java specification.
In that sense, Darklaf follows the spec, and its code should be compatible
with all Java virtual machines.
Vladimir
>Will JMeter remain 100% pure Java?
Sorry, I don't understand the question.
What do you mean by 100% Java?
>Are there really no standard LAFs that would suit JMeter?
1) Standard LAFs do not look and feel modern
2) No standard LAF has a dark scheme that might work better in the evening.
>JMeter is advertised as being 100% pure Java code.
Darklaf has a native integration feature, however, it is optional.
Currently, JMeter uses Darcula as a default look and feel now,
there are multiple UI bugs in Darcula (e.g. tree indent is hard to see),
Darcula has a single release only,
> * it seems to takes more screen space than the other themes (just a
feeling)
It was a bug in Combobox rendering:
https://github.com/weisJ/darklaf/issues/38
It is fixed.
>* dragable separators are hard to see (on my setup). I can only see the
drag-handles
I guess even the old Darcula renders
>Probably different caches?
I'm not sure, but it looks plausible that .asc resolution failed, and it
was cached somehow.
Can you try dropping the cache and restarting the job (there's UI as well
for that)
Vladimir
Felix, just in case, there's "drop cache" button in the UI:
https://travis-ci.org/apache/jmeter/caches
Vladimir
>Does it silently default if it fails to bind to dll or does it break ?
No idea.
The full thing works in my macOS. It might work as well if excluding jna
dependency, however I have not tried that.
Vladimir
>Just wondering, why does it rely on jna ?
I guess it is for
https://github.com/weisJ/darklaf/wiki/Features#native-window-decorations
(which is Windows-only for now)
Vladimir
>But the glitches for now seem blocking no ?
Well, checkbox/radio glitch is already fixed (~3-4 hours time from issue to
resolution), so the author is quite open with fixing issues, and they do
publish the library to Central.
The key issue left is license clearance + fixing minor issues.
In my
>Yes, it is looking really nice.
OK. I've tried it, and it seems to work, however, there are glitches :(
The most interesting bit is jxlayer-3.0.4.jar dependency.
AFAIK the library was initiated at http://swinglabs.org/ which is no longer
available.
The jar file does not bundle the license text.
Hi,
It looks interesting: https://github.com/weisJ/darklaf/wiki/Features
Vladimir
Just in case:
https://github.com/vlsi/jmeter/runs/411635373 (both macOS and Windows jobs
failed because of redirection policies)
https://github.com/apache/jmeter/pull/553/checks?check_run_id=411635502 the
same thing
The same thing for ALL Travis jobs:
>Is there a better way to test the same functionality?
The tests should not connect to external servers unless the server is known
to be stable.
For now, we have multiple tests that access external systems, and they fail
quite often.
Vladimir
Hi,
I see that batchTestRedirectionPolicies fails too often (more than 50% of
the times?) which is sad.
I'm inclined to disable the test.
Any thoughts?
Vladimir
Hi,
I intend to replace Spotless with Autostyle (
https://github.com/autostyle/autostyle) in our build.
The net result will be the license headers will be more consistent, and the
style violation messages will be easier to understand.
For instance, Autostyle is capable of automatic license
>more connections on the
client, which can be a sparse resource.
It does not typically exceed the number of threads, so users would expect
that.
The problem with the current default is it makes the false sense of
enabling keep-alive in UI.
The users might think that they activate KA, but it is
Philippe>dataSource.setEnableAutoCommitOnReturn(isAutocommit());
What do you think of adding a checkbox like "rollback on returning
connections to the pool"?
Dmitry>I've created issue. Currently I can't find solution for that without
Dmitry>changing source code :(
I guess it would make sense to
>Here is the example jmx file
It looks like the attachment was cut :(
https://lists.apache.org/thread.html/651e4cd6d9bebabc1a70766d01b2030c3e72ecdcd83d1c513558f99a%40%3Cdev.jmeter.apache.org%3E
Vladimir
Dmitry>I'm facing problem while I'm testing Derby DB - when 2 connection
used
Dmitry>(first with autoCommit=true and other with autoCommit=false)
exception
Dmitry>occurs while switching between this 2 connections inside test.
Can you please provide a minimal reproducible example (e.g. jmx file)?
Hi,
JMeter defaults to 2 seconds timeout for keep-alive HTTP connections, which
seems to be much less than the typical browser configuration.
https://en.wikipedia.org/wiki/HTTP_persistent_connection#Use_in_web_browsers
,
https://fastmail.blog/2011/06/28/http-keep-alive-connection-timeouts/
>About new feature of auto-correlation, we prepared specification written
as manual.
That is great. It really helps to preview the feature.
However, I fail to understand what is "correlation with JMX file".
I see it consumes an extra JMX file, but it is not clear what should be
there in the
Thanks,
+1
Artifacts look good, jks is not included to the binary archives.
Vladimir
>it's will be better to clean the distributions directory before
>put the archives to avoid issues?
Extra files do not bother me, and I even compare them sometimes.
The contents of src/dist/build/distributions is never scanned for the list
of files to publish,
and I see no reason to clean it
I guess it is up to RM, but I do not think those are significant issues.
It takes too much time to vote/announce, so redoing RC for minor issues
seems to be a waste of time.
Vladimis
>it could be moved to a test resources directory instead
I agree. We should refrain from mixing production code with testing code in
the same folder.
Vladimir
>It's also in the source release and in the Git repo, so I assume it is
>supposed to be there.
That depends. It might be in the source repo for testing purposes only.
So I would suggest we keep it in the source distribution (otherwise source
build would fail), and we exclude the file from the
Just a side note: the release step (gw publishDist) is known to fail if SVN
1.9 is used (see https://issues.apache.org/jira/browse/SVN-4666 ,
https://github.com/vlsi/asflike-release-environment/issues/1)
I guess Milamber is using a newer version (since the previous release
succeeded),
however, I
>The fourth release candidate for JMeter 5.2.1
Thank you
+1: I verified checksums, signatures, build, tests, pom files
JMeter from binary distribution starts.
--- script
VER=5.2.1
RC=4
svn checkout
https://dist.apache.org/repos/dist/dev/jmeter/apache-jmeter-$VER-rc$RC
cd apache-jmeter-$VER-rc4
Thanks,
The vote passes with +4: Vladimir, Philippe, Felix, Antonio.
Vladimir
Hi,
We are using GitHub pages for 'site preview' during release.
In https://issues.apache.org/jira/browse/INFRA-19395 I asked to create
robots.txt to disallow indexing of the preview site (
https://apache.github.io/jmeter-site/... )
It turns out we can have a CNAME (see INFRA-19395), so
Milamber, would you please retry creating RC?
Vladimir
>+The [RC NUMBER] release candidate
What do you mean by [RC NUMBER] ?
Could you just use $rc variable instead ?
Vladimir
Ok. I see you've made the screenshot to be much wider (687px -> 1055px):
https://github.com/apache/jmeter/commit/79bda1b4ea1eb9494811ca0c166ccca85bebf818?short_path=10973a0#diff-10973a05c7bd6dbecfcee858f78121b1
Does it help readability? I doubt so.
So, would we please enable force-push and
>Bin 26380 -> 37115 bytes
Philippe, have you compressed the image?
It is yet another reason to enable force-push.
If a big file suddenly committed, it would be hard to get rid of it.
Vladimir
>I will try to do a RC2 of v5.2.1 tonight
My bad. The latest snapshot (gradle-6.0.1-20191114002542+-all.zip) does
not include the fix yet.
So let's try tomorrow.
Vladimir
It seems rather restrictive that repository.apache.org is not ready for
sha256 in 2019.
Vladimir
>Are we sure it will be available in 1 week ?
Please have a look over the recent patch releases:
https://gradle.org/releases/
They were quite prompt.
For instance: Gradle 5.2 (Feb 04), 5.2.1 (Feb 08).
We are not voting that fast yet :-/
If it does not appear in a week, we can revert to 5.6.
Update: it turned out repository.apache.org is not yet ready for storing
sha256 and sha512 checksums.
Gradle 6.0 publishes sha256 and sha512, however, Nexus is not ready yet.
The relevant issue is https://issues.apache.org/jira/browse/INFRA-14923
Gradle issue is
>That’s what is done with maven when you want to force a newer version than
the one embedded by dependency
Remember there are frameworks and there are libraries.
binary distribution of JMeter is a framework: it enforces you to put jars
into relevant places, and start with ./jmeter.
On the other
>Done.
Why add asm?
We do not use it => it should not be added.
Vladimir
If Milamber has not yet started rc1, then we could add it.
Otherwise, I do not think it is a notable issue for stopping the release.
Vladimir
>+
Ah. Need to get rid of this.
Vladimir
Looks good to me.
Milamber, would you please create a rc?
Vladimir
>Following discovery of issue on pom, can we release a 5.2.1 ?
+1
Vladimir
>Where ?
https://github.com/apache/jmeter/blob/2cfdec9d50ddab4649b813c07724588a03371ef4/src/protocol/build.gradle.kts#L86
Vladimir
>1/ I reverted the ones that indeed look wrong.
Thanks
>2/ But I kept dec which is needed for http.
Do you mean org.brotli:dec ? It was there.
Vladimir
> For com.miglayout:miglayout-swing , isn't it missing ?
It is declared in "core":
https://github.com/apache/jmeter/blob/b0448c8cb3b70e7c3c58f84af926d0071a091f78/src/core/build.gradle.kts#L74
>- Is scope runtime in the poms correct ?
It is
Vladimir
>No, it's one of my concern but that's not what drives my commit.
>The Pom are wrong and I am trying to fix it.
That is fine. However, this time the fix is wrong, so I suggest to step
back and revert it.
>Can you explain instead of requesting revert ?
Simple explanation: Gradle builds the code,
>So the commit is not incorrect.
Please revert.
I'm 100% sure the commit is incorrect.
It seems you are driven by "the failure of jmeter-maven-plugin".
However, the failure is caused by j-m-p itself, and adding unused
dependencies to JMeter is not the right way to workaround j-m-p issue.
>implementation("xpp3:xpp3_min")
>Used by core for persisting
This is very simple to check.
xpp3_min-1.1.4c.jar jar contains only org/xmlpull/... classes.
$ git grep xmlpull
checksum.xml:
gradle.properties:xmlpull.version=1.1.3.1
lib/aareadme.txt:xmlpull-1.1.3.1
The ones that you've just added:
+implementation("com.miglayout:miglayout-core")
+implementation("com.miglayout:miglayout-swing")
+implementation("org.ow2.asm:asm")
+implementation("xalan:serializer:xalan")
+implementation("xmlpull:xmlpull")
+implementation("xpp3:xpp3_min")
>Fix dependencies for pom generation and remove version
Why are the dependencies added?
They are not used by JMeter.
Vladimir
>I thought running from there would generate for all projects
Of course, it would.
$ gw clean
$ find . -name 'pom*.xml' | wc -l
0
$ gw generatePom -m
...
:generatePom SKIPPED
:src:components:generatePomFileForComponentsPublication SKIPPED
:src:components:generatePom SKIPPED
Vladimir>The current error
Just to clarify: I believe
https://github.com/apache/jmeter/commit/ef06709a780bc776ecc3b5d839c424d39bb1aeae
fixes
the poms,
and the current jmeter/master is ok.
Vladimir
Philippe>But I see nothing in build/publications
Are you sure?
$ cd src/core
$ gw generatePom
$ grep -B 3 -A 3 jorphan build/publications/core/pom-default.xml
org.apache.jmeter
jorphan
5.2.1-SNAPSHOT
Vladimir
Mark>Secondly we don’t use any local files, we pull binaries directly down
from maven central using aether
Mark>currently the plugin wouldn’t use them anyway
Here you go:
https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/pull/345
The current error is "An error occurred:
Up. Any thoughts?
This could have been prevented if force-push was enabled:
https://github.com/apache/jmeter/commit/04aab12c68af8c57258c5ae905bd8b7ab0a2dd9f
Vladimir
+text("templates.xml")
+text("*.jmx")
Those files were not here.
Are they required?
What is the test case for the jar?
Vladimir
I've added removeStaleArtifacts which is automatically run after publishing
the release to /release/jmeter/...
The task can be called manually:
$ gw removeStaleArtifacts -PasfDryRun -Pjmeter.version=5.2 # keep 5.2
artifacts, and print the files to be removed
$ gw removeStaleArtifacts -Pasf
I reached out to jmeter-maven-plugin 3 month ago, and they did not seem to
care: https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/issues/339
Vladimir
>With the new build script, there is a Gradle task to do this ?
It is not there yet.
>Note: I use the (old) ant script to remove the v5.1.1 from the release site
https://dist.apache.org/repos/dist/dev/jmeter/ still contains old files.
Should they be removed after the release as well?
Should
Milamber>PS @vladimir can you fix this on the release plugin?
The folder is configured in JMeter sources:
https://github.com/apache/jmeter/blob/7fa6e9233b499c9a0c079c395a855331daccc8d5/build.gradle.kts#L126-L130
Vladimir
>issue: the generated email have twice "*apache-jmeter-5.2.xxx" on each
> line.
It is fixed now (~
https://github.com/vlsi/vlsi-release-plugins/commit/19e2a6e8330d3d10f80e7fed6503443362f69c07#
)
Vladimir
>source is singular because there is generally only one version of
> source for OSes.
I would suggest to update the download script accordingly because we have
tgz and zip flavours of the sources.
Plus we might happen to have multiple versions in the sources folder.
Vladimir
Many thanks to everybody involved.
Vladimir
sebb>I think the test harness is broken in this regard, and ought to be
fixed.
Ok. What do you typically do when an open-source project is broken or when
it is missing a feature?
sebb>It may still occur.
The probability is extremely low, so it does not matter if it can occur or
not.
Vladimir>
sebb>So is there a way to fix this so the line number *is* shown?
For instance: avoid extending test methods and use delegation instead of
inheritance.
sebb>Such an error is likely to occur again elsewhere
Why do you think so?
There are no more than 5 such cases (I would say 1-2, but 5 is very
201 - 300 of 839 matches
Mail list logo
