buildbot success in on jmeter-trunk

[buildbot]

The Buildbot has detected a restored build on builder jmeter-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/jmeter-trunk/builds/741

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: hemera_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-jmeter-commit' 
triggered this build
Build Source Stamp: [branch jmeter/trunk] 1733419
Blamelist: pmouawad

Build succeeded!

Sincerely,
 -The Buildbot

Re: svn commit: r1732939 - in /jmeter/trunk: bin/ src/core/org/apache/jmeter/gui/util/ src/protocol/http/org/apache/jmeter/protocol/http/config/gui/ src/protocol/http/org/apache/jmeter/protocol/http/s

[Philippe Mouawad]

Hi,
Thanks for reply.
Don'twe need to introduce a new config property to distinguish between
methods with entity (put, post) and methods without (get, head ...)

Thanks

On Thursday, March 3, 2016, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
>
> Am 2. März 2016 22:52:55 MEZ, schrieb Philippe Mouawad <
> philippe.moua...@gmail.com >:
> >Hi Felix,
> >Do we delay this one for 3.1 ?
>
> No. I will give it another try in the next days. I think it can be solved
> easily.
>
> Felix
>
> >Thanks
> >
> >On Mon, Feb 29, 2016 at 8:48 PM, Felix Schumacher <
> >felix.schumac...@internetallee.de > wrote:
> >
> >> Am 29.02.2016 um 20:39 schrieb Felix Schumacher:
> >>
> >>> Am 29.02.2016 um 20:36 schrieb fschumac...@apache.org :
> >>>
>  Author: fschumacher
>  Date: Mon Feb 29 19:36:14 2016
>  New Revision: 1732939
> 
>  URL: http://svn.apache.org/viewvc?rev=1732939=rev
>  Log:
>  Revert changes made by r1732937
>  At least HTTPHC4Impl uses HttpWebDav#isWebdavMethod in a way, that
> >is
>  incompatible to this change.
> 
>  Was: HTTP Request : Make Method field editable so that additional
>  methods (Webdav) can be added easily
> 
>  Bugzilla Id: 59083
> 
>  Modified:
>   jmeter/trunk/bin/jmeter.properties
> 
> >jmeter/trunk/src/core/org/apache/jmeter/gui/util/JLabeledRadioI18N.java
>  (props changed)
> 
> 
>
> >jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/config/gui/UrlConfigGui.java
> 
> 
>
> >jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java
> 
> 
>
> >jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
> 
> 
>
> >jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HttpWebdav.java
>   jmeter/trunk/xdocs/changes.xml
>   jmeter/trunk/xdocs/images/asf-logo.gif   (props changed)
> 
> >>> I wonder how I got this change in here. Will try to get the orginal
> >(new)
> >>> logo in again.
> >>>
> >> Seems the logo wasn't replaced by my revert. Should we delete the
> >image?
> >> It doesn't seem to be used.
> >>
> >> Regards,
> >>  Felix
> >>
>
>

-- 
Cordialement.
Philippe Mouawad.

Re: svn commit: r1732939 - in /jmeter/trunk: bin/ src/core/org/apache/jmeter/gui/util/ src/protocol/http/org/apache/jmeter/protocol/http/config/gui/ src/protocol/http/org/apache/jmeter/protocol/http/s

[Felix Schumacher]

Am 2. März 2016 22:52:55 MEZ, schrieb Philippe Mouawad 
:
>Hi Felix,
>Do we delay this one for 3.1 ?

No. I will give it another try in the next days. I think it can be solved 
easily.

Felix

>Thanks
>
>On Mon, Feb 29, 2016 at 8:48 PM, Felix Schumacher <
>felix.schumac...@internetallee.de> wrote:
>
>> Am 29.02.2016 um 20:39 schrieb Felix Schumacher:
>>
>>> Am 29.02.2016 um 20:36 schrieb fschumac...@apache.org:
>>>
 Author: fschumacher
 Date: Mon Feb 29 19:36:14 2016
 New Revision: 1732939

 URL: http://svn.apache.org/viewvc?rev=1732939=rev
 Log:
 Revert changes made by r1732937
 At least HTTPHC4Impl uses HttpWebDav#isWebdavMethod in a way, that
>is
 incompatible to this change.

 Was: HTTP Request : Make Method field editable so that additional
 methods (Webdav) can be added easily

 Bugzilla Id: 59083

 Modified:
  jmeter/trunk/bin/jmeter.properties

>jmeter/trunk/src/core/org/apache/jmeter/gui/util/JLabeledRadioI18N.java
 (props changed)


>jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/config/gui/UrlConfigGui.java


>jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java


>jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java


>jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HttpWebdav.java
  jmeter/trunk/xdocs/changes.xml
  jmeter/trunk/xdocs/images/asf-logo.gif   (props changed)

>>> I wonder how I got this change in here. Will try to get the orginal
>(new)
>>> logo in again.
>>>
>> Seems the logo wasn't replaced by my revert. Should we delete the
>image?
>> It doesn't seem to be used.
>>
>> Regards,
>>  Felix
>>

Re: About including Groovy

[Philippe Mouawad]

On Thursday, March 3, 2016, sebb  wrote:

> On 2 March 2016 at 22:06, Philippe Mouawad  > wrote:
> > Hello,
> > For information , we had a vote on our twitter account:
> > - https://twitter.com/apachejmeter/status/702590631571496961
> >
> > Results are the following:
> > Participation : 100 Votes
> > - 9% NO
>
> What reasons were given for saying no?


People don't give an explanation for their vote on twitter.
But you can read by clicking on the link above  the replies to the voting
tweet to see 2 or 3 reasons for no and the same for yes.

>
> > - 91% YES
> >
> >
> > This has no particular value except to give a kind of feeling about it.
> >
> > From this discussion it appears we have a move towards including it.
> >
> > Unless there is a NOGO I will start bundling 2.4.6 groovy-all in jmeter
> > tomorrow evening.
> >
> > Regards
> > Philippe
> >
> > On Thu, Feb 25, 2016 at 3:53 AM, Vladimir Sitnikov <
> > sitnikov.vladi...@gmail.com > wrote:
> >
> >> TL;DR:  +1 for bundling proper groovy.jar with JMeter.
> >>
> >> Alternative approach would be some kind of "online store to download
> >> JMeter plugins". I am not sure if that can be done in a reasonable
> >> time frame though.
> >>
> >> In my opinion, there are number of advantages for bundling Groovy:
> >> 1) I can easily get a "online groovy console", so I can easily check
> >> if -3.abs() returns 3 or -3. That is exactly JMeter users have to do.
> >> JMeter (as IDE) does not provide ability to execute small parts of
> >> code, thus users have to use their minds (or Google or whatever) to
> >> craft code that works. I claim using Groovy online console helps a
> >> lot. With BeanShell you never know if your code will work until you
> >> run it.
> >>
> >> groovyconsole.appspot.com just blows BeanShell out of the water.
> >>
> >> 2) "Groovy is in active development, thus everybody would have to
> >> constantly update groovy.jar anyway" is not justified.
> >> Even though there will be new groovy.jar releases, it is unlikely
> >> users will use cutting-edge features of Groovy language in JMeter
> >> scenarios.
> >>
> >> I think the main usage would be just regular boilerplate code, so
> >> non-experts would never be able to write Groovy code that requires the
> >> latest groovy.jar to execute.
> >>
> >> 3) Even though I prefer not to use Groovy, I see no better replacement
> >> for glue code in JMeter's samplers. In fact, it could even make sense
> >> to add a menu entry like "create groovy samlper". That way users could
> >> access it without secret knowledge of what JSR223 means.
> >>
> >> 4) Groovy's Java interop is much better designed from language point
> >> of view than the one of JavaScript. I mean it is just much easier to
> >> call java libraries since that was considered by Groovy language
> >> designers. This somewhat rules out JavaScript. BeanShell is too
> >> verbose and it does not seem to be the right tool as a glue language.
> >>
> >> As a Java programmer, I'm much more fluent in "Groovy+groovyconsole"
> >> than in "BeanShell+no_way_to_validate_snippet".
> >> I'm fluent in JavaScript, yet it does not help me to answer "how to
> >> read/write a file". Rhino/Nashorn have java interop, yet it is not in
> >> my active vocabulary, thus I would prefer groovy.
> >>
> >> 5) It is a bit hard to pick the proper groovy jar.
> >>
> >> 6) At the end of the day, "valid java code is valid Groovy code"
> >>
> >> 7) Having Groovy in JMeter would add nice "backward compatibility"
> >> feature. Suppose JMeter 3.0 includes Groovy. Then load scripts would
> >> work in exactly the same way for all the users of JMeter 3.0. If
> >> everybody downloads his/her own version of Groovy, that would easily
> >> result in "JMeter script broken for unknown reason" or even "wrong
> >> results due to newer/incompatible groovy.jar version".
> >>
> >>
> >> sebb> The only advantage I can see is that JMeter users don't have to
> >> sebb> download Groovy in order to use it.
> >>
> >> That is huge advantage.
> >> Current http://groovy-lang.org/download.html is not designed for
> >> downloading a single jar file.
> >> "apache-groovy-binary...zip" is 35MiB zip file with lots of jars
> >> inside. Technically speaking, 52 of them start with "groovy-"
> >> I do not want to learn/read which groovy jar I need. I just want to
> >> make JMeter work.
> >>
> >> Milamber>2/ Why Beanshell is including in JMeter and not Groovy?
> >>
> >> I think it might be a good time to deprecate BeanShell. Not in a sense
> >> "remove it in the subsequent release", but in order to clean up menus,
> >> etc, etc. One never has excessive screen space, so removing BeanShell
> >> menus seems wise from my point of view.
> >>
> >>
> >> sebb> This adds aboiut 5% to the total jar size.
> >>
> >> That is OK from my point of view.
> >>
> >> Current apache-jmeter-2.13.zip includes:
> >> 1) Lots of javadocs (docs/api). 46MiB when unzipped. That is 

Build failed in Jenkins: JMeter-trunk #5039

[Apache Jenkins Server]

See 

Changes:

[sebb] Tab police needed yet again

--
[...truncated 990 lines...]
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.java.test...
  [javadoc] Loading source files for package org.apache.jorphan.collections...
  [javadoc] Loading source files for package org.apache.jorphan.exec...
  [javadoc] Loading source files for package org.apache.jorphan.gui...
  [javadoc] Loading source files for package org.apache.jorphan.gui.layout...
  [javadoc] Loading source files for package org.apache.jorphan.io...
  [javadoc] Loading source files for package org.apache.jorphan.logging...
  [javadoc] Loading source files for package org.apache.jorphan.math...
  [javadoc] Loading source files for package org.apache.jorphan.reflect...
  [javadoc] Loading source files for package org.apache.jorphan.test...
  [javadoc] Loading source files for package org.apache.jorphan.util...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.ldap.config.gui...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.ldap.control.gui...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.ldap.sampler...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.tcp.config.gui...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.tcp.control.gui...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.tcp.sampler...
  [javadoc] Loading source files for package 
org.apache.jmeter.examples.sampler...
  [javadoc] Loading source files for package 
org.apache.jmeter.examples.sampler.gui...
  [javadoc] Loading source files for package 
org.apache.jmeter.examples.testbeans.example1...
  [javadoc] Loading source files for package 
org.apache.jmeter.examples.testbeans.example2...
  [javadoc] Loading source files for package 
org.apache.jmeter.examples.testbeans.example3...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.mail.sampler...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.mail.sampler.gui...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.smtp.sampler...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.smtp.sampler.gui...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.smtp.sampler.protocol...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.smtp.sampler.tools...
  [javadoc] Loading source files for package org.apache.jmeter.monitor.util...
  [javadoc] Loading source files for package org.apache.jmeter.monitor.model...
  [javadoc] Loading source files for package org.apache.jmeter.monitor.parser...
  [javadoc] Loading source files for package org.apache.jmeter.protocol.jms...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.jms.client...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.jms.control.gui...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.jms.sampler...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.system...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.system.gui...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.mongodb.config...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.mongodb.mongo...
  [javadoc] Loading source files for package 
org.apache.jmeter.protocol.mongodb.sampler...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.7.0_80
  [javadoc] Building tree for all the packages and classes...
  [javadoc] 
/x1/jenkins/jenkins-slave/workspace/JMeter-trunk/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java:783:
 warning - Tag @see:illegal character: "58" in 
"https://bz.apache.org/bugzilla/show_bug.cgi?id=58099;
  [javadoc] 
/x1/jenkins/jenkins-slave/workspace/JMeter-trunk/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java:783:
 warning - Tag @see:illegal character: "47" in 
"https://bz.apache.org/bugzilla/show_bug.cgi?id=58099;
  [javadoc] 
/x1/jenkins/jenkins-slave/workspace/JMeter-trunk/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java:783:
 warning - Tag @see:illegal character: "47" in 
"https://bz.apache.org/bugzilla/show_bug.cgi?id=58099;
  [javadoc] 
/x1/jenkins/jenkins-slave/workspace/JMeter-trunk/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java:783:
 warning - Tag @see:illegal character: "47" in 
"https://bz.apache.org/bugzilla/show_bug.cgi?id=58099;
  [javadoc] 
/x1/jenkins/jenkins-slave/workspace/JMeter-trunk/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java:783:
 warning - Tag @see:illegal character: "47" in 

buildbot failure in on jmeter-trunk

[buildbot]

The Buildbot has detected a new failure on builder jmeter-trunk while building 
. Full details are available at:
https://ci.apache.org/builders/jmeter-trunk/builds/740

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: hemera_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-jmeter-commit' 
triggered this build
Build Source Stamp: [branch jmeter/trunk] 1733393
Blamelist: sebb

BUILD FAILED: failed shell_3

Sincerely,
 -The Buildbot

[GitHub] jmeter pull request: Bug 59099 _ Add the possibility to use reg ex...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: svn commit: r1732939 - in /jmeter/trunk: bin/ src/core/org/apache/jmeter/gui/util/ src/protocol/http/org/apache/jmeter/protocol/http/config/gui/ src/protocol/http/org/apache/jmeter/protocol/http/s

[Philippe Mouawad]

Hi Felix,
Do we delay this one for 3.1 ?
Thanks

On Mon, Feb 29, 2016 at 8:48 PM, Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

> Am 29.02.2016 um 20:39 schrieb Felix Schumacher:
>
>> Am 29.02.2016 um 20:36 schrieb fschumac...@apache.org:
>>
>>> Author: fschumacher
>>> Date: Mon Feb 29 19:36:14 2016
>>> New Revision: 1732939
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1732939=rev
>>> Log:
>>> Revert changes made by r1732937
>>> At least HTTPHC4Impl uses HttpWebDav#isWebdavMethod in a way, that is
>>> incompatible to this change.
>>>
>>> Was: HTTP Request : Make Method field editable so that additional
>>> methods (Webdav) can be added easily
>>>
>>> Bugzilla Id: 59083
>>>
>>> Modified:
>>>  jmeter/trunk/bin/jmeter.properties
>>> jmeter/trunk/src/core/org/apache/jmeter/gui/util/JLabeledRadioI18N.java
>>> (props changed)
>>>
>>> jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/config/gui/UrlConfigGui.java
>>>
>>> jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java
>>>
>>> jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
>>>
>>> jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HttpWebdav.java
>>>  jmeter/trunk/xdocs/changes.xml
>>>  jmeter/trunk/xdocs/images/asf-logo.gif   (props changed)
>>>
>> I wonder how I got this change in here. Will try to get the orginal (new)
>> logo in again.
>>
> Seems the logo wasn't replaced by my revert. Should we delete the image?
> It doesn't seem to be used.
>
> Regards,
>  Felix
>



-- 
Cordialement.
Philippe Mouawad.

Re: https://ci.apache.org/projects/jmeter/nightlies/ : NIghtly build not generated since 16th january

[Philippe Mouawad]

Thanks
My questions inline

On Wed, Mar 2, 2016 at 2:32 PM, sebb  wrote:

> This is part of buildbot
>
> https://ci.apache.org/


How do you change the build ?

>
>
> The code is under:
>
> https://svn.apache.org/repos/infra/infrastructure/buildbot


I don't have the rights to access it.

>
>
> On 1 March 2016 at 21:58, Philippe Mouawad 
> wrote:
> > Hi,
> > Any clue on this ?
> >
> > Anybody knows how it works and where we can update the nightly page that
> > displays ?
> > Thanks
> >
> > On Sun, Feb 28, 2016 at 10:27 PM, Philippe Mouawad <
> > philippe.moua...@gmail.com> wrote:
> >
> >> Hello,
> >> How do we fix this ?
> >> Where is it configured ?
> >>
> >> Thanks for help
> >> Regards
> >>
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>



-- 
Cordialement.
Philippe Mouawad.

Re: Remaining Work before Release of 3.0

[Philippe Mouawad]

Hi
Thanks for contrib.
Maybe you should open a new discussion.
On Wednesday, March 2, 2016, Antonio Gomes Rodrigues 
wrote:

> Hi,
>
> My opinion about the remaining Work before Release of 3.0.
>
> JMeter seems to have a significant technical debt and I think it's the
> moment (because we can broke the compatibility) to reduce it
>
> The technical debt I see:
> Use of no maintained framework (Log, ORO)


Big work has been done already in the upcoming 3.0 ( 7 legacy jars and
dependencies dropped)
Big spring cleanup and java7 sugar syntax thanks to many PRs and work by
team.



> Old school GUI


That's big work


> Complex GUI


Some work has been done in 3.0 but there is still ways to improve and
simplify.

Feel free to open detailed proposals or Bugzillas


> Lack of official feature (JMeter plugin, Maven plugin, etc.)


non official maven plugin exists and works rather nicely.
What do you mean by JMeter plugin ?


> Unused (to my opinion) element (Monitor Results listener, etc.)

+1

> In Listener element, mix between Debug listener (Assertion Results, etc.)

and "real" listener (Summary Report, etc.)

+1

> Default value of parameter (I still don't understand why "Generate parent
> sample" is not true by default in Transaction Controller)

2 reason for keeping it:
- report/dashboard requires it to compute hits/s and detailed error report.
JMeter-plugins graphs also
- there are bugs in Parent sampler mode for now, 2 were fixed for 3.0 but 2
remain.



> etc.


Could you give more details ?


>
> Some of them are complex to fix but other can be fix if anybody are ok to
> brake the compatibility
>
>
> Regards
> Antonio
>
> Cet e-mail a été envoyé depuis un ordinateur protégé par Avast.
> www.avast.com
> <
> https://www.avast.com/fr-fr/lp-safe-emailing?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=OA-2109-A
> >
> <#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> 2016-02-28 19:15 GMT+01:00 Philippe Mouawad  >:
>
> > Hello,
> > I implemented Bug 58936 which distributes now nightly builds as regular
> > released versions, so they can be used much more easily.
> >
> > Regards
> >
> > On Sat, Feb 27, 2016 at 11:06 AM, Philippe Mouawad <
> > philippe.moua...@gmail.com > wrote:
> >
> > > Hello
> > > I had a look at bugs, enhancements and pending mailing lists
> discussions.
> > >
> > > After release of HttpClient 4.5.2, we are now ready to finalize the 3.0
> > > version.
> > >
> > > I added a Tag "fix_before_3.0" on issues that are pending :
> > >
> > > Here is the list:
> > > 59083 JMeter HTTP NEW --- HTTP Request : Make
> Method
> > > field editable so that additional methods (Webdav) can be added easily
> > =>
> > > PATCH nearly ready to be commited
> > > 59038 JMeter HTTP NEW --- Deprecate HTTPClient 3.1
> > > related elements => Some deprecation work to do
> > > 59033 JMeter HTTP NEW --- Parallel Download : Add
> CSS
> > > Parsing to extract links from CSS files => Patch Part1 ready to
> > commit,
> > > we could stop for now and complete it in 3.1 by adding an
> implementation
> > > similar to HTMLRegexParser that extracts url()
> > > 58986 JMeter Main REOP --- Report/Dashboard reuses
> > the
> > > same output directory
> > > => Waiting for sebb answer, not a lot of work
> > > 58807 JMeter HTTP NEED ---
> > > https.use.cached.ssl.context=false is broken
> > > => Patch waiting to be commited
> > > 57182 JMeter Main NEW --- Better defaults : Save
> idle
> > > time by default
> > > => Not mandatory
> > >
> > >
> > > I will work on:
> > >
> > >- 59038
> > >- 58986 if you are ok with my solution last comment on bug
> > >
> > >
> > > Besides this we had some documentation update:
> > >
> > >- Screenshots
> > >- New and Noteworthy section which should be very rich
> > >
> > >
> > > Once this is done, for release, what do you think of the following:
> > >
> > >- We send on user mailing list and twitter a message to ask users to
> > >test nightly build and wait for 1 week for feedback
> > >- We then start the release process
> > >
> > >
> > >
> > > Regards
> > > Philippe
> > >
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> >
>


-- 
Cordialement.
Philippe Mouawad.

Re: Switch "view.results.tree.max_size" to 0

[Philippe Mouawad]

Yes good point.
Setting maybe even 10mb should be enough I think.


Unless there is a nogo I will change it tonight


On Wednesday, March 2, 2016, Vladimir Sitnikov 
wrote:

> What if bump the value a bit, yet keep it limited?
> OutOfMemory errors are much harder to recover than response too big errors.
>
> What if using 50MiB limit (or less)?
>
> Vladimir
>


-- 
Cordialement.
Philippe Mouawad.

Re: Remaining Work before Release of 3.0

[Antonio Gomes Rodrigues]

Hi,

My opinion about the remaining Work before Release of 3.0.

JMeter seems to have a significant technical debt and I think it's the
moment (because we can broke the compatibility) to reduce it

The technical debt I see:
Use of no maintained framework (Log, ORO)
Old school GUI
Complex GUI
Lack of official feature (JMeter plugin, Maven plugin, etc.)
Unused (to my opinion) element (Monitor Results listener, etc.)
In Listener element, mix between Debug listener (Assertion Results, etc.)
and "real" listener (Summary Report, etc.)
Default value of parameter (I still don't understand why "Generate parent
sample" is not true by default in Transaction Controller)
etc.

Some of them are complex to fix but other can be fix if anybody are ok to
brake the compatibility


Regards
Antonio

Cet e-mail a été envoyé depuis un ordinateur protégé par Avast.
www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2016-02-28 19:15 GMT+01:00 Philippe Mouawad :

> Hello,
> I implemented Bug 58936 which distributes now nightly builds as regular
> released versions, so they can be used much more easily.
>
> Regards
>
> On Sat, Feb 27, 2016 at 11:06 AM, Philippe Mouawad <
> philippe.moua...@gmail.com> wrote:
>
> > Hello
> > I had a look at bugs, enhancements and pending mailing lists discussions.
> >
> > After release of HttpClient 4.5.2, we are now ready to finalize the 3.0
> > version.
> >
> > I added a Tag "fix_before_3.0" on issues that are pending :
> >
> > Here is the list:
> > 59083 JMeter HTTP NEW --- HTTP Request : Make Method
> > field editable so that additional methods (Webdav) can be added easily
> =>
> > PATCH nearly ready to be commited
> > 59038 JMeter HTTP NEW --- Deprecate HTTPClient 3.1
> > related elements => Some deprecation work to do
> > 59033 JMeter HTTP NEW --- Parallel Download : Add CSS
> > Parsing to extract links from CSS files => Patch Part1 ready to
> commit,
> > we could stop for now and complete it in 3.1 by adding an implementation
> > similar to HTMLRegexParser that extracts url()
> > 58986 JMeter Main REOP --- Report/Dashboard reuses
> the
> > same output directory
> > => Waiting for sebb answer, not a lot of work
> > 58807 JMeter HTTP NEED ---
> > https.use.cached.ssl.context=false is broken
> > => Patch waiting to be commited
> > 57182 JMeter Main NEW --- Better defaults : Save idle
> > time by default
> > => Not mandatory
> >
> >
> > I will work on:
> >
> >- 59038
> >- 58986 if you are ok with my solution last comment on bug
> >
> >
> > Besides this we had some documentation update:
> >
> >- Screenshots
> >- New and Noteworthy section which should be very rich
> >
> >
> > Once this is done, for release, what do you think of the following:
> >
> >- We send on user mailing list and twitter a message to ask users to
> >test nightly build and wait for 1 week for feedback
> >- We then start the release process
> >
> >
> >
> > Regards
> > Philippe
> >
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>

[GitHub] jmeter pull request: Bug 59099 _ Add the possibility to use reg ex...

[ra0077]

GitHub user ra0077 opened a pull request:

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

Bug 59099 _ Add the possibility to use reg ex in Backend listener

Hi,

This PR add the possibility to use reg ex in Backend listener
It will allow to be more productive

Antonio

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ra0077/jmeter 
UseRegexpForSamplerListInGraphiteBackendListener

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jmeter/pull/151.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #151


commit 46112a0f656a1b0c56b6af1b18625ebce671a05b
Author: ra0077 
Date:   2016-03-02T14:04:08Z

Add the possibility to use reg ex in Backend listener




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: https://ci.apache.org/projects/jmeter/nightlies/ : NIghtly build not generated since 16th january

[sebb]

This is part of buildbot

https://ci.apache.org/

The code is under:

https://svn.apache.org/repos/infra/infrastructure/buildbot

On 1 March 2016 at 21:58, Philippe Mouawad  wrote:
> Hi,
> Any clue on this ?
>
> Anybody knows how it works and where we can update the nightly page that
> displays ?
> Thanks
>
> On Sun, Feb 28, 2016 at 10:27 PM, Philippe Mouawad <
> philippe.moua...@gmail.com> wrote:
>
>> Hello,
>> How do we fix this ?
>> Where is it configured ?
>>
>> Thanks for help
>> Regards
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

[GitHub] jmeter pull request: deprecate some methods in JMeterUtils

[benbenw]

Github user benbenw commented on the pull request:

https://github.com/apache/jmeter/pull/148#issuecomment-191238251
  
add some javadoc the deprecated method


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Switch "view.results.tree.max_size" to 0

[Vladimir Sitnikov]

What if bump the value a bit, yet keep it limited?
OutOfMemory errors are much harder to recover than response too big errors.

What if using 50MiB limit (or less)?

Vladimir

Re: Switch "view.results.tree.max_size" to 0

[Philippe Mouawad]

On Wed, Mar 2, 2016 at 12:04 PM, sebb  wrote:

> On 28 February 2016 at 20:31, Philippe Mouawad
>  wrote:
> > Hello,
> > I propose to switch to 0 this value as I very frequently find myself
> after
> > recording having some response (that I am testing with Regex/CSS JQuery
> > tester to extract data) that is bigger than the configured value and have
> > then to change it , restart and record again which is a certain loss of
> > time.
>
> In which case add it to your copy of user.properties.
>
I am aware of that, my aim here is to make it easier for beginners.

>
> > I remember that it happens at the start of every campaign.
> >
> > It was introduced to protect from OOMs as far as I remember at a period
> of
> > time where there was such kind of issues.
>
> In which case it seems to have worked.
>

It was because at that time we had remaining issues which have been fixed.
I introduced this one I think.

>
> Are we sure that disabling the check won't cause lots of problems?
>

I am pretty sure yes, because I now always have it == 0

>
> > Since GUI is not made for Load Testing and if used, View Results Tree
> must
> > absolutely be avoided, I think switching it to 0 will not be an issue.
>
> The size of an individual page does not depend on whether you are Load
> Testing or not.
>

I thing my remark here is out of subject indeed.

>
> GUI mode is intended for building and checking test plans.
> It's important that changing the setting does not affect that adversely.
>
> Is there another way to change the default that does not involve
> restarting?
>

Not for now, there is a Bugzilla for it

>
> > Regards
> > Philippe
>



-- 
Cordialement.
Philippe Mouawad.

Re: Is "https.sessioncontext.shared" useful

[sebb]

We probably don't need that anymore.

On 1 March 2016 at 21:59, Philippe Mouawad  wrote:
> Hi,
> Any thoughts on that ?
> Thanks
>
> On Sun, Feb 28, 2016 at 9:12 PM, Philippe Mouawad <
> philippe.moua...@gmail.com> wrote:
>
>> Hello,
>> Do you see a Use Case for this old property ?
>> It was introduced in 2.2 , it's comment was:
>>
>>- In versions of JMeter up to 2.2, only a single SSL context was used
>>for all threads and samplers. This did not generate the proper load for
>>multiple users.
>>
>>
>> If there is none then let's drop it.
>>
>> Thanks
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Re: Switch "view.results.tree.max_size" to 0

[sebb]

On 28 February 2016 at 20:31, Philippe Mouawad
 wrote:
> Hello,
> I propose to switch to 0 this value as I very frequently find myself after
> recording having some response (that I am testing with Regex/CSS JQuery
> tester to extract data) that is bigger than the configured value and have
> then to change it , restart and record again which is a certain loss of
> time.

In which case add it to your copy of user.properties.

> I remember that it happens at the start of every campaign.
>
> It was introduced to protect from OOMs as far as I remember at a period of
> time where there was such kind of issues.

In which case it seems to have worked.

Are we sure that disabling the check won't cause lots of problems?

> Since GUI is not made for Load Testing and if used, View Results Tree must
> absolutely be avoided, I think switching it to 0 will not be an issue.

The size of an individual page does not depend on whether you are Load
Testing or not.

GUI mode is intended for building and checking test plans.
It's important that changing the setting does not affect that adversely.

Is there another way to change the default that does not involve restarting?

> Regards
> Philippe

Re: Switch http.java.sampler.retries to 1

[sebb]

If we are going to change the default, I guess it does not matter
changing its meaning at the same time, so long as both are clearly
documented.

On 1 March 2016 at 21:59, Philippe Mouawad  wrote:
> Hi,
> Any thoughts on that ?
> Thanks
>
> On Sun, Feb 28, 2016 at 9:37 PM, Philippe Mouawad <
> philippe.moua...@gmail.com> wrote:
>
>> Hello,
>> To align HttpClient with Java behaviour, I suggest that as for HttpClient,
>> we switch this property to 0.
>>
>>
>> Property is by the way not greatly named as a value of 1 means 0 retry.
>>
>> So maybe we should also fix the algorithm so that 0 means no retry.
>>
>> int retry = -1;
>> for (; retry < MAX_CONN_RETRIES; retry++) {
>> --
>> Regards.
>> Philippe
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.

[GitHub] jmeter pull request: BUG 59095 drop UserParameterXMLParser (was de...

[benbenw]

GitHub user benbenw opened a pull request:

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

BUG 59095 drop UserParameterXMLParser (was deprecated 8 years ago) and 
associated classes

deprecate UserSequence

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/benbenw/jmeter dropuserxml

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jmeter/pull/150.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #150


commit fa507f8117fa080e7c15dacf3971fb28bb99761a
Author: benoit 
Date:   2016-03-02T10:57:03Z

BUG 59095 drop UserParameterXMLParser (was deprecated 8 years ago) and
associated classes
deprecate UserSequence




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] jmeter pull request: drop some deprecated methods

[benbenw]

GitHub user benbenw opened a pull request:

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

drop some deprecated methods

Calculator#addValue 4 years ago
StatisticalSampleResult constructor 7 years ago

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/benbenw/jmeter dropdepre

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/jmeter/pull/149.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #149


commit 3fc56dd5b474cd423324b8c72a39eb2a74d37631
Author: benoit 
Date:   2016-03-02T10:34:43Z

drop some deprecated methods
Calculator#addValue 4 years ago
StatisticalSampleResult constructor 7 years ago




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Tabs in source files are not allowed

[Felix Schumacher]

Am 1. März 2016 22:23:34 MEZ, schrieb Felix Schumacher 
:
>Am 01.03.2016 um 22:04 schrieb Vladimir Sitnikov:
>>> They are now failing when getting the localhost
>> I think it is related with JVM buffer overflow:
>> https://twitter.com/viktorklang/status/704709748885688320
>The addons: hostname: short-name was in place, already. That was the
>fix 
>for the first jvm crashes.
>
>I think it is a bit like
>https://github.com/travis-ci/travis-ci/issues/1178

The workaround needed another workaround, which didn't work. So for now, I have 
removed openjdk7 and the workarounds.

The builds passes now with oraclejdk7 and 8.

Regards, 
Felix 
>
>Felix
>>
>> Vladimir