Re: [VOTE] Release JMeter 5.5 RC1

[UBIK LOAD PACK Support]

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


-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: [VOTE] Release JMeter 5.4 RC2

[UBIK LOAD PACK Support]

Hello,
Thanks for the RM !

[X] +1  I support this release


Philippe (binding)
Regards

On Sun, Nov 29, 2020 at 7:27 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

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


-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: Release a new version 5.3.1 ?

[UBIK LOAD PACK Support]

Hello,
How about releasing a 5.3.1 or 5.4 ?

I think we now have a stable version and it seems urgent to me to release
it.
Regards

On Sun, Aug 30, 2020 at 12:48 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 29.08.20 um 21:53 schrieb UBIK LOAD PACK Support:
> > On Thu, Aug 27, 2020 at 4:41 PM Felix Schumacher <
> > felix.schumac...@internetallee.de> wrote:
> >
> >>
> >> Am 27. August 2020 15:53:31 MESZ schrieb Philippe Mouawad <
> >> philippe.moua...@gmail.com>:
> >>> Hello,
> >>> Oups previous mail was sent too fast.
> >>>
> >>> I hope you're all fine and have spent  nice holidays if you did.
> >>>
> >>> I think we are ready for a release right ?
> >>> Pending issues are:
> >>> - https://github.com/apache/jmeter/pull/608 for bug 64553
> >
> >>> - https://bz.apache.org/bugzilla/show_bug.cgi?id=64624 which has a
> >>> patch
> >> >from Felix waiting for confirmation
> >>
> >> Here it would be nice, if you could have a look at it, as you did the
> >> original implementation, if I recall correctly.
> >>
> > I had a look, and left a comment on bugzilla, it LGTM.
>
> Committed
>
>
> >
> >
> >> Another pr (#595) that could probably be merged is the one about
> freestyle
> >> naming for samples recorded by the proxy.
> >>
> > Same for me, LGTM
>
> Committed
>
> Especially MacOS users should have a look at the refactored UI elements,
> as I changed a few lines, that had a reference to a UI bug, that was
> visible on MacOS, only.
>
> Felix
>
> >
> >> And what about #593?
> >>
> > ok by me
> >
> >>> Since 5.3 has some regressions, it would be nice to release a version
> >>> soon.
> >> +1
> >>
> >> Felix
> >>
> >>> Thanks
> >
>


-- 

Regards
Ubik Load Pack <http://ubikloadpack.com> Team
Follow us on Twitter <http://twitter.com/ubikloadpack>


Cordialement
L'équipe Ubik Load Pack <http://ubikloadpack.com>
Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>

Re: Release a new version 5.3.1 ?

[UBIK LOAD PACK Support]

On Thu, Aug 27, 2020 at 4:41 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
>
> Am 27. August 2020 15:53:31 MESZ schrieb Philippe Mouawad <
> philippe.moua...@gmail.com>:
> >Hello,
> >Oups previous mail was sent too fast.
> >
> >I hope you're all fine and have spent  nice holidays if you did.
> >
> >I think we are ready for a release right ?
> >Pending issues are:
> >- https://github.com/apache/jmeter/pull/608 for bug 64553
>


> >- https://bz.apache.org/bugzilla/show_bug.cgi?id=64624 which has a
> >patch
> >from Felix waiting for confirmation
>
> Here it would be nice, if you could have a look at it, as you did the
> original implementation, if I recall correctly.
>
I had a look, and left a comment on bugzilla, it LGTM.


> Another pr (#595) that could probably be merged is the one about freestyle
> naming for samples recorded by the proxy.
>
Same for me, LGTM

>
> And what about #593?
>
ok by me

>
> >
> >Since 5.3 has some regressions, it would be nice to release a version
> >soon.
>
> +1
>
> Felix
>
> >Thanks
>


-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: [jmeter] branch master updated: Bug 64638 - JSON JMESPath Assertion / JSON Assertion: Opening GUI shows a horizontal scrollbar that keeps sliding

[UBIK LOAD PACK Support]

Hello Felix,
I must reckon I had not checked with other LAFs.
I suspected it was due to JTextArea not being in JScrollPane.
I wanted to migrate it to miglayout anyway, so I did that.

I'll report the issue to the Darklaf project.
Thanks for noticing.

Regards


On Sun, Aug 2, 2020 at 7:14 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

> Do you know, why this happened? I saw this with Darklaf, only.
>
> Regards
>  Felix
>
> Am 2. August 2020 19:10:25 MESZ schrieb pmoua...@apache.org:
> >This is an automated email from the ASF dual-hosted git repository.
> >
> >pmouawad pushed a commit to branch master
> >in repository https://gitbox.apache.org/repos/asf/jmeter.git
> >
> >
> >The following commit(s) were added to refs/heads/master by this push:
> >new c037ee5  Bug 64638 - JSON JMESPath Assertion / JSON Assertion:
> >Opening GUI shows a horizontal scrollbar that keeps sliding
> >c037ee5 is described below
> >
> >commit c037ee577a03a895de1b5e0163b34db01e6eb4ac
> >Author: pmouawad 
> >AuthorDate: Sun Aug 2 19:09:41 2020 +0200
> >
> >Bug 64638 - JSON JMESPath Assertion / JSON Assertion: Opening GUI shows
> >a horizontal scrollbar that keeps sliding
> >
> >
> >Fix issue and rework UI
> >---
> >.../assertions/gui/JSONPathAssertionGui.java   | 63
> >+-
> >.../jmespath/gui/JMESPathAssertionGui.java | 43 +++
> > xdocs/changes.xml  |  1 +
> > 3 files changed, 71 insertions(+), 36 deletions(-)
> >
> >diff --git
>
> >a/src/components/src/main/java/org/apache/jmeter/assertions/gui/JSONPathAssertionGui.java
>
> >b/src/components/src/main/java/org/apache/jmeter/assertions/gui/JSONPathAssertionGui.java
> >index e3b0b3e..3c9efeb 100644
> >---
>
> >a/src/components/src/main/java/org/apache/jmeter/assertions/gui/JSONPathAssertionGui.java
> >+++
>
> >b/src/components/src/main/java/org/apache/jmeter/assertions/gui/JSONPathAssertionGui.java
> >@@ -19,19 +19,21 @@ package org.apache.jmeter.assertions.gui;
> >
> > import java.awt.BorderLayout;
> >
> >-import javax.swing.BorderFactory;
> > import javax.swing.JCheckBox;
> >+import javax.swing.JPanel;
> >+import javax.swing.JTextField;
> > import javax.swing.event.ChangeEvent;
> > import javax.swing.event.ChangeListener;
> >
> > import org.apache.jmeter.assertions.JSONPathAssertion;
> > import org.apache.jmeter.gui.GUIMenuSortOrder;
> > import org.apache.jmeter.gui.TestElementMetadata;
> >-import org.apache.jmeter.gui.util.VerticalPanel;
> >+import org.apache.jmeter.gui.util.JSyntaxTextArea;
> >+import org.apache.jmeter.gui.util.JTextScrollPane;
> > import org.apache.jmeter.testelement.TestElement;
> > import org.apache.jmeter.util.JMeterUtils;
> >-import org.apache.jorphan.gui.JLabeledTextArea;
> >-import org.apache.jorphan.gui.JLabeledTextField;
> >+
> >+import net.miginfocom.swing.MigLayout;
> >
> > /**
> >* Java class representing GUI for the {@link JSONPathAssertion}
> >component in JMeter
> >@@ -50,8 +52,8 @@ public class JSONPathAssertionGui extends
> >AbstractAssertionGui implements Change
> >private static final String JSON_ASSERTION_INVERT =
> >"json_assertion_invert";
> >private static final String JSON_ASSERTION_TITLE =
> >"json_assertion_title";
> >
> >-protected JLabeledTextField jsonPath = null;
> >-protected JLabeledTextArea jsonValue = null;
> >+protected JTextField jsonPath = null;
> >+protected JSyntaxTextArea jsonValue = null;
> > protected JCheckBox jsonValidation = null;
> > protected JCheckBox expectNull = null;
> > protected JCheckBox invert = null;
> >@@ -66,31 +68,40 @@ public class JSONPathAssertionGui extends
> >AbstractAssertionGui implements Change
> > setBorder(makeBorder());
> > add(makeTitlePanel(), BorderLayout.NORTH);
> >
> >-VerticalPanel panel = new VerticalPanel();
> >-panel.setBorder(BorderFactory.createEmptyBorder(5, 0, 5, 0));
> >-
> >-initFields();
> >+JPanel panel = buildPanel();
> >+add(panel, BorderLayout.CENTER);
> >
> > jsonValidation.addChangeListener(this);
> > expectNull.addChangeListener(this);
> >-
> >-panel.add(jsonPath);
> >-panel.add(jsonValidation);
> >-panel.add(isRegex);
> >-panel.add(jsonValue);
> >-panel.add(expectNull);
> >-panel.add(invert);
> >-
> >-add(panel, BorderLayout.CENTER);
> > }
> >
> >-protected void initFields() {
> >-jsonPath =  new
> >JLabeledTextField(JMeterUtils.getResString(JSON_ASSERTION_PATH));
> >-jsonValue = new
> >JLabeledTextArea(JMeterUtils.getResString(JSON_ASSERTION_EXPECTED_VALUE));
> >-jsonValidation = new
> >JCheckBox(JMeterUtils.getResString(JSON_ASSERTION_VALIDATION));
> >-expectNull = new
> >JCheckBox(JMeterUtils.getResString(JSON_ASSERTION_NULL));
> >-invert = new
> >JCheckBox(JMeterUtils.getResString(JSON_ASSERTION_INVERT));
> >-isRegex = new
> 

Re: AutoCorrelation functionality testing website down

[UBIK LOAD PACK Support]

Hello,

You can run it locally :

   - docker run --name challenge --log-driver=none -p 8080:8080 -e
   SECRET_KEY_BASE=allyourbases floodio/challenge


Secret can be whatever you want.


Regards

On Wed, Jul 29, 2020 at 12:54 PM Prajjwal Laad 
wrote:

> Hi all,
>
> This is regarding testing of the auto-correlation functionality.
> We are using the website "https://challengers.flood.io/#about; to create
> load testing scripts.
> The website is down for quite some time now.
> We tried but could not find any information about the state of this
> website anywhere.
> It would be helpful if anyone can share information about the state of the
> website.
>
> Kindly let me know in case more information is required.
>
> Best Regards
> Prajjwal Laad
>
> 
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. It shall not attach any liability
> on the originator or NECTI or its affiliates. Any views or opinions
> presented in this email are solely those of the author and may not
> necessarily reflect the opinions of NECTI or its affiliates. Any form of
> reproduction, dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior written
> consent of the author of this e-mail is strictly prohibited. If you have
> received this email in error please delete it and notify the sender
> immediately.
>


-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: [VOTE] Release JMeter 5.2 RC4

[UBIK LOAD PACK Support]

Hello,

Thanks for RM.
We tested RC4 version. No issue found on our side.

[X] +1  I support this release

-- 

Regards
@ubikloadpack Team

On Fri, Oct 18, 2019 at 12:50 PM Milamber  wrote:

> The fourth release candidate for JMeter 5.2 (26ef2cef53) has been
> prepared, and your votes are solicited.
>
> * This release brings two major changes for the distributed
> version-control system and the building tool:
> - migration from Subversion (svn) to Git repository (compliant with
> GitHub and ASF GitBox)
> - migration from Apache Ant to Gradle build system
>
> This for 2 main objectives:
> * Improve the ease for contributors to make improvements and
> corrections of bugs
> * Allow to have new and more frequent versions of JMeter by
> automating release steps.
>
> Special Thanks for Vladimir Sitnikov (vladimirsitnikov@a.o) for these
> works and supports.
>
> 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.
>
> @PMC and Commiters ==> This is the first release with the new
> process/tool with Gradle and Git repository, so please double check this
> release to find all issue in theses changes in the building and
> releasing mechanisms for JMeter. <==
>
> 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.2-rc4/
> (dist revision 36377)
>
> 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-1056/org/apache/jmeter/
>
> Tag:
> https://gitbox.apache.org/repos/asf?p=jmeter.git;a=tag;h=refs/tags/v5.2-rc4
>
> Keys are here:
> https://www.apache.org/dist/jmeter/KEYS
>
> N.B.
> To create the distribution and test JMeter: "./gradlew build -Prelease
> -PskipSigning".
>
> JMeter 5.2 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:
>
>
> fa68f14e56ac45787befba3a328862715d7b50693fca5e202f7d83b6b3119a5700493837d94c42759ea9ecfc3245b08a289bc5295a68f81157b7c5ef432a62f2
> *apache-jmeter-5.2.tgz
>
> e762fb36b086e94050c66b90ff55ee6a54eb86c0df8b5f109b5ac1c50be461507596badfa95db3ae037a3265f58bad857a2619a801d527d969ce66015f6f6327
> *apache-jmeter-5.2.zip
>
> b6d6e73ecfd5407dd1ffa2df8931459163335d495ddec7559e6d396985ae3d520950fb20bd562678eaf0b00530a5e33f829c5476760196b3b0ef29a584a2a74f
> *apache-jmeter-5.2_src.tgz
>
> 8b47d6c30636941c8f5567c914c23a0e03166f85d91830af2f5949ef5301be5b6429f6dd7445a3ca45e048c3251c8d3c69255afc9ea7c67d879142573a15d47a
> *apache-jmeter-5.2_src.zip
>

Re: Contribute a Dockerfile for JMeter

[UBIK LOAD PACK Support]

Hello Brian,

This docker image is indeed what you describe and is not intended to ease
distributed testing for now.
Note you can very well run distributed testing without using jmeter-server
as remote testing has a serialization/deserialization cost that is not
negligible. Of course you would have to build your own aggregation system
for metrics.

Let's enumerate few use cases (not exhaustive) for the proposed docker
image:

   - Rapid setup of JMeter for scripting
   - Use in a CI/CD system where running docker images is provided OOTB
   (Azure DevOps (
   
https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/docker-compose?view=azure-devops)
   , https://jenkins.io/doc/book/pipeline/docker/)
   - Load testing from a single machine with docker installed, depending on
   configuration you can easily go to 1000 to 5000 Virtual users


What you propose can be a second step, I guess you have approaches like
this in mind:

   -
   
https://eleanordare.com/blog/2017/6/14/using-a-jenkins-pipeline-to-run-jmeter-tests-in-openshift
   -
   
https://blog.kubernauts.io/load-testing-as-a-service-with-jmeter-on-kubernetes-fc5288bb0c8b
   - https://medium.com/@vepo/dockerized-jmeter-84228733e306
   -
   
https://www.testautomationguru.com/jmeter-distributed-load-testing-using-docker/


Of course , feel free to make a PR on our repo or at JMeter one if you have
better ideas.

Regards
On Tue, Oct 15, 2019 at 5:12 PM Brian Wolfe 
wrote:

> After looking more closely at the proposed dockerfile that UBIK has
> proposed. I have some observations.
> It looks like its a simple container that just runs plain jmeter with a
> test case file and logs data to a file.
> From what I can gather this is intended to be run with docker compose as a
> container based process. So basically it is running a standalone jmeter
> instance which generates load for your given test file.
>
> I am not sure this is the best direction. As in order to scale up you would
> have to combine the result files from running many docker processes. This
> is where jmeter server is more useful. You could run this docker image to
> connect to other jmeter-server instances and get your results, but that
> just wraps your jmeter process into a docker container. I don't see much
> benefit to this at the moment.
>
> I think the most useful docker image would be to deploy many jmeter-server
> instances in a kubernetes environment, have some way to connect 1 client to
> them all, and then run your tests.
>
>
> On Mon, Oct 14, 2019 at 11:13 AM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
> > >Is the JMeter project prepared to provide support for any Docker
> > >images and configurations?
> >
> > I suggest we push experimental Docker images, then we decide what needs
> to
> > be adjusted.
> >
> > In other words, we could start with "try JMeter" image that just launches
> > JMeter.
> > Of course, there will be corner cases here and there, however, we would
> > just ignore the "backward compatibility" issues for Docker image,
> > and we could stabilize it for a couple of releases.
> >
> > However, I agree we should at least try to enumerate the use cases for
> the
> > image.
> >
> > Vladimir
> >
>
>
> --
> Thanks,
> Brian Wolfe
> https://www.linkedin.com/in/brian-wolfe-3136425a/
>

Re: Contribute a Dockerfile for JMeter

[UBIK LOAD PACK Support]

Hello Vladimir,

Find answers inline below.

Regards

On Mon, Oct 14, 2019 at 11:46 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Dockerfile can be a part of the official release.
> However, it would be great if you could highlight use-cases for the
> container.
>

I am not sure to fully understand the question, but if the question is why
would somebody need a Docker image for JMeter :

   - Ease of use, as a user I want to run my test easily without having to
   install Java, JMeter before
   - Openshift deployment
   - Kubernetes deployment
   - Integration with Jenkins

Or was your question about something different

Then it would be interesting how plugins should be installed.
>

Not answering the question directly, but if The ASF could officially
distribute a JMeter image, it would be possible for users to create a
DockerFile using JMeter image, but that's another topic.


> Vladimir
>


-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 

Contribute a Dockerfile for JMeter

[UBIK LOAD PACK Support]

Hello,
We'd like to contribute a dockerfile to the project that could help users
generate easily a Docker Image.

Ideally for users, the best thing would be to have a JMeter image here:
https://hub.docker.com/u/apache

But it seems it might be a problem for:

   - security : as you would need to update it frequently
   - licensing: Is a complete image compatible with ASF license
   - we're not sure it's an official Apache profile

So as a first step, proposing a docker file and a readme would be helpful.

We have this repository that you can review for current piece of work:
https://github.com/ubikloadpack/jmeter-docker

We don't know where to do a PR, should it be on jmeter repository or on a
dedicated docker repository

Thanks for your feedback.
-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 

Re: MongoDB driver

[UBIK LOAD PACK Support]

Hello,
I created a branch to remove mongodb.
It still has issues related to loading old plans having it.

I'll stop work on it for now, in case somebody wants to fix it, it's ok by
me.

Regards

On Sun, Oct 6, 2019 at 12:48 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
> Am 04.10.19 um 21:27 schrieb Philippe Mouawad:
> > Hello Vladimir,
> > No the gradle plugin won't solve this.
> > The driver has broken source compatibility.
> >
> > Also we exposed DB object and now it has been replaced by MongoDatabase.
> > The authentication is also different which means we need to rewrite
> nearly
> > everything.
> > And finally, the Mongo elements are not even visible today, so removing
> > them has no impact for me.
> >
> > So let's just remove the code no ?
>
> The driver has been marked deprecated for at least one version of JMeter
> (marked on Dec 27 2015).
>
> It will not work on newer MongoDB versions (at least that is what I
> heard, haven't tried it).
>
> So it is probably time to remove it.
>
> On the other hand, the versioning scheme would require a new major
> version for breaking changes such as dropping a sampler, would not it?
>
> Felix
>
> > Regards
> >
> > On Fri, Oct 4, 2019 at 7:30 PM Vladimir Sitnikov <
> > sitnikov.vladi...@gmail.com> wrote:
> >
> >>> It’s not about size, it’s about quality and « «uptodateness »
> >> This would partially be solved with
> >> https://github.com/ben-manes/gradle-versions-plugin
> >> That is a Gradle plugin that discovers available updates on demand.
> >> What if we upgrade to mongo-java-driver 2.11.3 to 3.11.0?
> >>
> >>> But even with it, we should drop MongoDB
> >> Does it really hurt?
> >> The jar is small. The UI is small. It never fails CI.
> >>
> >> It is not like I use Mongo every day.
> >> I just mean that there might be chicken-and-egg problem: no Mongo
> sampler
> >> -> JMeter users don't even try testing MongoDB (or storing temporary
> data
> >> in MongoDB instead of files).
> >>
> >>> let’s make a POC of it.
> >> After 5.2?
> >>
> >> Vladimir
> >>
> >
>


-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: Use of https://github.com/HdrHistogram/HdrHistogram

[UBIK LOAD PACK Support]

Hello Isuru,
We are currently working on a future PR implementing this.
But feel free to help
Regards

On Thu, Jun 20, 2019 at 11:09 AM Isuru Perera  wrote:

> Hello,
>
> Any update on using HdrHistogram in JMeter?
>
> On Fri, Mar 30, 2018 at 5:12 PM Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
> > Am Freitag, den 30.03.2018, 12:38 +0200 schrieb Philippe Mouawad:
> > > ok for me.
> > > Make your dream become reality :)
> >
> > I have started on inserting the HdrHistogram into StatCalculator, but
> > that is not really possible, as StatCalculator is written as a generic
> > and HdrHistogram (as I have understood it) best with long values.
> >
> > Currently we have two non-generic implementations of StatCalculator.
> > One with Long and one with Integer. The Integer one seems to be used by
> > a test, only.
> >
> > Is the Integer version used somewhere else, that I have overlooked?
> >
> > At the moment I am trying to insert HdrHistogram into
> > StatCalculatorLong and delegate all calls to it. But I believe it would
> > be better to insert HdrHistogram into StatVisualizer and
> > SamplingStatVisualizer, since StatCalculator is public interface and I
> > don't see a way to keep it backward compatible with my current
> > approach.
> >
> > What do you think?
> >
> > Felix
> >
> > >
> > > On Friday, March 30, 2018, Felix Schumacher <
> > > felix.schumac...@internetallee.de> wrote:
> > >
> > > >
> > > > Sorry for the late answer.
> > > >
> > > > As https://bz.apache.org/bugzilla/show_bug.cgi?id=61725 is yet
> > > > another
> > > > report for the same "bug" and HdrHistogram seems to be a good
> > > > compromise on memory, speed and accuracy, I think we should go that
> > > > way.
> > > >
> > > > HdrHistogram is available under BSD clause 2, so it should be safe
> > > > to
> > > > include.
> > > >
> > > > As a side effect I am dreaming of a mini-histogram in the
> > > > visualizer
> > > > for every request line :)
> > > >
> > > > Felix
> > > >
> > > > Am Dienstag, den 21.11.2017, 14:33 +0530 schrieb Isuru Perera:
> > > > >
> > > > > +1 for using HdrHistogram. We found out that the percentiles
> > > > > values
> > > > > shown
> > > > > in "Aggregate Report" and the web dashboard are different for the
> > > > > same JTL
> > > > > file. It will be good if we can use the same logic to calculate
> > > > > percentile
> > > > > values in JMeter listeners and the web dashboard.
> > > > >
> > > > > On Sat, May 20, 2017 at 7:58 PM, Philippe Mouawad <
> > > > > philippe.moua...@gmail.com> wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > Hello,
> > > > > > Any other thoughts ?
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > On Saturday, May 6, 2017, Antonio Gomes Rodrigues  > > > > > .com
> > > > > > >
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > 2017-05-06 15:57 GMT+02:00 Maxime Chassagneux <
> > > > > > > maxime.chassagn...@gmail.com >
> > > > > > > :
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > +1 : lgtm
> > > > > > > >
> > > > > > > > 2017-05-06 15:41 GMT+02:00 Philippe Mouawad <
> > > > > > > p.moua...@ubik-ingenierie.com 
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > :
> > > > > > > > >
> > > > > > > > > Hello,
> > > > > > > > > A user recently reported a bug on StatCalculator class:
> > > > > > > > >
> > > > > > > > >- https://bz.apache.org/bugzilla/show_bug.cgi?id=61071
> > > > > > > > >
> > > > > > > > > It appears issue is not restrained to Median but
> > > > > > > > > concerns  percentile
> > > > > > > > > computing.
> > > > > > > > >
> > > > > > > > > Besides, this class has many drawbacks:
> > > > > > > > >
> > > > > > > > >- It is not tested as much as it should be
> > > > > > > > >- It relies on an algorithm that consumes memory
> > > > > > > > >
> > > > > > > > > We use another class in Web/Dashboard report and
> > > > > > > > > BackendListener
> > > > > > client
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > implementations that relies on commons-math
> > > > > > > > > org.apache.commons.math3.stat.descriptive.DescriptiveStat
> > > > > > > > > isti
> > > > > > > > > cs.
> > > > > > > > >
> > > > > > > > > My proposal is the following:
> > > > > > > > >
> > > > > > > > >- First step : Introduce in StatCalculator,
> > > > > > > > > HdrHistogram
> > > > > > > > >- Second step : Replace DescriptiveStatistics by
> > > > > > > > > HdrHistogram
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Benefits:
> > > > > > > > >
> > > > > > > > >- Uniform computing accross JMeter
> > > > > > > > >- Better performances
> > > > > > > > >
> > > > > > > > > Are you ok with this approach ?
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > > --
> > > > > > > > > Regards.
> > > > > > > > > Philippe Mouawad.
> > > > > > > > > Ubik-Ingénierie
> > > > > > > > >
> > > > 

Re: Build failed in Jenkins: JMeter Ubuntu #698

[UBIK LOAD PACK Support]

Hello,
I created this:
https://issues.apache.org/jira/browse/INFRA-17910

Regards

On Mon, Feb 25, 2019 at 5:11 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://builds.apache.org/job/JMeter%20Ubuntu/698/display/redirect?page=changes
> >
>
> Changes:
>
> [pmouawad] Bug 63207 - java.lang.NullPointerException: null when run
> Jmeter 5.1 with proxy options
> Bugzilla Id: 63207
>
> --
> [...truncated 131.14 KB...]
>
> compile:
>
> prepare-resources:
>  [copy] Copying 3 files to <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/build/res/META-INF>
>
> package-only:
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/bin/ApacheJMeter.jar
> >
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/ext/ApacheJMeter_core.jar
> >
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/ext/ApacheJMeter_components.jar
> >
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/ext/ApacheJMeter_functions.jar
> >
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/ext/ApacheJMeter_http.jar
> >
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/ext/ApacheJMeter_ftp.jar
> >
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/ext/ApacheJMeter_jdbc.jar
> >
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/ext/ApacheJMeter_java.jar
> >
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/bshclient.jar>
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/ext/ApacheJMeter_junit.jar
> >
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/junit/test.jar>
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/ext/ApacheJMeter_ldap.jar
> >
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/ext/ApacheJMeter_mail.jar
> >
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/ext/ApacheJMeter_tcp.jar
> >
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/ext/ApacheJMeter_jms.jar
> >
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/ext/ApacheJMeter_native.jar
> >
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/ext/ApacheJMeter_mongodb.jar
> >
>   [jar] Building jar: <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/lib/jorphan.jar>
>
> package:
>
> _check_3rdparty:
>
> _message_3rdParty:
>
> init-version:
>  [echo] jmeter.version = 5.1-SNAPSHOT
>  [echo] display.version = 5.1-SNAPSHOT r1854317
>  [echo] implementation.version = 5.1-SNAPSHOT r1854317
>
> compile-jorphan:
>
> compile-core:
>
> compile-components:
>
> compile-functions:
>
> compile-http:
>
> compile-ftp:
>
> compile-jdbc:
>
> compile-java:
>
> compile-ldap:
>
> create-mail-dir:
>
> compile-mail:
>
> compile-tcp:
>
> compile-protocols:
>
> compile-junit:
>
> compile-jms:
>
> compile-native:
>
> compile-mongodb:
>
> compile:
>
> compile-tests:
> [javac] Compiling 195 source files to <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/build/test>
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
>   [groovyc] Compiling 25 source files to <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/build/test>
>   [groovyc] <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/test/src/org/apache/jmeter/assertions/MD5HexAssertionSpec.groovy
> >
>   [groovyc] <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/test/src/org/apache/jmeter/assertions/gui/AssertionGuiSpec.groovy
> >
>   [groovyc] <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/test/src/org/apache/jmeter/control/RandomOrderControllerSpec.groovy
> >
>   [groovyc] <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/test/src/org/apache/jmeter/control/RunTimeSpec.groovy
> >
>   [groovyc] <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/test/src/org/apache/jmeter/control/ThroughputControllerSpec.groovy
> >
>   [groovyc] <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/test/src/org/apache/jmeter/engine/util/PackageSpec.groovy
> >
>   [groovyc] <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/test/src/org/apache/jmeter/extractor/BoundaryExtractorSpec.groovy
> >
>   [groovyc] <
> https://builds.apache.org/job/JMeter%20Ubuntu/ws/trunk/test/src/org/apache/jmeter/extractor/JoddExtractorSpec.groovy
> >
>   [groovyc] <
> 

Re: Issue 63130 and 63129

[UBIK LOAD PACK Support]

Hello,
Thanks for analyzing and contributing.
Those modifications are critical, could you provide JUnit tests for them
covering Shift_JIS, UTF-8, US-ASCII and CP1252 ?
I don't see any test.

Thank you
Regards

On Fri, Feb 22, 2019 at 4:18 AM Sanjay Chaurasia <
sanjay.chaura...@india.nec.com> wrote:

> Dear Philippe and Felix
>
>
>
> Please find details of created bugs and PRs respectively and kindly let me
> know if any further information is required for the same as our team is
> dedicatedly working on this.
>
>
>
> Bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=63130 ( PR :
> https://github.com/apache/jmeter/pull/440 )
>
> Bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=63129  (PR:
> https://github.com/apache/jmeter/pull/441 )
>
>
> Regards,
> Sanjay Chaurasia
>
>

-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Fwd: View Results Tree: Drop browser renderer

[UBIK LOAD PACK Support]

For information, as I think message was for mailing list.

Regards

-- Forwarded message -
From: Milamber 
Date: Fri, Oct 5, 2018 at 8:19 AM
Subject: Re: View Results Tree: Drop browser renderer
To: UBIK LOAD PACK Support 


Hello,

I'm agree to suppress this renderer. It's not very useful, bad rendering
and too slow.

Milamber

On 26/09/2018 08:55, UBIK LOAD PACK Support wrote:
> Hello,
> Isn't it time to drop Browser component and dependency on Java FX in next
> version ?:
>
> - It is not available in OpenJDK which should become the most used
JVM ?
> It currently trigger an ugly stacktrace
> - It introduces complexity and did not offer that much interest as
> initially expected
>
>
> Regards
>
> On Thu, Apr 12, 2018 at 8:10 PM Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
>> Am 07.04.2018 um 09:14 schrieb Philippe Mouawad:
>>> Hello,
>>> In jdk11, oracle will split javafx and javase.
>>> This component uses javafx, I initially thought it would be a better
>>> renderer but due to security limitations on resources download, it ended
>> up
>>> much less useful and rendering is always partial.
>>>
>>> So I propose to drop it in next 4.1 .
>> Is there any chance to bypass the limitations on resource download? I
>> found the rendering to be a bit better than the built-in "browser", but
>> there is certainly a lot of room for improvement.
>>
>> Felix
>>
>>> Throughts?
>>> Regards
>>>
>>>
>>



-- 

Regards
Ubik Load Pack <http://ubikloadpack.com> Team
Follow us on Twitter <http://twitter.com/ubikloadpack>


Cordialement
L'équipe Ubik Load Pack <http://ubikloadpack.com>
Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>

Re: View Results Tree: Drop browser renderer

[UBIK LOAD PACK Support]

Hello,
Isn't it time to drop Browser component and dependency on Java FX in next
version ?:

   - It is not available in OpenJDK which should become the most used JVM ?
   It currently trigger an ugly stacktrace
   - It introduces complexity and did not offer that much interest as
   initially expected


Regards

On Thu, Apr 12, 2018 at 8:10 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

> Am 07.04.2018 um 09:14 schrieb Philippe Mouawad:
> > Hello,
> > In jdk11, oracle will split javafx and javase.
> > This component uses javafx, I initially thought it would be a better
> > renderer but due to security limitations on resources download, it ended
> up
> > much less useful and rendering is always partial.
> >
> > So I propose to drop it in next 4.1 .
> Is there any chance to bypass the limitations on resource download? I
> found the rendering to be a bit better than the built-in "browser", but
> there is certainly a lot of room for improvement.
>
> Felix
>
> > Throughts?
> > Regards
> >
> >
>
>

-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: CSS/JQuery Extractor

[UBIK LOAD PACK Support]

Hello,
Currently majority of Extractors are based on syntax:

   - XPath,
   - Regex,
   - Boundary,
   - CSS / JQuery


Only JSON is based on format, but I remember it was due to JSON Path
already being used.

I think the issue with CSS/ JQuery is that name is maybe not clear to
testers. Should it be CSS Selector extractor ?
And should we by the way name JSON Extractor => JSON Path Extractor ?

Regards


On Thu, Aug 2, 2018 at 10:05 AM, Andrey Pokhilko  wrote:

> HTML Extractor is also very generic name.
>
> Let's understand which naming tradition do we use consistently for
> extractors - is it "by syntax used" or "by what it extracts"? Otherwise
> users will be confused when use HTML Extractor and when Boundary
> Extractor...
>
> I am for "by syntax used" since this is a tradition we have up to now
> and it is less ambiguous.
>
> --
>
> Andrey Pokhilko
>
> 02.08.2018 11:01, Jmeter Tea пишет:
> > Regex Extractor is more generic, it can extract from any text (JSON,
> plain,
> > XML, )
> >
> > On Thu, Aug 2, 2018 at 10:57 AM, Andrey Pokhilko  wrote:
> >
> >> Hi,
> >>
> >> IMO name is fine, since it reflects the syntax. Regex Extractor also
> >> extracts from HTML, XPath Extractor also extracts from HTML.
> >>
> >> --
> >>
> >> Andrey Pokhilko
> >>
> >> 02.08.2018 08:51, Jmeter Tea пишет:
> >>> It seems that CSS/JQuery Extractor name is a bit confusing,
> >>> Because it actually used to extract *HTML *using CSS/JQuery syntax
> >>> Isn't it better to rename it to HTML Extractor or HTML DOM Extractor ?
> >>>
> >>> Relevant question:
> >>> https://stackoverflow.com/questions/51644320/jmeter-how-
> >> to-use-the-jquery-not-css-extractor/51646040#51646040
> >>
>
>


-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

New XPath Extractor element supporting XPath 2 / Bug 60991

[UBIK LOAD PACK Support]

Hello,

UbikLoadPack Team is happy to contribute the enhancement desribed to Apache
JMeter developed by Thomas, Anthony and Philippe and sponsored by
Ubik-Ingenierie:

- https://bz.apache.org/bugzilla/show_bug.cgi?id=60991

Here are the enhancements:

- XPath 2 is now supported relying on SAXON9-HE under MPL 2 license
- A new element has been created to avoid any backward compatibility
constraint and to allow cleanup of code
- A new View Results Tree Renderer XPath2 Tester has been also implemented
- Performances of this component should be significantly faster than old
one as XPath Expression are now compiled and cached


We are happy to donate this code to Apache JMeter as we have already
donated other piece of code in the past under our signed CCLA.

Regards
UbikLoadPack Team
@ubikloadpack
https://ubikloadpack.com

BUG 61748 / Request compression

[UBIK LOAD PACK Support]

Hello,
In some applications, the request body needs to be gzipped.

It is currently possible to do it by developping a JSR223 PreProcessor but
it requires some development knowledge.

We would like to contribute a patch to provide this but have some questions
on what best options would be:

   - Option 1 :Should it be automatic, ie, whenever a Header
   Content-Encoding=gzip , we do it:
  - Easy
  - To disable it, remove Content-Encoding header
  - Is there a case where it would be annoying ?
  - We would add a property to disable registration of this Interceptor
  to disable globally the feature if really needed
  - Option 2 :Should it be activated by a checkbox in HTTP Request
   Advanced Tab ?
  - Yet Another option in a complex UI ?
  - Option 3 : Should it be a PreProcessor ?:
  - More flexible
  - but  requires insertions in many places


Unless there is a case we would go for Option 1.

Any thoughts ?


Thanks
Regards
UbikLoadPack Team

TestAction: Change its name to make it more meaningful

[UBIK LOAD PACK Support]

Hello,

TestAction in JMeter is a very useful element but its name is misleading or
not clear at all.

Currently it allows:

   - Pausing
   - Stopping Test
   - Stopping Test immediately
   - Switching to next thread loop iteration
   - We'll soon propose a patch to add:
  - Switch to next iteration of current loop : : It will be equivalent
  of "continue" in the the first parent loop that contains it
  - Break current loop : It will break the first parent loop that
  contains it, equivalent of "break" in algorithm


When we provide training or discuss with JMeter beginners, TestAction is
usually understood as something to debug or "test", and nobody thinks that
is allows all this.

Shouldn't it be renamed to something like:

   - Test Logic Action
   - Logical Action
   - Test Logical Action
   - Test Execution Modifier



Regards
UbikLoadPack Support Team

[VOTE] Release JMeter 4.0 RC7

[UBIK LOAD PACK Support]

Hello ,
Thanks Milamber for your work on RM and all team for this release.

[+1] We support this release

Tested successfully on Windows / Java 8 and 3rd party plugins.


Regards
@UbikLoadPack Team


On Wed, Feb 7, 2018 at 8:53 AM, Milamber  wrote:

> Hello,
>
> The seventh release candidate for JMeter 4.0 (r1823414) has been prepared,
> and your votes are solicited.
>
> This release brings a new default theme (Darcula), support for Java 9, 74
> enhancements (new features and improvements), and 26 bug fixes.
>
> Please, test this release candidate (with load tests and/or functional
> tests) using Java 8 or 9 on Linux/Windows/Mac OS, 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:
> http://home.apache.org/~milamber/jmeter-4.0RC7/docs/changes.html
>
> JMeter is a Java desktop application designed to load test functional
> behavior and measure performance. The current version targets Java 8 / 9.
>
> Download - Archives/hashes/sigs:
>
> https://dist.apache.org/repos/dist/dev/jmeter/v4.0_RC7/
> (dist revision r24781)
>
> RAT report:
>
> http://home.apache.org/~milamber/jmeter-4.0RC7/dist/rat-repo
> rt-jmeter-4.0RC7.txt
>
> MD5 hashes of archives for this vote:
>
> bfd202f5eb8a0ac322a145b97ef3fded *apache-jmeter-4.0.tgz
> 3a84491f10fb7b147101cf3926c4a855 *apache-jmeter-4.0.zip
> 7b3ed61896d704f3307d800616272393 *apache-jmeter-4.0_src.tgz
> 2f8d4260f125925eacce1069b295f53c *apache-jmeter-4.0_src.zip
>
> Site Docs are here:
> http://home.apache.org/~milamber/jmeter-4.0RC7/docs/
>
> Maven staging repository is accessible here:
> https://repository.apache.org/content/repositories/orgapache
> jmeter-1028/org/apache/jmeter/
>
> Tag:
> https://svn.apache.org/repos/asf/jmeter/tags/v4_0_RC7/
>
> Keys are here:
> https://www.apache.org/dist/jmeter/KEYS
>
> N.B.
> To download the dependencies: "ant download_jars"
>
> To create the jars and test JMeter: "ant package test".
>
> JMeter 4.0 requires Java 8 or later to run.
>
> Some known issues and incompatible changes are listed on changes page.
> http://home.apache.org/~milamber/jmeter-4.0RC7/docs/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
>
> *Note:* the RC1, RC2 and RC3 were not submit for vote due an issue in
> release process when the maven artefacts are upload to nexus. For this RC7,
> the automatic maven upload inside build.xml was replaced by a
> semi-automatic upload with the maven-gpg-plugin.
>
> *Note2:* the RC5 were not submit for vote due an little commit by Philippe
> :-) during the release process.
>
>
>
>
>
>


--

Re: Validate Functionality

[UBIK LOAD PACK Support]

Hi Graham,
My answers below.
Regards

On Fri, Nov 10, 2017 at 6:27 PM, Graham Russell <gra...@ham1.co.uk> wrote:

> I thought I'd start a new thread as not to derail the Workbench one.
>
> You understood correctly, the validate function was a much needed addition
> to JMeter, it currently needs more importance in the UI. I think it could
> be vastly improved with a button on the top row and by auto adding, and
> switching to, the results tree view once pressed. Or perhaps use a
> separate/temp tree view that's not attached to the test plan but lives in a
> separate window?
>
Would it be possible to show some  mock-up ?
I don't clearly see what you have in mind , but I am very curious to
understand.

>
> Thoughts?
>

+1 once I see mockup :-) or a patch if it's faster for you.


> Graham
>
> On Fri, 10 Nov 2017 at 16:39 UBIK LOAD PACK Support <
> supp...@ubikloadpack.com> wrote:
>
> Hi Graham,
> Thanks for your answers and feedback.
>
> My answers below.
> Regards
>
> On Fri, Nov 10, 2017 at 5:26 PM, Graham Russell <gra...@ham1.co.uk> wrote:
>
> > +1
> >
> > ...
> > I think to improve the UX would be to enable running of individual thread
> > groups, single threaded with a tree results view (that you don't have to
> > manually add).
> >
>
> Except for the manually added View Results Tree, the feature you're looking
> for already exists:
>
> 1. Right click on Thread Group:
> 1. Validate : Runs by default 1 thread (configurable), 1 iteration
> (configurable), No pauses (configurable)
> 2. Start No Pause
> 3. Start
>
> Did I misunderstand ?
>
>
> This would be far more intuitive and better align to a usual load test
> > workflow but far more work and maybe something I should raise a bugzilla
> > on?
> >
>
> Yes , create the remaining part as per my previous comment.
>



-- 

Regards
Ubik Load Pack <http://ubikloadpack.com> Team
Follow us on Twitter <http://twitter.com/ubikloadpack>


Cordialement
L'équipe Ubik Load Pack <http://ubikloadpack.com>
Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>

Re: Workbench : Let's drop it ?

[UBIK LOAD PACK Support]

Hi Graham,
Thanks for your answers and feedback.

My answers below.
Regards

On Fri, Nov 10, 2017 at 5:26 PM, Graham Russell  wrote:

> +1
>
> I think dropping it will simplify the code and the UX in the most efficient
> way, especially as time is always short for contributors.
>
> It seems generally confusing and not especially useful:
> https://stackoverflow.com/questions/44746278/why-
> workbench-is-shown-as-default-in-jmeter
> http://blog.sourcepole.ch/2011/01/04/the-jmeter-
> workbench-a-trapdoor-for-the-newbie/
>
> From the docs: "The WorkBench simply provides a place to temporarily store
> test elements while not in use, for copy/paste purposes, or any other
> purpose you desire."
>
> This can be replicated (as Andrey said) in the test plan by a separate
> tread group and just disabling or deleting it before running a test, this
> is less likely to confuse and for people to lose work.
>
> I think to improve the UX would be to enable running of individual thread
> groups, single threaded with a tree results view (that you don't have to
> manually add).
>

Except for the manually added View Results Tree, the feature you're looking
for already exists:

   1. Right click on Thread Group:
  1. Validate : Runs by default 1 thread (configurable), 1 iteration
  (configurable), No pauses (configurable)
  2. Start No Pause
  3. Start

Did I misunderstand ?


This would be far more intuitive and better align to a usual load test
> workflow but far more work and maybe something I should raise a bugzilla
> on?
>

Yes , create the remaining part as per my previous comment.




>
> Thanks
>
> Graham
>
> On Fri, 10 Nov 2017 at 15:07 Philippe Mouawad 
> wrote:
>
> > If we look at consensus, we have:
> >
> >- 3 (+1) to remove it (Maxime, Antonio and me) with favor to move the
> >elements inside Test plan as disabled (so backward compat). If we have
> > a PR
> >or patch that does that, I'll merge it after testing as much as
> > possible.
> >- 1 (-1) or (0) for sebb, do you agree sebb ? what would be your exact
> >position ?
> >
> >
> > @Felix, @Milamber, @Vladimir,@Graham, @Mikhail , any thoughts on this ?
> >
> >
> >
> > Thanks
> >
> > On Fri, Nov 10, 2017 at 4:01 PM, Andrey Pokhilko  wrote:
> >
> > > I don't see any point for Workbench to exist. Simply disabling elements
> > > in-place makes them temporary stored anywhere in test plan.
> > >
> > > Do we have a decision to remote it or not? I don't want to spend
> > > resources if we don't have consensus.
> > >
> > > Andrey Pokhilko
> > >
> > > 09.11.2017 13:41, sebb пишет:
> > > > Why not consider how to make the Workbench more intuitive and useful?
> > > >
> > > > On 8 November 2017 at 16:47, Philippe Mouawad
> > > >  wrote:
> > > >> As you say, it’s oddity.
> > > >> A tool should be intuitive, this part is not, we cannot always say,
> > > rtfm.
> > > >> You know that lot of people don’t read docs.
> > > >>
> > > >> Let’s try and see if it is that complex.
> > > >>
> > > >> We shouldn’t say , we cannot touch, JMeter is not legacy, so we
> touch
> > ,
> > > >> break then fix .
> > > >>
> > > >> Regards
> > > >>
> > > >> On Wednesday, November 8, 2017, sebb  wrote:
> > > >>
> > > >>> On 8 November 2017 at 16:18, Philippe Mouawad
> > > >>> > wrote:
> > >  Hello,
> > >  I’d say Test Plan.
> > >  I suggest testcompiler ignores them
> > > >>> That would involve a lot of testing to ensure nothing broke.
> > > >>>
> > > >>> Are you sure it's worth it?
> > > >>>
> > > >>> There have been other instances where what seems to be a minor
> change
> > > >>> turns out to be far more intrusive than first expected.
> > > >>> Dropping Workbench seems like such a case to me; it's been part of
> > > >>> JMeter for so long that there are bound to be lots of places that
> > > >>> assume it is present.
> > > >>>
> > > >>> I agree that the Workbench is a bit of an oddity, but I think
> > removing
> > > >>> it is going to prove much more of a headache than improving the
> > > >>> documentation to explain it better.
> > > >>> And potentially find more uses for it.
> > > >>>
> > >  Regards
> > > 
> > >  On Wednesday, November 8, 2017, Artem Fedorov <
> > > >>> artem.fedo...@blazemeter.com >
> > >  wrote:
> > > 
> > > > Hello,
> > > >
> > > > If we dropped WorkBench, in which element we can add Non-Test
> > > Elements
> > > > (HTTP Mirror Server, HTTP(S) Test Script Recorder, Property
> > Display)?
> > > > Can we add these Non-Test Elements to Test Plan (root) or Test
> > > Fragment?
> > > >
> > > > Thanks
> > > >
> > > >  > > > source=link_campaign=sig-email_content=webmail>
> > > > Без
> > > > вирусов. www.avast.ru
> > > > 

Re: Remove jmeter.sh

[UBIK LOAD PACK Support]

Let's chain it and log a message to deprecate  it.

I've seen some projects add a sleep to deprecate and make people move away,
let's do that.

Regards

On Fri, Oct 27, 2017 at 8:57 PM, sebb  wrote:

> Rather than drop it, which may break some 3rd party scripts, it could
> chain to jmeter (or be a direct copy)
>
> On 27 October 2017 at 18:03, Antonio Gomes Rodrigues 
> wrote:
> > jmeter have been updated to Java 9
> >
> > I propose to use jmeter and not jmeter.sh
> >
> > 2017-10-27 18:57 GMT+02:00 Andrey Pokhilko :
> >
> >> Hi,
> >>
> >> Agree, for me it was always confusing between jmeter/jmeter.sh script,
> >> which one is proper to use.
> >>
> >> Andrey Pokhilko
> >>
> >> 27.10.2017 19:48, Philippe Mouawad пишет:
> >> > Hello,
> >> > Is there a point keeping jmeter.sh ?
> >> > I feel it is a subset of jmeter ? What was its initial intention ?
> >> > Do we still need it ?
> >> >
> >> >
> >>
> >>
>



-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: http2 support

[UBIK LOAD PACK Support]

Hello,
See:

- https://incubator.apache.org/guides/ip_clearance.html

Regards

On Tuesday, October 3, 2017, Antonio Gomes Rodrigues 
wrote:

> Hi,
>
> I'm also curious about why we could not integrate apache licensed code. I
> was thinking we can fork a plugin and integrate it in JMeter.
>
> Anybody have an idea?
>
> Antonio
>
> 2017-10-02 21:25 GMT+02:00 Philippe Mouawad  >:
>
> > On Mon, Oct 2, 2017 at 9:21 PM, Emilian Bold  >
> > wrote:
> >
> > > > AFAIK, unless the project donates their code to JMeter, we cannot
> take
> > it
> > > as it would be a license infringement at minimum.
> > >
> > > It's open source under the Apache 2.0 license. The license itself
> allows
> > > you to bundle it with JMeter proper. Of course, it won't be owned by
> the
> > > ASF but you can have it as a dependency.
> > >
> > > You could also "fork" it (or "vendor" it) if you want to add some
> > patches.
> > >
> >
> > AFAIK, we need for this the owner to make a donation as piece of code is
> > important.
> > There is IP clearance process at Apache for that. I doubt that we can
> take
> > it as is or fork it, but I'm not an expert in those matters.
> > Maybe Andrei can tell us more.
> >
> >
> >
> > > Have there been any talks with CA Technologies / Blazemeter to perhaps
> > > donate the plugin to the ASF?
> > >
> > > > Would you like to work on its implementation ?
> > >
> > > Why would I do that when you have this plugin available under a
> > compatible
> > > license as well as this other one
> > > https://github.com/syucream/jmeter-http2-plugin under Apache 2.0 based
> > on
> > > netty?
> > >
> > I tested this one, it does not work very well.
> > Looks more like a POC than a stable implementation.
> >
> >
> >
> > >
> > >
> > > --emi
> > >
> > > On Mon, Oct 2, 2017 at 10:11 PM, Philippe Mouawad <
> > > philippe.moua...@gmail.com > wrote:
> > >
> > > > Hi Emilian,
> > > > AFAIK, unless the project donates their code to JMeter, we cannot
> take
> > it
> > > > as it would be a license infringement at minimum.
> > > >
> > > > Regarding HTTP2 there are many options AFAIK:
> > > >
> > > >- Jetty
> > > >- Netty
> > > >- HC5
> > > >
> > > > Would you like to work on its implementation ?
> > > >
> > > >
> > > > Regards
> > > >
> > > > On Mon, Oct 2, 2017 at 8:54 PM, Emilian Bold  >
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I see we have a HTTP2 plugin
> > > > > https://github.com/Blazemeter/jmeter-bzm-plugins based on the
> Jetty
> > > > HTTP2
> > > > > support and under an Apache 2.0 license.
> > > > >
> > > > > Is there any reason JMeter could not bless this implementation and
> > > bundle
> > > > > it?
> > > > >
> > > > > --emi
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cordialement.
> > > > Philippe Mouawad.
> > > >
> > >
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> >
>


-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: [GitHub] jmeter issue #306: Fix to BUG_60156

[UBIK LOAD PACK Support]

Hello Emilian,
There was indeed one last issue in TCPClientImpl with backward
compatibility, we pushed a commit
It should be ok now, but please review (
https://github.com/apache/jmeter/pull/306/files):

   - If AbstractTCPClient implement the old method they will work
   - If AbstractTCPClient implement the new  method, they will of course
   work
   - If 3rd party code calls the old method, they should also work


Regards

@ubikloadpack Team
On Fri, Sep 8, 2017 at 6:31 AM, Emilian Bold  wrote:

> It is backwards compatible as an SPI, meaning that 3rd party
> implementations that use AbstractTCPClient will still work if they
> implement only the old method.
>
> But it is not backwards compatible as an API because 3rd party code that
> calls the old method will now receive nulls for those existing
> implementations.
>
> So the question is if this is supposed to be an API or it's just an SPI.
>
> --emi
>
> On Fri, Sep 8, 2017 at 12:03 AM, Philippe Mouawad <
> philippe.moua...@gmail.com> wrote:
>
> > Hi Emilian
> > AFAIU, it is backward compatible no ?
> >
> > in AbstractTCPClient.java
> >  > a9c4a5285efe7b85e9bcd62614>,
> > the new method calls the old one.
> >
> > Only the subclasses has been modified to implement the new one.
> >
> > Thanks for reviewing
> >
> > On Thu, Sep 7, 2017 at 10:58 PM, Emilian Bold 
> > wrote:
> >
> > > I don't know the codebase but why bother marking the old method as
> > > @Deprecated if you are not making the change backwards compatible?
> > >
> > > I see 'return null' in two existing methods while previously those
> > methods
> > > returned something.
> > >
> > > A proper pattern would have been to call read(is, null) or read(is, new
> > > DummySampleResult()).
> > >
> > >
> > > --emi
> > >
> > > On Thu, Sep 7, 2017 at 11:25 PM, pmouawad  wrote:
> > >
> > > > Github user pmouawad commented on the issue:
> > > >
> > > > https://github.com/apache/jmeter/pull/306
> > > >
> > > > Hello
> > > > Unless there is a NO GO , I'll commit this tomorrow.
> > > >
> > > > Thanks
> > > >
> > > >
> > > > ---
> > > >
> > >
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> >
>

Re: Better JMeter remote testing on Amazon EC2

[UBIK LOAD PACK Support]

Hello ,
It looks like a very good idea.
But maybe not bind it to one cloud by using jcloud ?

Regards

On Thu, Jul 27, 2017 at 9:12 AM, Emilian Bold 
wrote:

> Hello,
>
> JMeter remote testing is interesting but seems to require a lot of
> manual fiddling to deploy to Amazon EC2.
>
> I wonder if users would be interested in some simpler interface for
> Amazon EC2 where you just give your credentials, the test you want to
> run, the EC2 regions / machine type and it automatically starts and
> runs everything behind the scenes?
>
> --emi
>



-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: About JMETER Bug 60782 and Bug 60966

[UBIK LOAD PACK Support]

Hello,
60782 depends on a dev discussion that is still pending.

I suggest you work on another issue.

Thanks

On Mon, Jul 17, 2017 at 4:09 PM, Tharindu Dananjaya  wrote:

> I like to work on these bugs and I have already build the project.How can I
> recreate bugs and have more information of these two bugs ?
>



-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: Issue with Search replace functionality in jmeter

[UBIK LOAD PACK Support]

Hello,
What was your search expression ?

Regards

On Fri, Apr 28, 2017 at 8:25 AM, mitsm  wrote:

> Hello,
>
> I was trying to do search and replace in jmeter (3.2 r1790748) for a change
> in URL for my application. I did as shown in the snaps below but found that
> the search replace was stuck and did not responded even after about 30
> mins.
>
> I did a bit of digging using jvisual vm and found that the method
> "org.apache.jorphan.util.JOrphanUtils.replaceAllWithRegex()" had the
> highest
> self time and it kept increasing with time (obviously!).
>
>  Search_Replace_Snap.png>
>
>  Search_Replace_snap_2.png>
>
>  >
>
> Seems to be a bug. Can i please get some suggestions?
>
>
>
> --
> View this message in context: http://www.jmeter-archive.org/
> Issue-with-Search-replace-functionality-in-jmeter-tp5725533.html
> Sent from the JMeter - Dev mailing list archive at Nabble.com.
>



-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: [VOTE] Release JMeter 3.2 RC2

[UBIK LOAD PACK Support]

Hello,
Note this is annoying as fixing it would mean that our plugin would only
support 3.2.
We usually try to support N and N-1 versions to allow for migration.
And this was usually the policy with JMeter releases.

Hope you can take this into account.
Regards



On Sun, Apr 2, 2017 at 3:03 PM, UBIK LOAD PACK Support <
supp...@ubikloadpack.com> wrote:

> Hello,
> First thanks a lot for all the team for the great work on Apache JMeter
> and thanks to RM !
>
> Now for this release, it appears HeaderManager API has been modified in a
> breaking and undocumented way:
> This method:
>
>- https://github.com/apache/jmeter/blob/v3_1/src/protocol/
>http/org/apache/jmeter/protocol/http/control/HeaderManager.java#L268
>
> <https://github.com/apache/jmeter/blob/v3_1/src/protocol/http/org/apache/jmeter/protocol/http/control/HeaderManager.java#L268>
>
> Has been modified:
>
>- https://github.com/apache/jmeter/blob/v3_2_RC2/src/
>protocol/http/org/apache/jmeter/protocol/http/control/
>HeaderManager.java#L234
>
> <https://github.com/apache/jmeter/blob/v3_2_RC2/src/protocol/http/org/apache/jmeter/protocol/http/control/HeaderManager.java#L234>
>
>
> This would unfortunately break our plugin.
>
> Is is possible to reintroduce this method and make it deprecated ?
>
> Thanks
> Regards
>
> UbikLoadPack Team
>
>
>
> On Sun, Apr 2, 2017 at 12:45 PM, Rainer Jung <rainer.j...@kippdata.de>
> wrote:
>
>> Am 01.04.2017 um 18:23 schrieb Milamber:
>>
>>> Hello,
>>>
>>> The second release candidate for JMeter 3.2 (r1789808) has been
>>> prepared, and your votes are solicited.
>>>
>>> This release brings new features and fixes bugs.
>>>
>>> Please, test this release candidate (with load tests and/or functional
>>> tests) using Java 8 on Linux/Windows/Mac OS, especially on the changes.
>>> The feedback are welcome.
>>>
>>> You can read the New and Noteworthy section with some screenshots to
>>> illustrate improvements and full list of changes at:
>>> http://home.apache.org/~milamber/jmeter-3.2RC2/docs/changes.html
>>>
>>> JMeter is a Java desktop application designed to load test functional
>>> behavior and measure performance. The current version is targeted at
>>> Java 8+.
>>>
>>> Download - Archives/hashes/sigs:
>>>
>>> https://dist.apache.org/repos/dist/dev/jmeter/v3.2_RC2/
>>> (dist revision r18998)
>>>
>>> RAT report:
>>>
>>> http://home.apache.org/~milamber/jmeter-3.2RC2/dist/rat-repo
>>> rt-jmeter-3.2RC2.txt
>>>
>>>
>>> MD5 hashes of archives for this vote:
>>>
>>> cfa8095f9c42208eb70caa6a0074558a *apache-jmeter-3.2.tgz
>>> 5d49a7cf94ce4dfebc68ab35f6f686d8 *apache-jmeter-3.2.zip
>>> 2dad5f6366647c93f822c87e64ff24ac *apache-jmeter-3.2_src.tgz
>>> 43f4ea27110efb23032e708e44dafe55 *apache-jmeter-3.2_src.zip
>>>
>>> Site Docs are here:
>>> http://home.apache.org/~milamber/jmeter-3.2RC2/docs/
>>>
>>> Maven staging repository is accessible here:
>>> https://repository.apache.org/content/repositories/orgapache
>>> jmeter-1016/org/apache/jmeter/
>>>
>>>
>>> Tag:
>>> https://svn.apache.org/repos/asf/jmeter/tags/v3_2_RC2/
>>>
>>> Keys are here:
>>> https://www.apache.org/dist/jmeter/KEYS
>>>
>>> N.B.
>>> To download the dependencies: "ant download_jars"
>>>
>>> To create the jars and test JMeter: "ant package test".
>>>
>>> JMeter 3.2 requires Java 8 or later to run.
>>>
>>> Some known issues and incompatible changes are listed on changes page.
>>> http://home.apache.org/~milamber/jmeter-3.2RC2/docs/changes.
>>> html#Known%20problems%20and%20workarounds
>>>
>>>
>>>
>>> All feedback and vote are welcome.
>>>
>>> [XX] +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!
>>>
>>
>> +1 (binding), thanks for RM.
>&

Re: [VOTE] Release JMeter 3.2 RC2

[UBIK LOAD PACK Support]

Hello,
First thanks a lot for all the team for the great work on Apache JMeter and
thanks to RM !

Now for this release, it appears HeaderManager API has been modified in a
breaking and undocumented way:
This method:

   -
   
https://github.com/apache/jmeter/blob/v3_1/src/protocol/http/org/apache/jmeter/protocol/http/control/HeaderManager.java#L268

Has been modified:

   -
   
https://github.com/apache/jmeter/blob/v3_2_RC2/src/protocol/http/org/apache/jmeter/protocol/http/control/HeaderManager.java#L234


This would unfortunately break our plugin.

Is is possible to reintroduce this method and make it deprecated ?

Thanks
Regards

UbikLoadPack Team



On Sun, Apr 2, 2017 at 12:45 PM, Rainer Jung 
wrote:

> Am 01.04.2017 um 18:23 schrieb Milamber:
>
>> Hello,
>>
>> The second release candidate for JMeter 3.2 (r1789808) has been
>> prepared, and your votes are solicited.
>>
>> This release brings new features and fixes bugs.
>>
>> Please, test this release candidate (with load tests and/or functional
>> tests) using Java 8 on Linux/Windows/Mac OS, especially on the changes.
>> The feedback are welcome.
>>
>> You can read the New and Noteworthy section with some screenshots to
>> illustrate improvements and full list of changes at:
>> http://home.apache.org/~milamber/jmeter-3.2RC2/docs/changes.html
>>
>> JMeter is a Java desktop application designed to load test functional
>> behavior and measure performance. The current version is targeted at
>> Java 8+.
>>
>> Download - Archives/hashes/sigs:
>>
>> https://dist.apache.org/repos/dist/dev/jmeter/v3.2_RC2/
>> (dist revision r18998)
>>
>> RAT report:
>>
>> http://home.apache.org/~milamber/jmeter-3.2RC2/dist/rat-
>> report-jmeter-3.2RC2.txt
>>
>>
>> MD5 hashes of archives for this vote:
>>
>> cfa8095f9c42208eb70caa6a0074558a *apache-jmeter-3.2.tgz
>> 5d49a7cf94ce4dfebc68ab35f6f686d8 *apache-jmeter-3.2.zip
>> 2dad5f6366647c93f822c87e64ff24ac *apache-jmeter-3.2_src.tgz
>> 43f4ea27110efb23032e708e44dafe55 *apache-jmeter-3.2_src.zip
>>
>> Site Docs are here:
>> http://home.apache.org/~milamber/jmeter-3.2RC2/docs/
>>
>> Maven staging repository is accessible here:
>> https://repository.apache.org/content/repositories/orgapache
>> jmeter-1016/org/apache/jmeter/
>>
>>
>> Tag:
>> https://svn.apache.org/repos/asf/jmeter/tags/v3_2_RC2/
>>
>> Keys are here:
>> https://www.apache.org/dist/jmeter/KEYS
>>
>> N.B.
>> To download the dependencies: "ant download_jars"
>>
>> To create the jars and test JMeter: "ant package test".
>>
>> JMeter 3.2 requires Java 8 or later to run.
>>
>> Some known issues and incompatible changes are listed on changes page.
>> http://home.apache.org/~milamber/jmeter-3.2RC2/docs/changes.
>> html#Known%20problems%20and%20workarounds
>>
>>
>>
>> All feedback and vote are welcome.
>>
>> [XX] +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!
>>
>
> +1 (binding), thanks for RM.
>
> Details:
>
> - MD5 OK
> - signatures OK
> - key in KEYS file
> - tgz and zip for src and bin consistent
> - svn and tgz/zip mostly consistent
>   - file bin/utility.groovy missing in src tgz/zip
> IMHO not a showstopper, fixed in r1789871 after RC2.
> Note: the missing file breaks the ability to run
> "ant distribution" from a src tgz/zip.
> I think this must have already been the case for
> 3.1 (untested).
>   - some files with name "*cp1252*" contain some binary differences
> between svn and zip.
> Example: file test/resources/org/apache/jmet
> er/protocol/jms/sampler/render/cp1252.txt
> in svn is 3 bytes hex 0xe9 0xe8 0x80
> and in zip 6 bytes hex 0xef 0xbf 0xbd 0xef 0xbf 0xbd
> - files bin/report-template/*/*/*/make.sh are not executable
>   (not in svn and not in any bin or src archive)
> - builds fine except:
>   - needed to disable class RenderInBrowser.java,
> because Oracle doesn't support JavaFX for Solaris
> - build result looks consistent with distribution, except for
>   - some ordering in javadoc (expected)
>   - binary jar files (expected)
> - no Javadoc warnings
> - new dependencies (expected)
> - ran the tests (but only with java.awt.headless) without failures
>   - needed to adjust the 500ms test execution time margin in
> TestSchedulerWithTimer.jmx (slow test system)
> - I have not checked the staging repository.
> - I have not checked the rat report
>
> Build and tests were done using Java 1.8.0_121, OS was Solaris 10 Sparc.
>
> Regards,
>
> Rainer
>

Re: Variable in BackendListener

[UBIK LOAD PACK Support]

Hello,

In distributed mode use:
-G from controller
or -J on jmeter-server

Regards

On Thu, Mar 9, 2017 at 9:52 AM, Maxime Chassagneux <
maxime.chassagn...@gmail.com> wrote:

> Hello,
>
> I can't variabilize parameter of BackendListener when I start a run via
> remote test.
> None of the value is replace.
>
> If I put something like this :
>
> influxdbUrl => ${__P(influxdbUrl, http://xxx.fr/influxdb_query/write?db=
> qualif}
>
> It cause one error :
>
> 2017-03-09 08:46:36,232 ERROR o.a.j.s.RemoteListenerWrapper:
> testStarted(host) on tlsqninjec10:7080
> java.lang.IllegalStateException: Failed calling setupTest
> Caused by: java.net.MalformedURLException: no protocol: ${__P(influxdbUrl,
> http://xxx.fr/influxdb_query/write?db=qualif)}
>
> Of course it work localy.
>
> Is it normal ? Any tips ? Where I have to start looking for fix it ?
>



-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Using RX Java for Summariser (and possibly other places)

[UBIK LOAD PACK Support]

Hello,
It might be interesting to look into using this library to better manager
listeners like Summariser and even all GUI related listeners related to
Bugzilla 60687  (see SwingScheduler.instance() in Readme):

   - http://www.vogella.com/tutorials/RxJava/article.html
   - https://github.com/ReactiveX/RxJava


Regards

Re: Hello:)

[UBIK LOAD PACK Support]

Hi,
There are also files in src folder that are suffixed by Language code (_fr
for French for example) for BeanInfo based components.
Search for *_fr.properties in project and you will find them.

Currently only EN and FR are complete.

Regards

On Wed, Feb 15, 2017 at 9:58 AM, Antonio Gomes Rodrigues 
wrote:

> Hi,
>
> Files are in src\core\org\apache\jmeter\resources
>
> You have a properties file by language
>
> Antonio
>
>  source=link_campaign=sig-email_content=webmail>
> Garanti
> sans virus. www.avast.com
>  source=link_campaign=sig-email_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> 2017-02-14 22:21 GMT+01:00 Bartosz :
>
> > Good Evening!
> >
> > I want to help with translations, can I ask you for the files I need to
> > start with? If that's matter - I'm from Poland.
> >
> > greetings,
> > Bartosz
> >
> >
>



-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: AuthManager behaviour

[UBIK LOAD PACK Support]

For record, fixed in upcoming 3.2:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57242

Regards

On Tue, Jul 30, 2013 at 9:28 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:

> Hello,
> Any answer on this ?
>
> Thanks
> Regards
> Philippe
>
>
> On Sat, Jul 27, 2013 at 11:08 PM, Philippe Mouawad <
> philippe.moua...@gmail.com> wrote:
>
>> While doing some checks with AuthManager (using HC4 and HC3.1) I noticed
>> to my surprise that it supported DIGEST auth while I thought it didn't.
>> At least it does with a Tomcat Digest auth.
>>
>> 1) Do you confirm it really does ?
>>
>> 2) Also something not clear for me, reading :
>> http://hc.apache.org/httpcomponents-client-ga/
>> tutorial/html/authentication.html
>> It is said preemptive auth is not supported out of the box, and we need
>> to use AuthCache object but I see nowhere in JMeter code usage of this
>> class.
>> So how come it works ?
>>
>> 3) Finally, I notice setting :
>> http.authentication.preemptive$Boolean=false
>> leads to preemptive auth being disabled for HC3 (Ok) , but also not
>> working for HC4 ? How come it impacts it ?
>>
>> Thanks for clarification.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>

Re: New Popup menu item to apply a Naming Policy

[UBIK LOAD PACK Support]

Hello,
Any feedback on this ?

Thank you
Regards

On Thursday, December 22, 2016, UBIK LOAD PACK Support <
supp...@ubikloadpack.com> wrote:

> Hello,
> We created:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60514
>
> Which shows how feature would work.
> Typically you'll use this feature after a recording of an application.
>
> For now, implementation only renames first level of children of selected
> TC but it could be easily changed to examine all the hierarchy.
>
> Regards
> @ubikloadpack
>
> On Thu, Dec 22, 2016 at 10:23 AM, UBIK LOAD PACK Support <
> supp...@ubikloadpack.com
> <javascript:_e(%7B%7D,'cvml','supp...@ubikloadpack.com');>> wrote:
>
>> Hello,
>> During the development of Test Plan our customer frequently require that
>> a  naming policy is applied to the Test Plan developed.
>>
>> This can be for example to :
>> - Prefix TC with something
>> - Add a suffix to children of TC
>> ...
>>
>> Applying this policy can be cumbersome and is a bit boring.
>> Would you be interested in making this generic this way:
>>
>>- On appliable nodes in Tree add a contextual popup menu (Apply
>>Naming Policy)
>>- When click on it, JMeter would search in classpath for
>>implementations of TreeNodeNamingPolicy. If one is found us it, it many
>>then use a configuration property
>>- For every child of the parent node, call this policy to name
>>children of this node
>>
>> If you're interested we can contribute a patch
>>
>> Let us know your thoughts.
>>
>> Thank you
>> --
>>
>> Regards
>> @ubikloadpack
>>
>
>
>
>

-- 

Regards
Ubik Load Pack <http://ubikloadpack.com> Team
Follow us on Twitter <http://twitter.com/ubikloadpack>


Cordialement
L'équipe Ubik Load Pack <http://ubikloadpack.com>
Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>

New Popup menu item to apply a Naming Policy

[UBIK LOAD PACK Support]

Hello,
During the development of Test Plan our customer frequently require that a
naming policy is applied to the Test Plan developed.

This can be for example to :
- Prefix TC with something
- Add a suffix to children of TC
...

Applying this policy can be cumbersome and is a bit boring.
Would you be interested in making this generic this way:

   - On appliable nodes in Tree add a contextual popup menu (Apply Naming
   Policy)
   - When click on it, JMeter would search in classpath for implementations
   of TreeNodeNamingPolicy. If one is found us it, it many then use a
   configuration property
   - For every child of the parent node, call this policy to name children
   of this node

If you're interested we can contribute a patch

Let us know your thoughts.

Thank you
-- 

Regards
@ubikloadpack

Re: Thoughts on 2 proposals

[UBIK LOAD PACK Support]

On Wed, Aug 31, 2016 at 10:04 AM, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> UBIK>The issue with CTT is that it tries to match the throughput but always
> exceeds it before slowing down, and if CTT is combined with variable pauses
> UBIK>, it becomes very hard for CTT to adjust the pauses to reach the
> Throughput..
>
> If CTT has issues, why don't we just fix CTT then?
>
Because it is probably impossible.
CTT has use cases but does not fit here due to variable pauses I think.
That's why we need this additional feature.


> Do you mean CTT will never be able to follow given throughput goal?
>
It will but the more pauses are variable the harder it is for it.


> Well, the timer of my choice does follow given throughput with no
> overshooting/undershooting issues, so it is not that big deal to have a
> timer that just follows given throughput goal.
>
> Note: CTT is off-topic for the current thread.
>
No, because  you mentioned in the bugzilla CTT as being able to answer this
use case. That's why I am mentionning it.

Note2: Philippe has recently fixed a couple of issues around CTT, thread
> pausing, etc.
>
Yes, but it only concerns the stopping of the test.

>
> Note3: I agree there might be valid cases for "adjust interpage timers"
> feature.
>

Good thing :-) We're almost okay then :-)

>
> Vladimir
>



-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: Thoughts on 2 proposals

[UBIK LOAD PACK Support]

On Wed, Aug 31, 2016 at 9:17 AM, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >As you read, the proposed solution (add a new field to timers) handles
> also
> the Ajax case.
>
> That is true.
> However it would likely to require user to walk over test plan and flip
> switches "adjust or not" manually. That's a pity.
>
> If I look at the last 20 Plans created during our load test campaigns, it
would concern 5% of elements.

This feature is IMO needed whenever there is no precise information on
Think Times provided by the business through analytics and you have to
match an expected throughput.

Compared to CTT, it is also IMO an easier and more precise way to play on
throughput.
The issue with CTT is that it tries to match the throughput but always
exceeds it before slowing down, and if CTT is combined with variable pauses
, it becomes very hard for CTT to adjust the pauses to reach the
Throughput..



That would open one more pitfall of "blind timer adjustment would give
> unexpected results".
>
Do you have another idea ?





>
> Vladimir
>



--

Re: Thoughts on 2 proposals

[UBIK LOAD PACK Support]

On Wed, Aug 31, 2016 at 8:58 AM, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >Yes , but this case is already edgy in JMeter as there is no concept of
> parallel request
>
> Note:
> 1) page...ajax delay can be used even without parallel requests
> 2) I expect "parallel request" feature to be landed soon, so it makes sense
> to plan "adjust timers" feature accordingly. Don't you suggest that JMeter
> will miss parallel request feature forever, so we can just ignore that case
> when implementing "adjust timers"?
>

As you read, the proposed solution (add a new field to timers) handles also
the Ajax case.
Regarding Parallel request, I would also be happy to see it landing soon.



>
> Vladimir
>



--

Re: Thoughts on 2 proposals

[UBIK LOAD PACK Support]

Hi all,
Some answers inline below.
Regards


On Wednesday, August 31, 2016, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >In my opinion, this feature could be usefull.
>
> TL;DR: I don't try to prove that the feature is bad. I just don't have
> motivation to implement this particular feature, so I list several corner
> cases when the feature can behave unexpectedly if implemented in a naive
> way.
>
>
> Let me take a step back.
>
> Here are some corner cases when "adjust timers" feature might harm:
>
> 1) Throughput timers. If a timer is set to maintain X requests per second,
> then "adjust timers" feature should not adjust that timer. Otherwise the
> throughput would be way off.
> There is at least one such timer in JMeter core.


True.
as explained in bugzilla, this will be handled through a method
canTimerBeAdjusted.
CTT and Sync Timer will return false.


> 2) Suppose there's an AJAX application, and there's natural duration
> between "the first HTML page, and the subsequent AJAX request". I mean it
> takes some time for the browser to parse the initial page, and only then
> AJAX requests are sent. In order to reflect that JMeter would have some
> timer to implement the delay.
> "adjust timers" feature should not impact that delay.


Yes , but this case is already edgy in JMeter as there is no concept of
parallel request.


>
> Note: I don't think this particular type of delay can easily be
> distinguished from true inter-page delays when doing automatic recording.
>
> 3) Service timers that are used to implement "wait for the task" pattern.
> I mean:
> while(!task_ready) {
>   sleep(1 min);
>   refresh(home screen);
> }

Good catch .
An option would be to introduce a new field on timers to say if it can be
adjusted or not.
Bu default it would be configured to true for all except CTT and Sync timer.
This also solves the ajax case.

>
> I happen to see that pattern quote often.
> That particular "sleep(1min)" should not be "adjusted" (multiplied or
> whatever) since that particular timer is not related to user behavior, but
> it just lets the system to process the data.
>
> So, the problem is "timer's java class" is the same yet the meaning (adjust
> or not) is different.
>
> 4) There might be user-created timers those are completely unknown to
> JMeter. Something should be done for the timers as well.

User just override the ancestor method

>
> 5) Some good wording in documentation is required to make it clear for the
> end-user when the feature should be used, and when it should not be used.
> Of course, every feature can be misused, so "theoretical misuse" should not
> serve as a reason to deny a feature. However, the particular "adjust
> timers" can very easily be confused with "tune throughput" feature. As
> discussed, "throughput" should be tuned by the proper throughput timers.


Yes

>
> Vladimir
>


-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Thoughts on 2 proposals

[UBIK LOAD PACK Support]

Hello,
We opened today 2 enhancement requests:
- https://bz.apache.org/bugzilla/show_bug.cgi?id=60018
- https://bz.apache.org/bugzilla/show_bug.cgi?id=60017

Would you be ok to integrate 2 patches if we implement what we proposed ?

Thank you
Regards
UbikLoadPack Team
@ubikloadpack

Throughput Controller default property values

[UBIK LOAD PACK Support]

Hello,
Currently when you create a Throughput Controller, its default
configuration is:
- Total Executions
- Per User is checked


In our customer's experience and our scripting experience, in most of case
(I would say 95%) we switch to :
- Percent Executions

And regarding Per User, I would say around 70% you uncheck Per User.

I don't know what other users do, but maybe it would be interesting to ask
and potentially change those default values  ?


-- 

Regards
@ubikloadpack

New __g (Groovy based) function as an alternative for __BeanShell for performance, easiness and up to dateness

[UBIK LOAD PACK Support]

Hello,

Currently whenever you want to make some processing and a JMeter
function is not available for it, you can only use __BeanShell
function.
For example:
- substring
- length
- Maths functions
- + hundreds of examples where you need the power of Java without
wanting to use a JSR223TestElement.



Unfortunately Beanshell performances are horrid compared to Groovy
ones for example besides the fact that Groovy is now integrated in
JMeter, maintained by Apache and very popular and that Beanshell is
nearly abandoned.

As an example, we attached a Test Plan showing the performance difference.

TG-Groovy Enabled only:

Generate Summary Results =  2 in 00:00:00 = 41666.7/s Avg: 0
Min: 0 Max: 2 Err: 0 (0.00%)


TG-Beanshell enabled only:
Generate Summary Results +  17444 in 00:00:13 = 1312.6/s Avg: 0
Min: 0 Max: 2 Err: 0 (0.00%) Active: 10 Started: 10
Finished: 0
Generate Summary Results +   2556 in 00:00:02 = 1296.1/s Avg: 0
Min: 0 Max: 1 Err: 0 (0.00%) Active: 0 Started: 10
Finished: 10
Generate Summary Results =  2 in 00:00:15 = 1310.4/s Avg: 0
Min: 0 Max: 2 Err: 0 (0.00%)



This simple benchmark shows that this new __g function is 31 to 32
times faster than __BeanShell.



So we propose to add this function that will work the same way as Beanshell.

We have submitted under
https://bz.apache.org/bugzilla/show_bug.cgi?id=59991 a new __g
function for Groovy which is the equivalent of __BeanShell.

Note we could make this function totally generic by adding an argument for
the language to use but it would add a new parameter, and we aim at
encouraging best practices which are to use fastest languages.
But of course this can be amended


-- 

Regards
@ubikloadpack Team

Re: Regression in 3.0 / Bug 59401 - is it really a bug?

[UBIK LOAD PACK Support]

Hello sebb,

On Mon, May 2, 2016 at 3:09 PM, sebb  wrote:

> If a server response includes Content-Encoding, then HC can be asked
> to decode it.
> If HC does this, then it removes the headers that no longer apply.
> This is entirely correct.
> Otherwise, downstream consumers would see an inconsistent response.
>
Yes, Absolutely true regular users of the API.
But in the particular case of JMeter, can this happen ?
In the particular case of JMeter, users usually want to:

   - Check that server response was Compressed or not (ie what were the
   original headers) and the size of the original response (headers + body
   compressed if applies)
   - They also want usually to check some data in the response through
   Assertion, which means it needs to be uncompressed

Usually also, users will compare headers in the browser with headers in
JMeter to see if they match, and it will be suspicious if they don't.
I am afraid a lot of plan and users expect these headers to be here (but
maybe we can ask on user mailing list and twitter)



>
> In particular, if HC did not remove the Content-Encoding header,
> consumers could attempt to decode the response again.
>
> I think it is wrong to change JMeter to restore the original Content-
> headers.
> They are no longer applicable to the sample result.
>
> So either we reject the bug as invalid, or we find a different way of
> providing the original headers (e.g. as X-headers)
>
>
>
> It may also be worth providing an option to tell HC not to decompress
> the response.
>
> This would allow the true server response to be saved.
> It would reduce the JMeter client processing slightly.
>
Yes option might be interesting although it is then hard to know if
received response is OK or a 404 page masked under a 200 response code or
similar cases.


> However the response would not be viewable in the Tree View Listener.
>



-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: Bug 59391 - In Distributed mode, the client exits abnormally at the end of test

[UBIK LOAD PACK Support]

Hi,
To reproduce (it is always reproducable):
- Run locally a jmeter-server
- Run a client (Debug this in your IDE ):
./jmeter -r -n -t  -l
/data/jmeter/re7/results-rc3-remote.csv -e -o /data/jmeter/re7/report-rc3-2

Regards

On Fri, Apr 29, 2016 at 2:06 PM, sebb  wrote:

> I assume that the fix works, however I have not been able to reproduce
> the original issue.
> Maybe it needs a more complicated test. Has anyone else got a reproducer?
>
> However I wonder if this is the correct solution?
>
> The bug mentions TidyRMI, but I don't see how that is relevant.
> The intention is that the TidyRMI method is be called after the test
> is complete, in order to allow JMeter to exit cleanly. Also it only
> interrupts the "RMI Reaper" thread, so it should not have an effect on
> anything else.
>
> If it is somehow interfering with threads that are doing work, then
> this ought to be fixed if possible.
>
> It also seems wrong to create a non-Daemon thread in a Daemon thread -
> that seems very fragile.
>
> I suspect that is the real issue - since we expect the ListenToTest
> thread to complete, it should not be a Daemon thread.
>



-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: Junk Characters in the report Dashboard

[UBIK LOAD PACK Support]

Hello,
Attached files are not accepted on mailing list.
Can you open a bugzilla and attach it or give a link showing the issue.
Did you try RC1 or RC2 ? A fix was made in RC2 maybe related.
Thanks

@ubikloadpack

On Thu, Apr 21, 2016 at 2:00 PM, Krishna Kanth 
wrote:

> All.
>
> I was interested in some of the new features in JMeter 3.0 , so I started
> some testing with the latest build.
>
> When I am generating a report using the jmeter -n -g ,
>
> I am finding that there are some junk characters which are showing up on
> the home page of the report which got generated.
>
> Please find the screenshot attached.
>
> There characters are not report in the report template.
>
> [image: Inline image 1]
>

Re: svn commit: r1739924 - /jmeter/trunk/src/core/org/apache/jmeter/logging/LogkitLoggerAdapter.java

[UBIK LOAD PACK Support]

But wasn't it non final in previous commit ?

On Tue, Apr 19, 2016 at 4:13 PM, sebb  wrote:

> On 19 April 2016 at 13:54, Felix Schumacher
>  wrote:
> >
> >
> > Am 19. April 2016 14:40:57 MESZ, schrieb s...@apache.org:
> >>Author: sebb
> >>Date: Tue Apr 19 12:40:57 2016
> >>New Revision: 1739924
> >>
> >>URL: http://svn.apache.org/viewvc?rev=1739924=rev
> >>Log:
> >>Field can still be final
> >>
> >>Modified:
> >>jmeter/trunk/src/core/org/apache/jmeter/logging/LogkitLoggerAdapter.java
> >>
> >>Modified:
> >>jmeter/trunk/src/core/org/apache/jmeter/logging/LogkitLoggerAdapter.java
> >>URL:
> >>
> http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmeter/logging/LogkitLoggerAdapter.java?rev=1739924=1739923=1739924=diff
>
> >>==
> >>---
> >>jmeter/trunk/src/core/org/apache/jmeter/logging/LogkitLoggerAdapter.java
> >>(original)
> >>+++
> >>jmeter/trunk/src/core/org/apache/jmeter/logging/LogkitLoggerAdapter.java
> >>Tue Apr 19 12:40:57 2016
> >>@@ -32,10 +32,8 @@ import org.slf4j.helpers.MessageFormatte
> >>  */
> >>public class LogkitLoggerAdapter extends MarkerIgnoringBase implements
> >>Serializable {
> >>
> >>-transient Logger logger;
> >>-/**
> >>- *
> >>- */
> >>+final transient Logger logger;
> >
> > Is this really valid? When an object of This class gets deserialized,
> its transient fields will not be initialized. But they are marked as non
> changing and thus stay in that state.
> >
> > Looks strange to me.
>
> That's one reason why I asked if it needed to be Serializable.
>
> > Felix
> >
> >>+
> >> private static final long serialVersionUID = -122848886791823355L;
> >>
> >> /**
> >>@@ -44,6 +42,7 @@ public class LogkitLoggerAdapter extends
> >> @Deprecated // only for Unit test usage
> >> public LogkitLoggerAdapter() {
> >> super();
> >>+this.logger = null;
> >> }
> >>
> >> LogkitLoggerAdapter(org.apache.log.Logger logkitLogger) {
> >
>



-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: Customizing JMeter

[UBIK LOAD PACK Support]

JMeter already let's you do that using :
http://jmeter.apache.org/usermanual/realtime-results.html
And *GraphiteBackendListenerClient:*
http://jmeter.apache.org/usermanual/component_reference.html#Backend_Listener


Regards

On Wed, Mar 23, 2016 at 3:23 PM, Krishna Kanth 
wrote:

> Hi All,
>
> I am looking to customize JMeter to be able to send data to InfluxDB or a
> similar Time Series DB
>
> The catch is that I want to send the data to a specific User which would be
> created in the DB.
>
> The DB user would either be already created or would be created in real
> time.
>
> How do I start customizing or Where should I be looking to get tweaking the
> code.
>
> Thanks,
> ~K
>



-- 

Regards
Ubik Load Pack  Team
Follow us on Twitter 


Cordialement
L'équipe Ubik Load Pack 
Suivez-nous sur Twitter 

Re: GenericController#next() and GenericController#isDone()

[UBIK LOAD PACK Support]

Hello Sebb,
Thanks for answer.

So you would say it is not a contract ? Although it seems logical.

If so, the change made by this commit (the one related to the
JMeterThread#run() only):
- http://svn.apache.org/viewvc?view=revision=1720004

Should be reverted to previous state as behaviour will be different between
2.13 and 3.0.

With 2.13:

   - If controller.next() returns null and controller.isDone() returns
   false, the inner loop is exited but the outer loop will not be, if next
   call to controller.next() returns true the inner loop restarts and run() is
   not exited


With 3.0 as of current nightly build:

   - If controller.next() returns null and controller.isDone() returns
   false, the loop is exited as long as run



This probably explains the bug reported  by Andrei Pokhilko:

   - https://bz.apache.org/bugzilla/show_bug.cgi?id=59133



Regards



On Mon, Mar 14, 2016 at 4:15 PM, sebb <seb...@gmail.com> wrote:

> That area is by far the most complicated part of the JMeter code.
>
> It would need very careful examination and lots of unit tests to
> determine if that is a valid assumption.
>
> I would start by amending your copy of the code to log a warning if
> the assumption is not true.
> Then try it with as many different test cases as you have.
>
>
> On 14 March 2016 at 14:57, UBIK LOAD PACK Support
> <supp...@ubikloadpack.com> wrote:
> > Hello,
> > Because until current nightly, it was not enforced so it was possible to
> > write such code.
> >
> > Regards
> >
> > On Monday, March 14, 2016, UBIK LOAD PACK Support <
> supp...@ubikloadpack.com
> > <javascript:_e(%7B%7D,'cvml','supp...@ubikloadpack.com');>> wrote:
> >
> >> Hello,
> >> Can we consider it a contract that:
> >>
> >>-  if GenericController#next()  returns null,
> >>GenericController#isDone() must return true ?
> >>
> >>
> >> Thank you
> >>
> >> Regards
> >>
> >
> >
> > --
> >
> > Regards
> > Ubik Load Pack <http://ubikloadpack.com> Team
> > Follow us on Twitter <http://twitter.com/ubikloadpack>
> >
> >
> > Cordialement
> > L'équipe Ubik Load Pack <http://ubikloadpack.com>
> > Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
>

GenericController#next() and GenericController#isDone()

[UBIK LOAD PACK Support]

Hello,
Because until current nightly, it was not enforced so it was possible to
write such code.

Regards

On Monday, March 14, 2016, UBIK LOAD PACK Support <supp...@ubikloadpack.com
<javascript:_e(%7B%7D,'cvml','supp...@ubikloadpack.com');>> wrote:

> Hello,
> Can we consider it a contract that:
>
>-  if GenericController#next()  returns null,
>GenericController#isDone() must return true ?
>
>
> Thank you
>
> Regards
>


-- 

Regards
Ubik Load Pack <http://ubikloadpack.com> Team
Follow us on Twitter <http://twitter.com/ubikloadpack>


Cordialement
L'équipe Ubik Load Pack <http://ubikloadpack.com>
Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>

GenericController#next() and GenericController#isDone()

[UBIK LOAD PACK Support]

Hello,
Can we consider it a contract that:

   -  if GenericController#next()  returns null, GenericController#isDone()
   must return true ?


Thank you

Regards

Re: svn commit: r1732944 - in /jmeter/trunk: bin/jmeter.properties src/core/org/apache/jmeter/JMeter.java src/core/org/apache/jmeter/report/dashboard/HtmlTemplateExporter.java xdocs/changes.xml xdocs/

[UBIK LOAD PACK Support]

Hello sebb,

Some notes inline below  from an external eye.

Regards

On Tue, Mar 1, 2016 at 11:08 AM, sebb  wrote:

> On 1 March 2016 at 06:11, Philippe Mouawad 
> wrote:
> > On Monday, February 29, 2016, sebb  wrote:
> >
> >> On 29 February 2016 at 20:57,  >
> wrote:
> >> > Author: pmouawad
> >> > Date: Mon Feb 29 20:57:32 2016
> >> > New Revision: 1732944
> >> >
> >> > URL: http://svn.apache.org/viewvc?rev=1732944=rev
> >> > Log:
> >> > Bug 58986 - Report/Dashboard reuses the same output directory
> >> > Bugzilla Id: 58986
> >> >
> >> > Modified:
> >> > jmeter/trunk/bin/jmeter.properties
> >> > jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
> >> >
> >>
> jmeter/trunk/src/core/org/apache/jmeter/report/dashboard/HtmlTemplateExporter.java
> >> > jmeter/trunk/xdocs/changes.xml
> >> > jmeter/trunk/xdocs/usermanual/generating-dashboard.xml
> >> >
> >> > Modified: jmeter/trunk/bin/jmeter.properties
> >> > URL:
> >>
> http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.properties?rev=1732944=1732943=1732944=diff
> >> >
> >>
> ==
> >> > --- jmeter/trunk/bin/jmeter.properties (original)
> >> > +++ jmeter/trunk/bin/jmeter.properties Mon Feb 29 20:57:32 2016
> >> > @@ -1262,6 +1262,7 @@ jmeter.reportgenerator.exporter.html.cla
> >> >
> >>
> #jmeter.reportgenerator.exporter.html.property.template_dir=report-template
> >> >
> >> >  # Sets the destination directory for generated html pages.
> >> > +# This will override the value set through -o command line option
> >> >
> #jmeter.reportgenerator.exporter.html.property.output_dir=report-output
> >> >
> >> >  # Indicates which graph series are filtered (regular expression)
> >> >
> >> > Modified: jmeter/trunk/src/core/org/apache/jmeter/JMeter.java
> >> > URL:
> >>
> http://svn.apache.org/viewvc/jmeter/trunk/src/core/org/apache/jmeter/JMeter.java?rev=1732944=1732943=1732944=diff
> >> >
> >>
> ==
> >> > --- jmeter/trunk/src/core/org/apache/jmeter/JMeter.java (original)
> >> > +++ jmeter/trunk/src/core/org/apache/jmeter/JMeter.java Mon Feb 29
> >> 20:57:32 2016
> >> > @@ -110,6 +110,9 @@ public class JMeter implements JMeterPlu
> >> >  public static final String HTTP_PROXY_USER = "http.proxyUser"; //
> >> $NON-NLS-1$
> >> >
> >> >  public static final String JMETER_NON_GUI = "JMeter.NonGui"; //
> >> $NON-NLS-1$
> >> > +
> >> > +public static final String JMETER_REPORT_OUTPUT_DIR_PROPERTY =
> >> > +"jmeter.reportgenerator.outputdir"; //$NON-NLS-1$
> >> >
> >> >  // If the -t flag is to "LAST", then the last loaded file (if
> any)
> >> is used
> >> >  private static final String USE_LAST_JMX = "LAST";
> >> > @@ -134,6 +137,7 @@ public class JMeter implements JMeterPlu
> >> >  private static final int VERSION_OPT= 'v';// $NON-NLS-1$
> >> >  private static final int REPORT_GENERATING_OPT  = 'g';//
> $NON-NLS-1$
> >> >  private static final int REPORT_AT_END_OPT  = 'e';//
> $NON-NLS-1$
> >> > +private static final int REPORT_OUTPUT_FOLDER_OPT  = 'o';//
> >> $NON-NLS-1$
> >> >
> >> >  private static final int SYSTEM_PROPERTY= 'D';// $NON-NLS-1$
> >> >  private static final int JMETER_GLOBAL_PROP = 'G';// $NON-NLS-1$
> >> > @@ -217,7 +221,10 @@ public class JMeter implements JMeterPlu
> >> >  "generate report dashboard only"),
> >> >  new CLOptionDescriptor("reportatendofloadtests",
> >> >  CLOptionDescriptor.ARGUMENT_DISALLOWED,
> >> REPORT_AT_END_OPT,
> >> > -"generate report dashboard after load test")
> >> > +"generate report dashboard after load test"),
> >> > +new CLOptionDescriptor("reportoutputfolder",
> >> > +CLOptionDescriptor.ARGUMENT_REQUIRED,
> >> REPORT_OUTPUT_FOLDER_OPT,
> >> > +"output folder for report dashboard"),
> >> >  };
> >> >
> >> >  public JMeter() {
> >> > @@ -400,6 +407,31 @@ public class JMeter implements JMeterPlu
> >> >  startGui(testFile);
> >> >  startOptionalServers();
> >> >  } else {
> >> > +CLOption reportOutputFolderOpt = parser
> >> > +
> .getArgumentById(REPORT_OUTPUT_FOLDER_OPT);
> >> > +if(reportOutputFolderOpt != null) {
> >> > +String reportOutputFolder =
> >> parser.getArgumentById(REPORT_OUTPUT_FOLDER_OPT).getArgument();
> >> > +File reportOutputFolderAsFile = new
> >> File(reportOutputFolder);
> >> > +// We check folder does not exist or it is
> empty
> >> > +if(!reportOutputFolderAsFile.exists() ||
> >> > +// folder 

Re: UBIKLOADPACK JSON PLUGIN DONATION TO APACHE JMETER

[UBIK LOAD PACK Support]

Hi Felix, All,

We submitted:

   - https://github.com/apache/jmeter/pull/28

Shall we create a Bugzilla ?

Regards
UbikLoadPack Team
@ubikloadpack

On Thu, Oct 15, 2015 at 11:31 AM, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

> Am 14.10.2015 um 21:05 schrieb UBIK LOAD PACK Support:
>
>> Hello Dev Team,
>> I am contacting you to know if you would be interested in integrating our
>> JSON Plugin within Core JMeter.
>>
> I think json support directly in jmeter is needed.
>
>>
>> Its features are shown on our blog, I didn't put any link because none of
>> my 2 previous mails were received on dev mailing list.
>>
> I looked at the blog post for which Rainer sent the link.
>
> The features look good. What "language" is the extraction part?


It's based on json-path : http://goessner.net/articles/JsonPath/


> Is there any standard like xpath/xquery for xml?
>
Kind of

>
>>
>> Currently plugin uses com.ubikingenierie.loadpack package, but it would be
>> donated with a package you would choose:
>>
>> - org.apache.jmeter.json for example
>>
> Renaming a package is really simple with modern IDEs, so that would be a
> no-brainer.
>
Done within PR.

>
>>
>> If you are OK and wish to integrate it, we would submit a PR on Github so
>> that you can review it and potentially provide some patches before
>> integration in JMeter.
>>
> Probably a good idea.
>
Done

>
> Regards,
>  Felix
>
> Your feedback is welcome.
>>
>>
>> We think this feature would be very useful for Web Application testing
>> where JSON format is becoming a very frequently used format for Rest
>> Webservices for example.
>>
>> Thanks
>> Regards
>> Ubik Load Pack Team
>> @ubikloadpack
>>
>>
>

Re: UBIKLOADPACK JSON PLUGIN DONATION TO APACHE JMETER

[UBIK LOAD PACK Support]

On Thu, Oct 15, 2015 at 10:21 AM, sebb <seb...@gmail.com> wrote:

> On 14 October 2015 at 23:07, Milamber <milam...@apache.org> wrote:
> >
> > Thanks for your proposal.
> >
> > Seems a good thing to add this plugin on JMeter but we need to known the
> new
> > functionality(ies) of this plugin? that is an new listener or sampler?
> >
> > Can you confirm that this plugin don't have some dependencies against the
> > Apache License v2 (like GPL) for the distribution?
> >
> > I thinks that Ubik Load Pack have already sign the CCLA and can
> contribute
> > to Apache projects?
> >
> > I thinks that after your PR (or other way of submission), a vote (in
> Apache
> > way) must be done to accept or not this plugin.
> > (example:
> >
> http://mail-archives.us.apache.org/mod_mbox/cloudstack-dev/201504.mbox/%3CCAEJ3w4W=_4ue+vidf3uytt_zywci4h-dfk9s+myp6kwgewx...@mail.gmail.com%3E
> > )
> >
> > @Sebb can you confirm the good way to the donation, thanks.
> >
>
> There are several aspects to incorporating a sizeable chunk of code:
> - is it in scope for the project?
> We think it is absolutely in it. At the time we created it because core
> JMeter was lacking it and we faced a lot of applications that used JSON
> where Regexp didn't do the job.
>
You can see on our page  Our Customers (bottom) that customers found it
very useful.

>
> - is there sufficient community within the project to maintain the
>> code going forward?
>>
> We would help as we already did, and anyway it's not a big piece of code
(5 classes)

>
> - does it have documentation and tests?
>
It would have documentation and tests as JMX as you  do in the project.

>
> - is it well-written enough to be maintainable?
>
We think it is :-) , but it's up to the Apache JMeter Team to decide

> - does it affect backwards compatibility?
>
No

> - does it need IP clearance?
>
What is IP clearance ? is it Intellectual Property, in this case , as with
our other contributions we have signed a CCLA and would give all IP.


>
> As to IP clearance, large chunks of code may need to go via the
> Incubator and a code grant.
> In this case, I don't know; I suggest someone asks on the Incubator
> list once we have satisfied ourselves that the other criteria have
> been met.
>
> >
> > On 14/10/2015 20:05, UBIK LOAD PACK Support wrote:
> >>
> >> Hello Dev Team,
> >> I am contacting you to know if you would be interested in integrating
> our
> >> JSON Plugin within Core JMeter.
> >>
> >> Its features are shown on our blog, I didn't put any link because none
> of
> >> my 2 previous mails were received on dev mailing list.
> >>
> >>
> >> Currently plugin uses com.ubikingenierie.loadpack package, but it would
> be
> >> donated with a package you would choose:
> >>
> >> - org.apache.jmeter.json for example
> >>
> >>
> >> If you are OK and wish to integrate it, we would submit a PR on Github
> so
> >> that you can review it and potentially provide some patches before
> >> integration in JMeter.
> >> Your feedback is welcome.
> >>
> >>
> >> We think this feature would be very useful for Web Application testing
> >> where JSON format is becoming a very frequently used format for Rest
> >> Webservices for example.
> >>
> >> Thanks
> >> Regards
> >> Ubik Load Pack Team
> >> @ubikloadpack
> >>
> >
>

Re: Add to JMeter modification

[UBIK LOAD PACK Support]

Hi,
Just open on dev list a discussion per feature with a clear title and if
possible open a Pull Request for it on github or attach a patch to bugzilla.

Regards

On Tue, Jul 21, 2015 at 11:34 AM, Maxime Chassagneux 
maxime.chassagn...@gmail.com wrote:

 Hi,

 Since many mounth I made some modifications on JMeter source to add some
 features I need.
 Now I would like to know how I could discuss with the community in order to
 add it on the trunk source.

 Many modifications I made are simple to report but I'm not a good
 developper and I think a review is necessary.

 How do I proceed to do this ? First I have to explain all modifications one
 by one with the reason ?

 Best reagrd.

Re: HTTPClient4 missing filename for file uploads

[UBIK LOAD PACK Support]

AFAIU, setting name would not break existing behaviour and fix the
situation right ?


On Fri, May 15, 2015 at 11:50 AM, Andrey Pokhilko a...@ya.ru wrote:

 I investigated it more. It happened that with stock httpmime-4.2.6 it
 works, but user has upgraded HTTPComponents libraries to support custom
 plugins. Since version 4.3 of httpmime they deprecated that constructor
 and don't have automatic logic to set filename from file if filename is
 null.

 This seems to be a deadlock situation for user unless we're making a
 step towards custom plugin users and will call different super-constructor.

 Sebb, what's your opinion?

 Andrey Pokhilko

 On 05/15/2015 12:05 AM, sebb wrote:
  OK, it does look like a bug, but according to the source for http mime
  4.2.6 if filename is null it uses file.getName() anyway, so AFAICT
  your proposed fix would have no effect.
 
  This needs further investigation.
 
  On 14 May 2015 at 19:00, Andrey Pokhilko a...@ya.ru wrote:
  Java implementation does well, providing required parameter:
 
  POST http://localhost/api/file/upload/
 
  POST data:
  -7d159c1302d0y0
  Content-Disposition: form-data; name=jtl_file;
  *filename=011f07efb04762311137.jtl.gz *
  Content-Type: application/octet-stream
  Content-Transfer-Encoding: binary
 
  actual file content, not shown here
  -7d159c1302d0y0--
 
 
  Andrey Pokhilko
 
  On 05/14/2015 07:57 PM, sebb wrote:
  On 14 May 2015 at 17:36, Andrey Pokhilko a...@ya.ru wrote:
  Hi,
 
  I'm trying to resolve a user issue when he claims that file upload
  scenario is missing filename parameter. When I use HTTPClient4 I get
  failing file upload request:
 
  POST http://localhost/api/file/upload/
 
  POST data:
  --cJfjtjR2_380MwSzTd_SQdQfG51aS5D
  Content-Disposition: form-data; name=jtl_file;
  Content-Type: application/octet-stream
 
  actual file content, not shown here
  --cJfjtjR2_380MwSzTd_SQdQfG51aS5D--
 
  While for HTTPClient3.1 I have successful request with:
 
  POST http://localhost/api/file/upload/
 
  POST data:
  --wqkPl1L84AqGtph2Cgr79xYPJVMxntF4IJ
  Content-Disposition: form-data; name=jtl_file;
  *filename=011f023437.jtl.gz *
  Content-Type: application/octet-stream
  Content-Transfer-Encoding: binary
 
  actual file content, not shown here
  --wqkPl1L84AqGtph2Cgr79xYPJVMxntF4IJ--
 
 
  After digging into HTTPClient4 implementation I found that we're
 really
  do not pass filename parameter to underlying http library. This is
 easy
  to fix by changing this line:
 
 https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L966
 
  from
 
  super(file, mimeType);
 
  into:
 
  super(file, file.getName(), mimeType, null);
 
 
  Questions:
 
   1. Is that a bug? Maybe a known one? Or this is intended behavior.
  It would be useful to know what the Java implementation does.
 
   2. Should I fix this as demonstrated (if this is a bug)?
 
  --
  Andrey Pokhilko
 
 
 




-- 

Regards
Ubik Load Pack http://ubikloadpack.com Team
Follow us on Twitter http://twitter.com/ubikloadpack


Cordialement
L'équipe Ubik Load Pack http://ubikloadpack.com
Suivez-nous sur Twitter http://twitter.com/ubikloadpack

User manual index is broken

[UBIK LOAD PACK Support]

Hello,
There is an issue in documentation.
To. reproduce:
- Select user manual
- Select Real time results
- Click prev, you get 404

If you select the next chapter (best-practices) , real-time results is a
phantom.

Regards

-- 

Regards
Ubik Load Pack http://ubikloadpack.com Team
Follow us on Twitter http://twitter.com/ubikloadpack


Cordialement
L'équipe Ubik Load Pack http://ubikloadpack.com
Suivez-nous sur Twitter http://twitter.com/ubikloadpack

Re: [VOTE] Release JMeter 2.13 RC1

[UBIK LOAD PACK Support]

+1 for new website as per:
http://people.apache.org/~fschumacher/jmeter/changes.html

Except for some icon overlapping between apache feather and jmeter one on
iphone it looks rather nice and anyway much better than

On Friday, March 6, 2015, Philippe Mouawad philippe.moua...@gmail.com
wrote:

 Hi Felix,
 Good catch.
 For now collectD would be more of a way to monitor servers and using
 InfluxDB as single Backend using collectd-proxy:
 - https://wooster.checkmy.ws/2014/08/influxdb-collectd-grafana/
 But maybe this is out of JMeter docs scope. Should it be mentioned ?

 I fixed docs in last 2 commits, removed for now mention of Collectd.

 Regarding your future implementation of CollectD backend, maybe we should
 rename GraphiteMetricsSender to MetricsSender and you would only implement
 a  CollectdMetricsSender.

 Regards
 Philippe



 On Fri, Mar 6, 2015 at 7:18 AM, Felix Schumacher 
 felix.schumac...@internetallee.de
 javascript:_e(%7B%7D,'cvml','felix.schumac...@internetallee.de');
 wrote:



 Am 5. März 2015 00:12:03 MEZ, schrieb Philippe Mouawad 
 philippe.moua...@gmail.com
 javascript:_e(%7B%7D,'cvml','philippe.moua...@gmail.com');:
 Hi,
 Thanks milamber.
 I updated changes.xml with new and noteworthy notes on connectTime and
 retry in distributed mode as per Andrei resuest.
 
 I also rewrote the webservice tutorial to make it up to date as
 Webservice
 Sampler has been deprecated since 2 versions. Maybe other tutorials
 should
 be refreshed to mention at least other listener than Graph Results
 which
 leads to GUI mode usage.
 
 I finally finished for now work on Graphite Backend Listener and
 updated
 doc for InfluxDB and metrics.
 If anybody has time to update Collectd and Graphite parts it would be
 great.

 For usage with collectd we would have to include another sender plugin I
 believe. You probably read that collectd had a Graphite plugin. That plugin
 is wrie only. So mache we should remove that mentioning and wait for
 someone (probably me) to implement the sender.

 Philippe suggested also, that I should commit the website patches for
 2.13. Any thoughts on this?

 Regards
 Felix
 
 For now I won't commit any feature, only docs and any bug I find.
 
 Thanks for RM.
 Regards
 
 On Wednesday, March 4, 2015, Milamber milam...@apache.org
 javascript:_e(%7B%7D,'cvml','milam...@apache.org'); wrote:
 
  Hello,
 
  This vote is cancelled, some fixes on the documentation must be done.
 
  The next RC2 will made this new Saturday.
 
  Please don't commit new features on trunk. In place make a lot of
 tests
  on the RC1 to find bug or issue(s).
 
  Milamber
 
 
  On 03/03/2015 23:57, Milamber wrote:
   Hello,
  
   The first release candidate for JMeter 2.13 (r1663807) has been
   prepared, and your votes are solicited.
  
   This release brings some new features and fixes
   some bugs.
  
   If you can, some tests of this release candidate (load tests and/or
   functional tests) with Java 6/7/8 on Linux/Windows/Mac OS on
 changes are
   welcome.
  
   You can read the New and Noteworthy section with some screenshots
 to
   illustrate improvements and full list of changes at:
   http://people.apache.org/~milamber/jmeter-2.13RC1/docs/changes.html
  
   JMeter is a Java desktop application designed to load test
 functional
   behavior and measure performance. The current version is targeted
 at
   Java 6+.
  
   Archives/hashes/sigs:
  
   https://dist.apache.org/repos/dist/dev/jmeter/v2.13_RC1/
  
   RAT report:
  
  
 
 
 http://people.apache.org/~milamber/jmeter-2.13RC1/dist/rat-report-jmeter-2.13RC1.txt
  
   (please note: you need build the latest version of RAT:
 0.12-SNAPSHOT to
   generate the report. Reason unknown, but the version 0.11 don't
 work
   (loop running indefinitely))
  
   MD5 hashes of archives for this vote:
  
   15ddc74560f71118a6afdaef41a800a6 *apache-jmeter-2.13.tgz
   d4280b12bea9e09769075fb3d4861deb *apache-jmeter-2.13.zip
   45723fba94479016a14e9834817ec2d4 *apache-jmeter-2.13_src.tgz
   f04c55fa5c12b281b8060248d4437325 *apache-jmeter-2.13_src.zip
  
   Site Docs are here:
   http://people.apache.org/~milamber/jmeter-2.13RC1/docs/
  
   Maven staging repo is accessible here:
  
 
 
 https://repository.apache.org/content/repositories/orgapachejmeter-1004/org/apache/jmeter/
  
   Tag:
   http://svn.apache.org/repos/asf/jmeter/tags/v2_13_RC1/
  
   Keys are here:
   http://www.apache.org/dist/jmeter/KEYS
  
   N.B.
   To download the dependencies: ant download_jars
  
   To create the jars and test JMeter: ant package test.
  
   JMeter 2.13 requires Java 6 or later to run.
  
   Some known issues and incompatible changes are listed on changes
 page.
   http://people.apache.org/~milamber/jmeter-2.13RC1/docs/changes.html
  
  
   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 

Re: httpClient.getConnectionManager() performance with HTTP only

[UBIK LOAD PACK Support]

Hi Oleg,
Is there some sample somewhere showing how to implement this ?

Thanks
Regards
@ubikloadpack
On Thu, May 15, 2014 at 10:39 AM, Oleg Kalnichevski ol...@apache.org
wrote:

 On Wed, 2014-05-14 at 19:46 +0100, sebb wrote:
  On 14 May 2014 12:28, Oleg Kalnichevski ol...@apache.org wrote:

 ...

   Issue is not present in HTTPCLient 3.1
  
   Philippe
  
   If HttpClient is used correctly, this code should only be executed only
   once. Why does JMeter create more than one instance of HttpClient?
 
  We currently create an instance for each instance of different proxy
  settings and each protocol and each authority, because the client is
  created with these settings.
 
  This is also done for each thread.
 
  IIRC, this was necessary originally. We have not rewritten the code
  yet to use all the latest features.
 

 I see. For the time what you can do is to use a custom SSL socket
 factory that lazily initializes SSL context when requested for the first
 time. This is exactly what HC 3.1 does. It will be somewhat slower given
 that one would need to mutex to synchronize access to the initialization
 code.

 Oleg

   Oleg
  
 
  -
  To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
  For additional commands, e-mail: httpclient-users-h...@hc.apache.org
 

Re: How to commit a patch for jmeter?

[UBIK LOAD PACK Support]

Hello,
You best option is to attach your patch (in unified format ) to the
bugzilla or a new one your create mentionning it is related to 56197
https://issues.apache.org/bugzilla/show_bug.cgi?id=56197.
Ensure your run ant test to check that all Unit Tests pass after your
change.
http://jmeter.apache.org/issues.html
Regards
@ubikloadpack

On Wed, Oct 22, 2014 at 4:13 PM, 黄吉浩 13651877...@163.com wrote:


 sorry for this basic question, but I looked in jmeter.apache.org and read
 'Contribute back to the community', but didn't find answer.
 there is  Bug 56197
 https://issues.apache.org/bugzilla/show_bug.cgi?id=56197
 part of the bug is:

 2) The file will not be sent if the UI is on the 'Body Data' tab, even if
 this tab has no content.  Simply switching to the Parameters tab causes the
 file to be included.

 I meet this bug in my work either, so I create a patch in eclipse,  I
 tested it worked, I think I fixed it.
 the patch is as following, But I don't know how to submit this patch to
 the svn reposity?

 Index:
 src/protocol/http/org/apache/jmeter/protocol/http/config/gui/UrlConfigGui.java
 ===
 ---
 src/protocol/http/org/apache/jmeter/protocol/http/config/gui/UrlConfigGui.java
 (revision 1633145)
 +++
 src/protocol/http/org/apache/jmeter/protocol/http/config/gui/UrlConfigGui.java
 (working copy)
 @@ -203,9 +203,11 @@
   * On retrival, CRLF is converted back to LF for storage in
 the text field.
   * See
   */
 -HTTPArgument arg = new HTTPArgument(,
 text.replaceAll(\n,\r\n), false);
 -arg.setAlwaysEncoded(false);
 -args.addArgument(arg);
 +if (!text.replaceAll(\n,\r\n).equals()){
 +   HTTPArgument arg = new HTTPArgument(,
 text.replaceAll(\n,\r\n), false);
 +   arg.setAlwaysEncoded(false);
 +   args.addArgument(arg);
 +}
  } else {
  args = (Arguments) argsPanel.createTestElement();
  HTTPArgument.convertArgumentsToHTTP(args);

Why do Functions that only have values as instance variable synchronize execute ?

[UBIK LOAD PACK Support]

Hi,
Reviewing code of Functions in JMeter we don't understand why Functions
that only have values as instance variable (so Beanshell or StringFromFile
or IterationCounter (which could be improved to avoid it) are not
concerned) synchronize on execute.

It appears values instance variable is initialized within
StandardJMeterEngine thread and then only accessed in read mode by
JMeterThread

But it is true that if synchronized is removed then CompoundVariable is
accessed by multi threads but it seems it uses thread related data so it
should be OK.



--

Re: Enable saving thread counts by default?

[UBIK LOAD PACK Support]

Hi,
Answering on behalf of Philippe as we had some discussion on this.

What you can do is make the change and run the Ant task called test.
properties used by test are located in bin/testfiles/jmetertest.properties.

You will get tests failures because all generated files will have an
additional field (threads) , as some test compare result files with
expected result files, they will logically fail.
So nothing complex in the change just some work to do to fix either the
test results or the properties used by test.
Maybe this can be discussed here with PMC.

Regards

On Fri, Sep 26, 2014 at 3:18 PM, Andrey Pokhilko a...@ya.ru wrote:

 Thanks for the link, Philippe.

 What prevents this change from being done? Is there really complex tests
 that break on this change? How can I help? (I'm not familiar with
 JMeter's source tests, unfortunately).

 Andrey Pokhilko

 On 09/26/2014 02:05 PM, Philippe Mouawad wrote:
  Hi Andrey,
  This has been discussed in a previous thread, see:
 
 http://mail-archives.apache.org/mod_mbox/jmeter-dev/201404.mbox/%3CCAOGo0VaiM=TdW_Fj9fE1De4W8jao8ox5ELTAFVHTyN=5sy0...@mail.gmail.com%3E
 
  I think it is agreed upon by PMC members, changing this just breaks some
  Tests that need to be fixed.
 
 
 




-- 

Regards
Ubik Load Pack http://ubikloadpack.com Team
Follow us on Twitter http://twitter.com/ubikloadpack


Cordialement
L'équipe Ubik Load Pack http://ubikloadpack.com
Suivez-nous sur Twitter http://twitter.com/ubikloadpack