Re: Workbench : Let's drop it ?
FYI BlazeMeter will attempt to implement this change and contribute it. Andrey Pokhilko 04.11.2017 17:06, Andrey Pokhilko пишет: > I'll need to think about it. > > Andrey Pokhilko > > 04.11.2017 17:01, Philippe Mouawad пишет: >> On Sat, Nov 4, 2017 at 2:52 PM, Andrey Pokhilko wrote: >> >>> +1 from me, I think it is possible to automatically move elements from >>> loaded test plans. >>> >> Do you have some time to contribute a patch for this if you think it's >> needed ? >> >>> Andrey Pokhilko >>> >>> 04.11.2017 15:18, Maxime Chassagneux пишет: >>>> Hi, >>>> >>>> I never use it, except for recording script, so +1 for me. >>>> >>>> Regards >>>> >>>> 2017-11-04 13:07 GMT+01:00 Philippe Mouawad >>> : >>>> >>>>> Hello, >>>>> Workbench element is confusing for beginners who don't understand >>>>> clearly its use. >>>>> >>>>> Thinking more about it, I don't see today why we should still keep it. >>>>> >>>>> The only advantage of this element is Non Test Elements which would >>>>> be made available from Test Plan directly. >>>>> When running a test those element would not impact test plan. >>>>> >>>>> The only issue is backward compatibility, should we try to move >>> elements in >>>>> workbench under test plan or just mention a backward incompatibility. >>>>> >>>>> Users would manually move there elements to Test Plan. >>>>> >>>>> Regards >>>>>
Re: Workbench : Let's drop it ?
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 >>>>> >>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_ >>>>> source=link&utm_campaign=sig-email&utm_content=webmail> >>>>> Без >>>>> вирусов. www.avast.ru >>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_ >>>>> source=link&utm_campaign=sig-email&utm_content=webmail> >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>>>> >>>>> On Wed, Nov 8, 2017 at 4:41 PM, Philippe Mouawad < >>>>> philippe.moua...@gmail.com >>>>>> wrote: >>>>>> Great ! >>>>>> >>>>>> On Wed, Nov 8, 2017 at 2:38 PM, Andrey Pokhilko >> >>>>> > wrote: >>>>>>> FYI BlazeMeter will attempt to implement this change and contribute >>> it. >>>>>>> Andrey Pokhilko >>>>>>> >>>>>>> 04.11.2017 17:06, Andrey Pokhilko пишет: >>>>>>>> I'll need to think about it. >>>>>>>> >>>>>>>> Andrey Pokhilko >>>>>>>> >>>>>>>> 04.11.2017 17:01, Philippe Mouawad пишет: >>>>>>>>> On Sat, Nov 4, 2017 at 2:52 PM, Andrey Pokhilko >> >>>>> > wrote: >>>>>>>>>> +1 from me, I think it is possible to automatically move >>> elements >>>>>> from >>>>>>>>>> loaded test plans. >>>>>>>>>> >>>>>>>>> Do you have some time to contribute a patch for this if you think >>>>> it's >>>>>>>>> needed ? >>>>>>>>> >>>>>>>>>> Andrey Pokhilko >>>>>>>>>> >>>>>>>>>> 04.11.2017 15:18, Maxime Chassagneux пишет: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I never use it, except for recording script, so +1 for me. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> 2017-11-04 13:07 GMT+01:00 Philippe Mouawad < >>>>>>> philippe.moua...@gmail.com >>>>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> Workbench element is confusing for beginners who don't >>> understand >>>>>>>>>>>> clearly its use. >>>>>>>>>>>> >>>>>>>>>>>> Thinking more about it, I don't see today why we should still >>>>> keep >>>>>>> it. >>>>>>>>>>>> The only advantage of this element is Non Test Elements which >>>>> would >>>>>>>>>>>> be made available from Test Plan directly. >>>>>>>>>>>> When running a test those element would not impact test plan. >>>>>>>>>>>> >>>>>>>>>>>> The only issue is backward compatibility, should we try to >>> move >>>>>>>>>> elements in >>>>>>>>>>>> workbench under test plan or just mention a backward >>>>>> incompatibility. >>>>>>>>>>>> Users would manually move there elements to Test Plan. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Cordialement. >>>>>> Philippe Mouawad. >>>>>> >>>> >>>> -- >>>> Cordialement. >>>> Philippe Mouawad. >>>> Ubik-Ingénierie >>>> >>>> UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/> >>>> >>>> UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack> >> >> -- >> Cordialement. >> Philippe Mouawad.
Re: XPath Extractor : Drop Tidy Option
+0 for me Andrey Pokhilko 16.11.2017 22:20, Philippe Mouawad пишет: > Hello, > Tidy option AFAIK used to allow using XPath Extractor for HTML. > I don't think it's needed anymore since we have CSS/JQuery extractor which > is: > - Up to date > - Powerful > - Performing much better than XPath > > I propose to drop tidy options from XPath. > I even propose to think about dropping jtidy library which would mean : > >- Either Dropping AnchorModifier or finding a better alternative to >jtidy to it if it's useful > > IMO, we should drop it, as it doesn't work with Distributed testing as it > requires keeping the previous SampleResult response Data to be able to work > which Stripping mode clears. >
Re: Deprecated Classes
Hi, If JMeter will break plugins massively, the biggest problem are rarely changing/abandoned plugins. There's simply nobody to release fixed versions of them. So please consider a pain that this will cause to community. Andrey Pokhilko 22.11.2017 00:44, Philippe Mouawad пишет: > Hi Graham, > As we'll be releasing a 4.0, we might drop them. > This can possibly break plugins but we have warned about this for 2 > releases. > > Regards > > On Mon, Nov 20, 2017 at 2:54 AM, Graham Russell wrote: > >> I came across the following classes, in org.apache.log, which are >> deprecated and the comment says will be removed in 3.3, but they still >> seem to be here: >> LogEvent >> ContextMap >> LogTarget >> Logger >> Priority >> >> Was this an oversight or should these have been removed? >> >> Thanks >> >> Graham >> > >
Re: Deprecated Classes
It can be any plugin in fact, you never know if maintainer will have time to update it or will just say "meh". For example, look at this plugin: https://github.com/Netflix/CassJMeter/wiki * Is it useful - yes. * Worth including into JMeter core - no, because it is useful for small amount of people. * Is it rarely changing - yes. Chances nobody will find time to update it is high. JMeter's strong side is independence of plugins, so no need for core team to maintain rarely used code. IMO even more code could be taken out of core to benefit from independent release cycle. The rarely used code might be still important for small group of people, so any core disruption is a big question if we want to disrupt or not. I personally don't like holding for old code and limiting project evolution because of that. But for these specific classes, they don't require much maintenance, nor they limit project progress. Finally, I'm ok with dropping those classes, I will find a way to mitigate this disruption for community. Andrey Pokhilko 22.11.2017 11:43, Antonio Gomes Rodrigues пишет: > Hi, > > My opinion > If rarely changing/abandoned plugins are useful, autor can donate it to > core JMeter > If they are not useful, don't clean the JMeter core code are a bad idea, > because the code will be more and more complexe > > Andrey, what plugin do you think? > > > Antonio > > 2017-11-22 9:22 GMT+01:00 Philippe Mouawad : > >> Agreed , let's keep it >> >> On Wed, Nov 22, 2017 at 8:48 AM, Andrey Pokhilko wrote: >> >>> Hi, >>> >>> If JMeter will break plugins massively, the biggest problem are rarely >>> changing/abandoned plugins. There's simply nobody to release fixed >>> versions of them. So please consider a pain that this will cause to >>> community. >>> >>> Andrey Pokhilko >>> >>> 22.11.2017 00:44, Philippe Mouawad пишет: >>>> Hi Graham, >>>> As we'll be releasing a 4.0, we might drop them. >>>> This can possibly break plugins but we have warned about this for 2 >>>> releases. >>>> >>>> Regards >>>> >>>> On Mon, Nov 20, 2017 at 2:54 AM, Graham Russell >>> wrote: >>>>> I came across the following classes, in org.apache.log, which are >>>>> deprecated and the comment says will be removed in 3.3, but they still >>>>> seem to be here: >>>>> LogEvent >>>>> ContextMap >>>>> LogTarget >>>>> Logger >>>>> Priority >>>>> >>>>> Was this an oversight or should these have been removed? >>>>> >>>>> Thanks >>>>> >>>>> Graham >>>>> >>>> >>> >> >> -- >> Cordialement. >> Philippe Mouawad. >>
Re: Release a 4.0 ?
My opinion is that default should be "System", as the safest decision is to use system LAF. Andrey Pokhilko 23.11.2017 14:08, Philippe Mouawad пишет: > Hi Maxime, > It didn't look that ugly to me and the overall look was much better but if > it looks weird to you, it will be the same for others, then NO GO until we > fix it. > > Regards > > On Thu, Nov 23, 2017 at 12:05 PM, Maxime Chassagneux < > mchassagn...@apache.org> wrote: > >> Hi, >> >> I understand it, but for me it's a 'no go", mostly if this theme is the >> default one for 4.0. >> But may be I'm the only one who find it strange. >> >> Of course, if I can fix it , I will do. >> >> >> 2017-11-23 11:40 GMT+01:00 Philippe Mouawad : >> >>> Hello Maxime, >>> It's because RSyntaxtTextarea is not aware of the Darcula LAF. >>> If you can contribute a fix,go ahead. >>> >>> Thanks >>> >>> On Thu, Nov 23, 2017 at 11:38 AM, Maxime Chassagneux < >>> mchassagn...@apache.org> wrote: >>> >>>> Hi, >>>> >>>> First test of Darcula theme on windows for me, I find the rendering of >>>> texteara ugly ( too black & white ! ) I'm the only one with this >>>> effect ? : >>>> >>>> https://www.dropbox.com/s/8h08xu0l3oj2ujt/%231.png?dl=0 >>>> >>>> https://www.dropbox.com/s/grlasbkbxuscliv/%232.png?dl=0 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2017-11-21 21:50 GMT+01:00 Antonio Gomes Rodrigues : >>>> >>>>> Work fine in my Linux >>>>> >>>>> Antonio >>>>> >>>>> 2017-11-21 20:28 GMT+01:00 Milamber : >>>>> >>>>>> >>>>>> On 21/11/2017 12:36, Philippe Mouawad wrote: >>>>>> >>>>>>> Hello, >>>>>>> Thanks Antonio for your tests, I indeed was using laf name instead >>> of >>>>>>> class >>>>>>> name. >>>>>>> It is working now in my tests, but Milamber, Antonio or any >>>> subscriber, >>>>>>> your tests are welcome. >>>>>>> >>>>>> That's works for default LAF after remove theses lines into this >> file >>>>>> ~/.java/.userPrefs/org/apache/jmeter/gui/action/prefs.xml >>>>>> >>>>>> (removed) >>>>>> >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> Jenkins build is in progress, a new nightly build should be >> available >>>> in >>>>>>> few minutes. >>>>>>> Regards >>>>>>> >>>>>>> On Tue, Nov 21, 2017 at 10:17 AM, Philippe Mouawad < >>>>>>> philippe.moua...@gmail.com> wrote: >>>>>>> >>>>>>> Hi Antonio, >>>>>>>> I fixed this bug on sunday. >>>>>>>> Are you using last revision ? >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> On Tue, Nov 21, 2017 at 10:14 AM, Antonio Gomes Rodrigues < >>>>>>>> ra0...@gmail.com> wrote: >>>>>>>> >>>>>>>> Hi Philippe, >>>>>>>>> About Darcula, in Windows 10 (I will test it in Linux later but >> I >>>>> think >>>>>>>>> it's the same) we have in the first launch >>>>>>>>> >>>>>>>>> 2017-11-21 10:09:26,333 INFO o.a.j.g.a.LookAndFeelCommand: >>>> Installing >>>>>>>>> Darcula LAF >>>>>>>>> 2017-11-21 10:09:26,363 INFO o.a.j.g.a.LookAndFeelCommand: Using >>>> look >>>>>>>>> and >>>>>>>>> feel: Darcula [] >>>>>>>>> 2017-11-21 10:09:26,363 INFO o.a.j.JMeter: Setting LAF to: >> Darcula >>>>>>>>> 2017-11-21 10:09:26,363 WARN o.a.j.JMeter: Could not set LAF to: >>>>> Darcula >>>>>>>>> java.lang.ClassNotFoundException: Darcula >>>>>>>>> at java.net.URLClassLoader.findClass(Unknown Source) >>> ~[?:1.8.0_144] >>>>>>>>
Re: Hanging test due to no timeout set / hanging sampler and Test duration
Hi, First of all, I agree that this is very confusing for users. We need to not fall into this trap by default. Wouldn't changing default timeout for HTTP sampler help in this case? Just default how we set it for newly added samplers. This way it won't affect existing test plans, but will make users by default to have limited socket waiting time. Something like 30-60 seconds is a good default from my practice. Andrey Pokhilko 24.11.2017 15:15, Philippe Mouawad пишет: > Hello, > Currently when you check Schedule in Thread group and: > >- fix a duration for your test >- Don't set any timeout on HTTP requests or use a non interruptible >sampler > > Your test can hang infinitely as JMeter will not interrupt the Hanging > samplers even after duration of Thread Group has been reached. > > This is a frequent problem faced by JMeter users (I remember that I have > answered this SO question at least 10 times). Even non newbie can get > trapped. > > Shouldn't we introduce this to avoid hanging test that give a feeling of > broken JMeter while the problem is in the hanging targetted server ?: > >- Option 1: Add an option in Scheduler part called "Interrupt pending >Threads after duration + security margin (1m) that could be a field or >property" on Thread Group (checked by default) >- Option 2 : Add it at test plan level to avoid repeating the >configuration >- On start of Thread Group, an additional TimerTask would be triggered >after duration + security margin and would do the following: > - run equivalent (refactor) of code at: > - > > https://github.com/apache/jmeter/blob/trunk/src/core/org/apache/jmeter/engine/StandardJMeterEngine.java#L326 > > Cordialement. > Philippe Mouawad. > Ubik-Ingénierie > > UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/> > > UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack> >
Re: Controversial topic: Remove internationalization
Hi, +1 to become English-only. I agree to all of the reasoning by Philippe. Andrey Pokhilko 04.01.2018 19:31, Philippe Mouawad пишет: > Hello, > > Currently we provide ability to translate JMeter GUI in many languages. > In our tests we only ensure French translations are available because we > have french team members. > > For other languages, we are in best effort and most probably the UI looks > non professional for many users as there will be a mix of english and non > english labels. > > I am aware that it's a controversial topic and many people probably rely on > translated GUI BUT: > >- I dislike the fact that GUI looks non professional >- Why don't we have more translation contributions if they are used ? >- It's a certain piece of work to maintain and create those translations > > So unless there is a magical way to fully translate all labels and maintain > them efficiently, I am in favor of: > >- Having english forced in setup instead of relying on default locale. >It seems this happened accidentally in 3.3 and nobody complained about it. >- In a second step, and unless there is a big move to help on >translation, I propose to drop all languages, even french one as it's an >additional work and we have other and a lot of things to do > > > Thoughts :-) ?
Re: [VOTE] Release JMeter 4.0 RC6
+1 Andrey Pokhilko 03.02.2018 00:57, Maxime Chassagneux пишет: > Hi all, > > [+1] I support this release > > I use it in production without problem. > > Best regard > > > 2018-02-02 16:30 GMT+01:00 Milamber : > >> Hello, >> >> The fourth release candidate for JMeter 4.0 (r1822967) 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.0RC6/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_RC6/ >> (dist revision r24640) >> >> RAT report: >> >> http://home.apache.org/~milamber/jmeter-4.0RC6/dist/rat- >> report-jmeter-4.0RC6.txt >> >> MD5 hashes of archives for this vote: >> >> a497d140f1956ba65cf15930b0638333 *apache-jmeter-4.0.tgz >> 8b7015e303b3aac83d1a050cb3782860 *apache-jmeter-4.0.zip >> b3d9cce11b04be574a47b4108a3d2bc6 *apache-jmeter-4.0_src.tgz >> 04dbd79c242192cdcde574e10c7c43cd *apache-jmeter-4.0_src.zip >> >> >> Site Docs are here: >> http://home.apache.org/~milamber/jmeter-4.0RC6/docs/ >> >> Maven staging repository is accessible here: >> https://repository.apache.org/content/repositories/orgapache >> jmeter-1027/org/apache/jmeter/ >> >> Tag: >> https://svn.apache.org/repos/asf/jmeter/tags/v4_0_RC6/ >> >> 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.0RC6/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 RC6, >> 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: [VOTE] Release JMeter 4.0 RC7
+1 Andrey Pokhilko 07.02.2018 10:53, Milamber пишет: > 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-report-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/orgapachejmeter-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: [VOTE] Release JMeter 4.0 RC7
BTW, I see following text "Apache JMeter 4.0 (Requires Java 8. JMeter 4.0 does not yet support Java 9.)" on this page: http://jmeter.apache.org/download_jmeter.cgi. We probably need to remove "does not supoort Java 9". Andrey Pokhilko 11.02.2018 09:31, Milamber пишет: > > > On 10/02/2018 08:27, Philippe Mouawad wrote: >> Because announce will reach more people than on week-end. > > I understand, but unfortunately I will no have the time to finish the > release process tomorrow. I will send the email announcement today, > but I will let you to send the Twitter message tomorrow if that can be > help to have more visibility > > >> >> On Saturday, February 10, 2018, Milamber wrote: >> >>> >>> On 10/02/2018 07:59, Philippe Mouawad wrote: >>> >>>> Hello Milamber, >>>> What do you think of delaying announce to monday ? >>>> >>> Why? >>> >>> >>>> Regards >>>> >>>> On Sat, Feb 10, 2018 at 8:56 AM, Milamber wrote: >>>> >>>> Hello, >>>>> Thanks very much to all who voted for this release. >>>>> >>>>> The votes were as follows: >>>>> >>>>> === +1 vote (with *: binding) === >>>>> >>>>> Maxime Chassagneux (mchassagneux) >>>>> Andrey Pokhilko (undera) >>>>> UBIK LOAD PACK Support >>>>> Antonio Gomes Rodrigues (agomes)* >>>>> NaveenKumar Namachivayam >>>>> Philippe Mouawad (pmouawad)* >>>>> Felix Schumacher (fschumacher)* >>>>> Bruno Demion (milamber)* >>>>> >>>>> === >>>>> >>>>> There were no other votes, so the vote passes. >>>>> >>>>> I will prepare the delivery of release for having an official >>>>> announce >>>>> after the mirrors sync. >>>>> >>>>> Milamber >>>>> >>>>> >>>>> On 07/02/2018 07:53, 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- >>>>>> report-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: >>>>>>
Re: [VOTE] Release JMeter 4.0 RC7
The release has been announced via email, I assume this means anyone can tweet about it. And I hope it's not bad thing... Andrey Pokhilko 11.02.2018 13:43, Philippe Mouawad пишет: > Hi Andrei, > I see you tweeted release. > So I had to tweet from official account. > > Regards > > On Sunday, February 11, 2018, Philippe Mouawad > wrote: > >> Hello, >> Maybe we should add to changes / Incompatble changes a note on remote >> testing new requirements and a link to: >> >> - http://jmeter.apache.org/usermanual/remote-test.html#setup_ssl >> >> And do we need to mentions cve fixes now they are public ? >> >> Regards >> >> On Sunday, February 11, 2018, Milamber wrote: >> >>> >>> On 11/02/2018 08:03, Andrey Pokhilko wrote: >>> >>>> BTW, I see following text "Apache JMeter 4.0 (Requires Java 8. JMeter >>>> 4.0 does not yet support Java 9.)" on this page: >>>> http://jmeter.apache.org/download_jmeter.cgi. We probably need to remove >>>> "does not supoort Java 9". >>>> >>> >>> In progress to fix this >>> >>> >>> >>>> Andrey Pokhilko >>>> >>>> 11.02.2018 09:31, Milamber пишет: >>>> >>>>> On 10/02/2018 08:27, Philippe Mouawad wrote: >>>>> >>>>>> Because announce will reach more people than on week-end. >>>>>> >>>>> I understand, but unfortunately I will no have the time to finish the >>>>> release process tomorrow. I will send the email announcement today, >>>>> but I will let you to send the Twitter message tomorrow if that can be >>>>> help to have more visibility >>>>> >>>>> >>>>> On Saturday, February 10, 2018, Milamber wrote: >>>>>> On 10/02/2018 07:59, Philippe Mouawad wrote: >>>>>>> Hello Milamber, >>>>>>>> What do you think of delaying announce to monday ? >>>>>>>> >>>>>>>> Why? >>>>>>> >>>>>>> Regards >>>>>>>> On Sat, Feb 10, 2018 at 8:56 AM, Milamber >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>>> Thanks very much to all who voted for this release. >>>>>>>>> >>>>>>>>> The votes were as follows: >>>>>>>>> >>>>>>>>> === +1 vote (with *: binding) === >>>>>>>>> >>>>>>>>> Maxime Chassagneux (mchassagneux) >>>>>>>>> Andrey Pokhilko (undera) >>>>>>>>> UBIK LOAD PACK Support >>>>>>>>> Antonio Gomes Rodrigues (agomes)* >>>>>>>>> NaveenKumar Namachivayam >>>>>>>>> Philippe Mouawad (pmouawad)* >>>>>>>>> Felix Schumacher (fschumacher)* >>>>>>>>> Bruno Demion (milamber)* >>>>>>>>> >>>>>>>>> === >>>>>>>>> >>>>>>>>> There were no other votes, so the vote passes. >>>>>>>>> >>>>>>>>> I will prepare the delivery of release for having an official >>>>>>>>> announce >>>>>>>>> after the mirrors sync. >>>>>>>>> >>>>>>>>> Milamber >>>>>>>>> >>>>>>>>> >>>>>>>>> On 07/02/2018 07:53, 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 >>>>>>>>>&g
Re: TestAction: Change its name to make it more meaningful
Hi, "Test" sounds redundant to me. Everything we do in JMeter is a test. So maybe just "Logical Action"? -- Andrey Pokhilko 30.03.2018 18:15, 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 > <http://twitter.com/ubikloadpack> >
Re: TestAction: Change its name to make it more meaningful
"Flow Control Action"? Andrey Pokhilko 01.04.2018 16:49, Jmeter Tea пишет: > Most samplers ends with Sampler and none with Action. > And this Sampler *controls* the execution of the test. > I know it's not a controller, but I suggest a name as "Control Sampler" or > " "Execution Control Sampler" > > On Sat, Mar 31, 2018 at 10:29 AM, Andrey Pokhilko wrote: > >> Hi, >> >> "Test" sounds redundant to me. Everything we do in JMeter is a test. So >> maybe just "Logical Action"? >> >> -- >> >> Andrey Pokhilko >> >> 30.03.2018 18:15, 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 >>> <http://twitter.com/ubikloadpack> >>> >>
Re: Move Bugzilla to JIRA ?
Hi, I'd love to retire Bugzilla, it hurts public image of JMeter IMO. I'd suggest to consider GitHub issues, 'cause I like to have single integrated place for project information. Andrey Pokhilko 10.04.2018 23:56, Philippe Mouawad пишет: > Hello Team, > Today someone proposed to move bugzilla to JIRA. > >- https://bz.apache.org/bugzilla/show_bug.cgi?id=62280 > > > I have no strong opinion but my 2 cents: > >- I use bugzilla only for JMeter, it looks very old but it works, >interface with svn is working >- I use JIRA at work and when it's fast it's great, I like it. Still I >have noticed that Apache JIRA has frequently incidents and is very slow > > > I feel moving to JIRA would help increase our community and help make > project more popular. > > So +1 for me hoping it's not much work. > > But I am not ready to spend any time on migration which should of course > keep history IMO. > > I prefer to dedicate my time to coding new features or bugfixes. >
Re: About Mailing list guidelines
+1 to ease process of getting users into mailing list. Andrey Pokhilko 11.04.2018 23:19, Philippe Mouawad пишет: > On Wed, Apr 11, 2018 at 10:15 PM, sebb wrote: > >> On 11 April 2018 at 20:41, Philippe Mouawad >> wrote: >>> Hello, >>> Today when users want to ask a question about JMeter there are many ways: >>> >>> >>>- Our way: >>> - User mailing list >>> - Other ways: >>> - https://stackoverflow.com/questions/tagged/jmeter >>> - There is a slack for jmeter >>> >>> So if we look at our mailing list: >>> >>>- http://jmeter.apache.org/mail.html >>>- http://jmeter.apache.org/mail2.html >>> >>> The left link on website goes to mail.html and there is some long text to >>> read: >>> >>>- Do users read it ? >>>- If we look at its content, it is very defensive: >> I did not write the original, but I think it is sensible, rather than >> defensive. >> > I wrote part of it, and I think now reading it again that it can be seen as > distrustful to users. > >>> - *Respect the mailing list type * >>> - *Join the lists that are appropriate for your discussion.* >>> - >>> *Ask smart questions. * >>> - *Keep your email short and to the point; use a suitable subject >>> line. * >>> - *Do your best to ensure that you are not sending HTML or >> "Stylized" >>> email to the list.* >>> - *Please don't send attachments or include large chunks of code* >>> - *Do not cross post messages. * >>> - >>> *Watch where you are sending email. * >>>- *Isn't it kind of scary for the newbie who wants to ask some >> question >>>?* >> Once an email has been sent, in general it cannot be removed or redacted. >> > Yes but this can happen today no ? > >>> Shouldn't we just remove mail.html and directly link to mail2.html and >>> mention guidelines in it ? >> The point was to try and get people to read the guidelines. >> > I think people who don't want to read them won't wherever we put them and > will directly find the link or ask somewhere else which is what is > happening looking at number of question on SO vs questions on User mailing > list > People who want to read them will do even if we change the order. > So another approach would be: > >- let's trust users and encourage this way of asking > > > >>> -- >>> Regards. >>> Philippe > >
Re: JMeter wiki
Hi, I'd migrate useful part of it onto main JMeter website and drop it. Because the purpose overlaps - main website supposed to be a source of documentation, no point in wiki. Andrey Pokhilko 11.04.2018 22:56, Philippe Mouawad пишет: > Hello, > Looking at JMeter wiki, I wonder if it's useful and if it serves the > project. > IMO, a newbie seeing it might think JMeter is largely outdated > >- The look of pages is awful >- The content is largely outdated and gives IMO a bad image of the >project: > - https://wiki.apache.org/jmeter/FutureReleases > - https://wiki.apache.org/jmeter/Java14Proposals > - https://wiki.apache.org/jmeter/BuildingJMeter > - https://wiki.apache.org/jmeter/JMeterAndEclipseHowTo > - https://wiki.apache.org/jmeter/JMeterArchitecturalOverview > - https://wiki.apache.org/jmeter/JMeterDevelopment/Requirements > - ... > > > So what should we do ? > >- Drop it ? >- Make some spring cleanup ? Drop 70% > >
Re: CSS/JQuery Extractor
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 >
Re: CSS/JQuery Extractor
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 >>
Concerns about change in JTL writing
Hi, I took the latest snapshot of JMeter and I'm shocked by the change in CSV JTL writing. It is strange that it writes subsamples now with no respect to "Save Sub Results" flag. I simply can't turn new behavior off. It will break all the automated scripts written in the ecosystem. I run the test with Aggregate Report, I see one number. If I save it into CSV JTL and re-load it in Aggregate Report, I see completely different picture. All my response times are counted twice now. I believe something really breaking has happened, and it will hurt users. I think CSV JTL writer has to respect the "Save Sub Results" flag and not have that flag enabled by default. Otherwise, we break any automation that were reading CSV JTL assuming only top-level samples are written and math of average response times is consistent. Or maybe I'm just doing something wrong? -- Andrey Pokhilko
Re: Concerns about change in JTL writing
I tried to use JMeter only like regular user will. I did change through UI flag in listener, under "Configure" button. I believe the UI is the "final judge" that overrides any property, plus if I have in my JMX the flag set to false, it is guaranteed that it will be taken into account. I looked into code and I see that property default is "true" from many years ago. This still leaves us with the problem that behavior of CSV JTL writing does change. If we change property default, it will change result writing for users of XML JTL, if we don't - it will change it for users of CSV JTL. JMeter use CSV JTL as default format, so I'd suggest to change "jmeter.save.saveservice.subresults" default to false as lesser from two evils (IMO). -- Andrey Pokhilko 08.08.2018 11:56, Philippe Mouawad пишет: > On Wednesday, August 8, 2018, Andrey Pokhilko wrote: > >> Hi, >> >> I took the latest snapshot of JMeter and I'm shocked by the change in >> CSV JTL writing. It is strange that it writes subsamples now with no >> respect to "Save Sub Results" flag. I simply can't turn new behavior off. > > how did you do that ? > Through property > jmeter.save.saveservice.subresults > or in a different way , in the latter case how ? > > >> It will break all the automated scripts written in the ecosystem. I run >> the test with Aggregate Report, I see one number. If I save it into CSV >> JTL and re-load it in Aggregate Report, I see completely different >> picture. All my response times are counted twice now. > > That would be a bug that we need to fix. > The intention of the change was just to respect the > jmeter.save.saveservice.subresults > flag for csv also. > > It was only taken into account for xml. > >> I believe something really breaking has happened, and it will hurt >> users. I think CSV JTL writer has to respect the "Save Sub Results" flag >> and not have that flag enabled by default. Otherwise, we break any >> automation that were reading CSV JTL assuming only top-level samples are >> written and math of average response times is consistent. >> >> Or maybe I'm just doing something wrong? >> >> -- >> Andrey Pokhilko >> >>
Re: [VOTE] Release JMeter 5.0 RC2
+1 Andrey Pokhilko 14.09.2018 20:39, Milamber пишет: > Hello, > > The second release candidate for JMeter 5.0 (r1840935) has been > prepared, and your votes are solicited. > > This release brings a lot of 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/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-5.0RC2/docs/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/v5.0_RC2/ > (dist revision r29390) > > RAT report: > > http://home.apache.org/~milamber/jmeter-5.0RC2/dist/rat-report-jmeter-5.0RC2.txt > > > SHA512 hashes of archives for this vote: see footnote [1] > > Site Docs are here: > http://home.apache.org/~milamber/jmeter-5.0RC2/docs/ > > Maven staging repository is accessible here: > https://repository.apache.org/content/repositories/orgapachejmeter-1033/org/apache/jmeter/ > > > Tag: > https://svn.apache.org/repos/asf/jmeter/tags/v5_0_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 5.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-5.0RC2/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 > > > === > [1] SHA512 hashes of archives for this vote: > > a5a3bdd84ec8f78b67cee1b12bd9f2f578f3e9334ef2dc85cebd37878e0cf69ea3385a9c4f531dae094c0a4df93f262f43c2d9a9dfb10d38565d17eec3f907f1 > *apache-jmeter-5.0.tgz > 26d4cf65cce0ef008f8ef5955ef0d28e0bef310f2a75a36fe78fcc5f4ff9a6853071be0dd5140815834ca533e88224d766917b7ed2eb5168dc859b35eda5d2dc > *apache-jmeter-5.0_src.tgz > c0b65879db8cbc7ed25de96b869ed3b703ceecad3acbf7fe726f101bd5d65f22443168eac4676c98d8cb55719de453efcb3bf699d02ca4ce4137ef0c594505fa > *apache-jmeter-5.0.zip > f3a4400cea7431b6c1e59cf2498bf70c526eb06f5016dbdf5423d1530549b4555d3eedafe305c51c996adb0543c186d54c0c4979bbac9b8f5269630a1df1 > *apache-jmeter-5.0_src.zip > > > >
Re: Place holder for function execution / Variables evaluation
Hi, There's already a plugin for that: https://jmeter-plugins.org/wiki/SetVariablesAction/ It is exactly a sampler that is used to evaluate functions/variables. -- Andrey Pokhilko 11.11.2018 20:53, Philippe Mouawad пишет: > Hello, > Frequently when using JMeter functions, users don't really know for certain > use cases where to put the function, here are few examples: > >- Any function which output will not be used directly by sample >parameters >- Such type of functions: > - https://jmeter-plugins.org/wiki/InterThreadCommunication/ >- you want to create a variable from the output of a function and update >it on each iteration: > - User Defined Variable is not an option as evaluation occurs on > start of test > - User Parameters being a preprocessor, it would be evaluated on each > call, so you need to nest it inside a Flow Control Action, not very > intuitive right ? > > I also remember when I started using JMeter that I found this part > counter-intuitive. > > I think it would be nice to have a solution for this, that would evaluate > the variables/functions exactly at the place where the call is present and > without generating any SampleResult. > > We could implement this: > >- as an enhancement to Flow Control Action >- as a new Sampler > > What's your thoughts on this ? > > Regards >
Re: Place holder for function execution / Variables evaluation
Can you give a mock of how you envision it implemented in Flow Control Action? -- Andrey Pokhilko 12.11.2018 14:50, Philippe Mouawad пишет: > Thanks for information. > I feel this behavior should be in core. > > To avoid another element, I think updating Flow Control Action is a good > candidate as it’s a sample about jmeter internals. > > Thoughts? > > Regards > > On Monday, November 12, 2018, Andrey Pokhilko wrote: > >> Hi, >> >> There's already a plugin for that: >> https://jmeter-plugins.org/wiki/SetVariablesAction/ >> >> It is exactly a sampler that is used to evaluate functions/variables. >> >> -- >> >> Andrey Pokhilko >> >> 11.11.2018 20:53, Philippe Mouawad пишет: >>> Hello, >>> Frequently when using JMeter functions, users don't really know for >> certain >>> use cases where to put the function, here are few examples: >>> >>>- Any function which output will not be used directly by sample >>>parameters >>>- Such type of functions: >>> - https://jmeter-plugins.org/wiki/InterThreadCommunication/ >>>- you want to create a variable from the output of a function and >> update >>>it on each iteration: >>> - User Defined Variable is not an option as evaluation occurs on >>> start of test >>> - User Parameters being a preprocessor, it would be evaluated on >> each >>> call, so you need to nest it inside a Flow Control Action, not very >>> intuitive right ? >>> >>> I also remember when I started using JMeter that I found this part >>> counter-intuitive. >>> >>> I think it would be nice to have a solution for this, that would evaluate >>> the variables/functions exactly at the place where the call is present >> and >>> without generating any SampleResult. >>> >>> We could implement this: >>> >>>- as an enhancement to Flow Control Action >>>- as a new Sampler >>> >>> What's your thoughts on this ? >>> >>> Regards >>> >
Re: Migrating build system to Gradle
++1 from me. Any change to modern is better, contributors will appreciate the good modern tooling. As for plugins, source layout does not affect them, as long as lib+lib/ext are kept for libs and plugins in distribution structure. -- Andrey Pokhilko 21.02.2019 13:00, Antonio Gomes Rodrigues пишет: > Hi, > > No experience in Gradle, but ++1 (Binding) to replace ant > > Antonio > > Le jeu. 21 févr. 2019 à 10:48, Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> a écrit : > >> sebb> Whoever wants to switch should show that it can replace the current >> sebb> Ant build system without causing disruption. >> sebb> It needs to support all of the existing Ant targets. >> >> Ok, I read that as you agree to replace Ant with Gradle. >> So far the only technical justification (see >> https://www.apache.org/foundation/voting.html#Veto ) I see is "Gradle >> might >> fail to implement some of current build logic". >> Of course the only way to prove that "Gradle fails to implement the >> required tasks" is to actually implement the tasks. I agree there might be >> issues, however I'm sure this fear alone does not qualify as "technical >> justification". >> >> So far >> ++1 (Binding): Vladimir Sitnikov >> ++1 (Binding): Philippe Mouawad >> >> Vetos: none >> >> sebb> (The Ant scripts don't change that often, so that should not be too >> difficult). >> >> Maintenance of multiple build systems at once is always a time consuming >> task. >> We don't seem to have funding for that, so I suggest we just implement >> Gradle build as a branch, and merge that in a single go. >> >> sebb> Why use a build system that all but forces a change on you? >> >> Sebb, I don't suggest Gradle just because it forces to move files around. >> I suggest Gradle since it simplifies day-to-day coding activities like: >> 1) loading JMeter project to IDE >> 2) building JMeter >> 3) testing JMeter >> 4) dependency management >> 5) other >> >> On top of that, there are good reasons for certain folder layout. >> For instance, Gradle encourages to keep dependency jar files in a >> completely separate folder (outside of the project). >> This prevents accidentally putting multi-megabyte blobs under source >> control like in >> >> https://github.com/apache/jmeter/commit/c9a4d557f9a8e213ccc93215264a254dfb2bc50a >> >> Then it makes sense to keep test classes close to the relevant code. >> Otherwise the codebase looks like a single module which really takes time >> to comprehend. >> Currently all the test code is located in a single folder/structure, and it >> is not clear which tests are related to which jars. >> >> So moving files around it not just to make Gradle happy, but it is more to >> make developers who read and maintain the code happy. >> >> sebb> Note that the current Ant build relies on some Beanshell scripting >> and >> sebb> Maven integration. >> >> Gradle approach there would be to use Java (or Kotlin) code and place it in >> buildSrc folder. >> Gradle builds buildSrc code at build script initialization, and buildSrc >> code can represent whatever build logic is required >> Doc: >> >> https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:build_sources >> >> Apparently, Java/Kotlin code is way better than Beanshell. Should I >> elaborate? >> >> Vladimir >>
Re: Migrate SVN -> Git
+1, I know from experience how much easier is to work & review with github PRs, compared to SVN, bugzilla and patches Andrey Pokhilko 21.02.2019 0:33, Vladimir Sitnikov пишет: > Hi, > > What do you think of migrating to Git as a primary VCS? > I've seen recent migration of Apache Calcite to Apache Gitbox ( > https://gitbox.apache.org/ ), and it is kind of great. > The site can be hosted via gitbox as well (one typically creates a separate > git repository for the site like https://github.com/apache/calcite-site ). > > It enables write access for GitHub repositories (e.g. committers can edit > PRs, edit issues, close, label them, etc). > > Can you please express your opinion on that? > If you struggle what to say, you might find the below options useful: > > [ ] ++1: 'Wow! I like this! Let's do it!' > [ ] +1: 'Let's do it!' > [ ] +0.9: 'This is a cool idea and i like it' > > Vladimir >
Re: new org.apache.jorphan.gui.DefaultTreeTableModel() == NPE
Hi, I know some classes from this package are used by plugins: https://github.com/undera/jmeter-plugins/search?utf8=%E2%9C%93&q=%22org.apache.jorphan.gui%22&type= --- Andrey Pokhilko On 03.03.2019 11:00, Vladimir Sitnikov wrote: > Hi, > > I got almost all the tests working in gradle branch, however I've > noticed that new org.apache.jorphan.gui.DefaultTreeTableModel() leads > to NPE. > > Is it just a dead code? > Should we just remove obsolete JTreeTable, DefaultTreeTableModel, > AbstractTreeTableModel, TreeTableModel etc classes from jorphan.gui > package? > > If I put jorphan.jar into lib/ext, then JMeterTest fails as follows > (it is true for ant-based test as well): > > org.apache.jmeter.junit.JMeterTest > initializationError FAILED > java.lang.Exception: Error creating > org.apache.jorphan.gui.DefaultTreeTableModel > at > org.apache.jmeter.junit.JMeterTest.instantiateClass(JMeterTest.java:528) > at org.apache.jmeter.junit.JMeterTest.getObjects(JMeterTest.java:458) > at > org.apache.jmeter.junit.JMeterTest.suiteSerializableElements(JMeterTest.java:391) > at org.apache.jmeter.junit.JMeterTest.suite(JMeterTest.java:133) > Caused by: > java.lang.NullPointerException > at > org.apache.jorphan.gui.AbstractTreeTableModel.getRowCount(AbstractTreeTableModel.java:114) > at > javax.swing.table.DefaultTableModel.setDataVector(DefaultTableModel.java:224) > at > javax.swing.table.DefaultTableModel.(DefaultTableModel.java:124) > at > javax.swing.table.DefaultTableModel.(DefaultTableModel.java:106) > at > javax.swing.table.DefaultTableModel.(DefaultTableModel.java:86) > at > org.apache.jorphan.gui.AbstractTreeTableModel.(AbstractTreeTableModel.java:49) > at > org.apache.jorphan.gui.DefaultTreeTableModel.(DefaultTreeTableModel.java:38) > at > org.apache.jorphan.gui.DefaultTreeTableModel.(DefaultTreeTableModel.java:31) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at java.lang.Class.newInstance(Class.java:442) > at > org.apache.jmeter.junit.JMeterTest.instantiateClass(JMeterTest.java:496) > ... 3 more > > Vladimir
Enable saving thread counts by default?
Hi team, Since I started developing JMeter plugins I faced one issue and after five years it is still the most frequent request from users: "why JTL does not contain active threads info?". Five years I've been answering that they should put jmeter.save.saveservice.thread_counts=true in their jmeter.properties. It is obvious that recording current level of active threads is very important for JMeter. Every analysis session starts from looking at active threads dynamics. Maybe it's time to enable it by default for everyone? It will just add couple more columns to CSV JTL. -- Andrey Pokhilko
Re: Enable saving thread counts by default?
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. > > >
Re: Enable saving thread counts by default?
Hi, I took latest trunk from SVN and changed bin/jmeter.properties to have jmeter.save.saveservice.thread_counts=true Then I ran "ant clean download_jars install test". The only error that showed is: [java] There was 1 failure: [java] 1) testMaven(org.apache.jmeter.JMeterVersionTest)junit.framework.ComparisonFailure: serializer expected:<2.7.[2]> but was:<2.7.[1]> [java] at org.apache.jmeter.JMeterVersionTest.testMaven(JMeterVersionTest.java:182) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236) Which seems to be unrelated to saveservice change. It also appears without any change to properties. So I see no tests failing after the change. Does it mean that we can do the change right now? Andrey Pokhilko On 09/26/2014 04:24 PM, UBIK LOAD PACK Support wrote: > 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 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. >>> >>> >>> >> >
Re: Enable saving thread counts by default?
Thanks Philippe, Now I'm able to see the failure. Do we have bugzilla for the change already or should I register one? Andrey Pokhilko On 09/27/2014 02:16 PM, Philippe Mouawad wrote: > Hello, > It's because there was an issue in last commit which upgraded serializer > version to 2.7.2, one test was failing. > > Try again now, you will see. > Regards > > On Sat, Sep 27, 2014 at 1:00 PM, Andrey Pokhilko wrote: > >> Hi, >> >> I took latest trunk from SVN and changed bin/jmeter.properties to have >> jmeter.save.saveservice.thread_counts=true >> >> Then I ran "ant clean download_jars install test". The only error that >> showed is: >> [java] There was 1 failure: >> [java] 1) >> >> testMaven(org.apache.jmeter.JMeterVersionTest)junit.framework.ComparisonFailure: >> serializer expected:<2.7.[2]> but was:<2.7.[1]> >> [java] at >> org.apache.jmeter.JMeterVersionTest.testMaven(JMeterVersionTest.java:182) >> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> [java] at >> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> [java] at >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> [java] at org.apache.jorphan.test.AllTests.main(AllTests.java:236) >> >> Which seems to be unrelated to saveservice change. It also appears >> without any change to properties. >> >> So I see no tests failing after the change. Does it mean that we can do >> the change right now? >> >> Andrey Pokhilko >> >> On 09/26/2014 04:24 PM, UBIK LOAD PACK Support wrote: >>> 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 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. >>>>> >>>>> >>>>> >> >
Re: [ANNOUNCE] Andrey Pohilko as new commiter on JMeter
Thanks to everyone! Glad to join JMeter team! Andrey Pokhilko On 10/13/2014 10:16 PM, Philippe Mouawad wrote: > The Project Management Committee (PMC) for Apache JMeter has asked Andrey > Pohilko to become a committer and we are pleased to announce that he has > accepted. > > Andrey Pohilko is founder of http://jmeter-plugins.org and among other > things a well-known performance expert. > > Being a committer allows many contributors to contribute more autonomously. > For developers, it makes it easier to submit changes and eliminates the > need to have contributions reviewed via the patch submission process. > Whether contributions are development-related or otherwise, it is a > recognition of a > contributor's participation in the project and commitment to the project and > the Apache Way. > > Please join me in congratulating Andrey ! > > -Philippe M. > For the JMeter PMC. >
Re: Migrating from SVN to GITHUB
+1 This would be great. DVCS'es has proven their strength and flexibility already. I guess some of Apache have some option to use GIT as main repository. I think the policy will not allow to use GitHub as primary source location. But GIT allows easy process of having GitHub repo as main workplace and pushing changes into primary repo in automated fashion. Andrey Pokhilko On 10/18/2014 05:06 PM, Philippe Mouawad wrote: > Hi, > What about migrating to Github some day ? > > Currently for us using SVN is good, but using Github would allow much > easier contribution by community through PR ? > Another possible improvement would be easier branching for bit more > complicated features. > > I wonder about the time it would take us to do this and if there is some > help from infrastructure on this ? > >
Re: [VOTE] Release JMeter 2.12 RC2
+0 Andrey Pokhilko On 11/08/2014 11:13 AM, Philippe Mouawad wrote: > Hello, > +1 (binding), I support this release. > > Thanks for RM. > Regards > Philippe M. > @philmdot > > > On Friday, November 7, 2014, Rainer Jung wrote: > >> Am 05.11.2014 um 23:17 schrieb Milamber: >> >>> Hello, >>> >>> The second release candidate for JMeter 2.12 (r1636949) has been >>> prepared, and your votes are solicited. >>> >> ... >> >> 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) >>> >> +1 (binding), thanks for RM. >> >> Details: >> >> - MD5 OK >> - signatures OK >> - key in KEYS file >> - gz and zip for src and bin consistent >> - svn and gz/zip mostly consistent >> - "bin/mirror-server" missing from dist, >> not a showstopper, since mirror-server.sh >> is included and mirror-server is only a trivial wrapper >> Fixed in svn by r1637321. >> - Revision number in line >> >> (expected) >> - builds fine >> - build result looks consistent with distribution, except for >> - timestamps in generated javadoc (expected) >> - should we exclude those? Javadoc has a flag to >> not generate the timestamps. >> - some whitespace in javadoc (expected) >> - binary jar files (expected) >> - no Javadoc warnings when building with Java 6 or 7 >> - some Javadoc warnings when building with Java 8 >> - Details see below >> - ran the tests (but only with java.awt.headless) >> - I have not checked the staging repository. >> - I have not checked tha rat report >> >> Build and tests were done using Java 1.6.0_45, 1.7.0_51 and 1.8.0, OS was >> Solaris 10 Sparc. >> >> Javadoc Warnings under Java 8: >> >> /src/core/org/apache/jmeter/JMeter.java:274: warning: no @param for args >> /src/core/org/apache/jmeter/JMeter.java:847: warning: no description for >> @param >> /src/reports/org/apache/jmeter/JMeterReport.java:299: warning: no >> description for @param >> /src/core/org/apache/jmeter/NewDriver.java:190: warning: no description >> for @param >> /src/core/org/apache/jmeter/NewDriver.java:200: warning: no description >> for @throws >> /src/core/org/apache/jmeter/util/BeanShellTestElement.java:137: warning: >> no description for @throws >> /src/core/org/apache/jmeter/testelement/TestElement.java:79: warning: no >> @return >> /src/core/org/apache/jmeter/testelement/TestElement.java:85: warning: no >> description for @param >> /src/core/org/apache/jmeter/testelement/TestElement.java:102: warning: no >> @param for key >> /src/core/org/apache/jmeter/testelement/TestElement.java:102: warning: no >> @return >> /src/core/org/apache/jmeter/testelement/TestElement.java:126: warning: no >> @param for run >> /src/core/org/apache/jmeter/testelement/TestElement.java:149: warning: no >> @param for property >> /src/core/org/apache/jmeter/testelement/TestElement.java:155: warning: no >> @param for propName >> /src/core/org/apache/jmeter/testelement/TestElement.java:155: warning: no >> @return >> /src/core/org/apache/jmeter/testelement/TestElement.java:173: warning: no >> @param for traverser >> /src/core/org/apache/jmeter/gui/Searchable.java:29: warning: no >> description for @throws >> /src/core/org/apache/jmeter/testelement/AbstractScopedTestElement.java:71: >> warning: no description for @param >> /src/core/org/apache/jmeter/testelement/AbstractScopedTestElement.java:81: >> warning: no description for @param >> /src/core/org/apache/jmeter/testelement/AbstractScopedTestElement.java:91: >> warning: no description for @param >> /src/core/org/apache/jmeter/testelement/AbstractScopedTestElement.java:101: >> warning: no description for @param >> /src/components/org/apache/jmeter/assertions/HTMLAssertion.java:260: >> warning: no description for @param >> /src/components/org/apache/jmeter/assertions/HTMLAssertion.java:273: >> warning: no description for @param >> /src/components/org/apache/jmeter/assertions/HTMLAssertion.java:282: >> warning: no description for @param >> /src/components/org/apache/jmeter/assertions/HTMLAssertion.java:298: >> warning: no description for @param >> /src/components/org/apache/jmeter/assertions/HTMLAssertion.java:371: >> warning: no description for @param >> /src/core/org/apache/jmet
Re: Drop Java 6 support for the next release?
+1 to drop support for Java 6 Since there is already Java 8 released and even Java 9 is on the horizon I expect for Java 7 to be stable enough and wide-spread. Andrey Pokhilko On 11/15/2014 10:00 PM, sebb wrote: > On 15 November 2014 18:27, Milamber wrote: >> Hello, >> >> I would open the discussion to remove the Java 6 support (End Of Life: >> Feb 2013) to JMeter for next release (in 2015 I think). >> >> I think, now, the Java 7 (or 8) is widespread on computer. >> >> For history: >> JMeter 2.9 (2013-01-28) drop the Java 1.5 support (EOL Oct 2009) >> JMeter 2.4 (2010-07-12) drop the Java 1.4 support (EOL Oct 2008) >> >> Note : Java 7 EOL is April 2015 >> >> >> Have you some special objections to remove the Java 6 support to JMeter? >> > JMeter is an a stand-alone application, and so other Java code is not > generally dependent on it. > > This means we have more freedom when deciding the minimum Java version. > If necessary, JMeter can be installed on a separate system with a more > recent version of Java. > > I think the main constraint is whether or not the Java version is > readily available and stable on a wide variety of platforms. > > Having said that, unless a newer version of Java offers significant > benefits, there is no point in forcing (some) users to upgrade Java. > > So: what are the features of Java 7 and/or 8 that would improve JMeter? > >> Milamber >> >> >> [ Oracle Java SE Support Roadmap] >> http://www.oracle.com/technetwork/java/eol-135779.html >>
Introduce connect times for SampleResult?
Hi, Many times I see a sence to have connect times measured separately, in addition to latency that we have in SampleResult. It is important when measuring a time for SSL handshake and DNS resolving, when users want to see it separate share in total Response Time. Connect time is available as separate metric in Grinder and Yandex.Tank. The latter has following details on response time pars: connect, send, latency, receive. Sometimes some parts are zero, but at least there is a technical possibility to see when it is non-zero. It should be noted that full breakdown would be: dns, connect, send, latency, receive. Send and receive times are not of great importance, IMO. And I would cope with connect time including DNS resolve time. But having connect time would add interesting aspect on results. For implementation it will require adding one more property with getters and setters to SampleResult, modifying SampleSaveConfiguration and UI settings to configure saving, using this new field in HTTP sampler, TCP sampler, maybe there are other samplers that can respect this field. As separate question I would raise if latency should not include connect time, for me it sounds logical, but changes existing behavior. Any opinions? -- Andrey Pokhilko
Re: Introduce connect times for SampleResult?
Happened to be not so much work: https://github.com/apache/jmeter/pull/11/files Please, review it and point me at any changes needed. Andrey Pokhilko On 11/29/2014 04:06 PM, sebb wrote: > On 29 November 2014 at 12:14, Andrey Pokhilko wrote: >> Hi, >> >> Many times I see a sence to have connect times measured separately, in >> addition to latency that we have in SampleResult. It is important when >> measuring a time for SSL handshake and DNS resolving, when users want to >> see it separate share in total Response Time. >> >> Connect time is available as separate metric in Grinder and Yandex.Tank. >> The latter has following details on response time pars: connect, send, >> latency, receive. Sometimes some parts are zero, but at least there is a >> technical possibility to see when it is non-zero. It should be noted >> that full breakdown would be: dns, connect, send, latency, receive. >> >> Send and receive times are not of great importance, IMO. And I would >> cope with connect time including DNS resolve time. But having connect >> time would add interesting aspect on results. > [I expect DNS resolve time might be very tricky to measure in Java] > >> For implementation it will require adding one more property with getters >> and setters to SampleResult, modifying SampleSaveConfiguration and UI >> settings to configure saving, using this new field in HTTP sampler, TCP >> sampler, maybe there are other samplers that can respect this field. > The docs would need to be updated to state whether a sampler supports > the metric or not. > >> As separate question I would raise if latency should not include connect >> time, for me it sounds logical, but changes existing behavior. > Connect time is currently included in both latency and elapsed. > > The simplest would be to just add connect as a separate time, but not > subtract it from latency or elapsed. > This would allow further analysis without changing behaviour. > Maybe add an option to perform the subtraction. > I don't think we should change the default behaviour. > >> Any opinions? > I can see its use and am not against it, but it needs quite a lot of > work to implement fully. > >> -- >> Andrey Pokhilko >>
Re: Introduce connect times for SampleResult?
No, it is not committed into SVN, you'll need to build it from the sources. Andrey Pokhilko On 12/04/2014 07:07 PM, Shmuel Krakower wrote: > Is it part of any nightly yet? > I'll give it a try... > > www.beatsoo.org - free application performance monitoring from world wide > locations. > On Dec 3, 2014 4:17 PM, "Andrey Pokhilko" wrote: > >> Happened to be not so much work: >> https://github.com/apache/jmeter/pull/11/files >> >> Please, review it and point me at any changes needed. >> >> Andrey Pokhilko >> >> On 11/29/2014 04:06 PM, sebb wrote: >>> On 29 November 2014 at 12:14, Andrey Pokhilko wrote: >>>> Hi, >>>> >>>> Many times I see a sence to have connect times measured separately, in >>>> addition to latency that we have in SampleResult. It is important when >>>> measuring a time for SSL handshake and DNS resolving, when users want to >>>> see it separate share in total Response Time. >>>> >>>> Connect time is available as separate metric in Grinder and Yandex.Tank. >>>> The latter has following details on response time pars: connect, send, >>>> latency, receive. Sometimes some parts are zero, but at least there is a >>>> technical possibility to see when it is non-zero. It should be noted >>>> that full breakdown would be: dns, connect, send, latency, receive. >>>> >>>> Send and receive times are not of great importance, IMO. And I would >>>> cope with connect time including DNS resolve time. But having connect >>>> time would add interesting aspect on results. >>> [I expect DNS resolve time might be very tricky to measure in Java] >>> >>>> For implementation it will require adding one more property with getters >>>> and setters to SampleResult, modifying SampleSaveConfiguration and UI >>>> settings to configure saving, using this new field in HTTP sampler, TCP >>>> sampler, maybe there are other samplers that can respect this field. >>> The docs would need to be updated to state whether a sampler supports >>> the metric or not. >>> >>>> As separate question I would raise if latency should not include connect >>>> time, for me it sounds logical, but changes existing behavior. >>> Connect time is currently included in both latency and elapsed. >>> >>> The simplest would be to just add connect as a separate time, but not >>> subtract it from latency or elapsed. >>> This would allow further analysis without changing behaviour. >>> Maybe add an option to perform the subtraction. >>> I don't think we should change the default behaviour. >>> >>>> Any opinions? >>> I can see its use and am not against it, but it needs quite a lot of >>> work to implement fully. >>> >>>> -- >>>> Andrey Pokhilko >>>> >>
Re: Introduce connect times for SampleResult?
Hi Philippe, This is a great help to have your code review, thanks! I tried to fix following items, please verify: * MeasuringConnectionManager#dnsResolver removed * Added Connect time into View Results in Table * ATT_CONNECT_TIME changed to ct * connectedTime and startedTime are removed, you are right about their origin * added License header and javadocs to MeasuringConnectionManager * fixed NPE source by removing the connManager field The items that I did not fix, but can fix if you will insist on it: * I don't agree that CSV_CONNECT_TIME should be changed to "Connection", for me "connect" is short of "connect time", and "connection" is about "connection state" or "connection object" * I don't think the 'PoolingClientConnectionManagerAdapter' makes our code easier to read. The approach to make Java class names more and more long has its limits. Finally, ask yourself, what is more obvious in this situation - MeasuringConnectionManager or PoolingClientConnectionManagerAdapter ? * I did not understand what is wrong with MeasuringConnectionRequest and MeasuringConnectionRequest classes being inner. What do you offer instead? * The SampleResult instance variable is the only way to have the same style as for latency, when you just call "connectEnd". Otherwise we need to get connectedTime and startedTime back and use simple getter. The only change that might make sense is to use WeakReference to shorten the lifetime of SampleResult. As I see in the code there is no ways currently to share the same HTTPClient between threads. Let's discuss, maybe with more opinions from other contributors, what's should be finally done with these items. NPE will be discussed in a different branch of emails. Andrey Pokhilko On 12/06/2014 04:34 PM, Philippe Mouawad wrote: > Hi, > I checked , it seems OK regarding multi-threading. > > Few more notes: > MeasuringConnectionManager#dnsResolver is not used > > Shouldn't connectTime be added to View Results in Table ? > > Regards > > > On Sat, Dec 6, 2014 at 2:51 PM, Philippe Mouawad > wrote: >> Hi, >> Note there is currently a bugzilla and patch (but partly outdated due to >> HttpSampler having been drastically reworked since that time) for this: >> >>- https://issues.apache.org/bugzilla/show_bug.cgi?id=48799 >> >> >> Regards >> >> On Sat, Dec 6, 2014 at 2:48 PM, Philippe Mouawad < >> philippe.moua...@gmail.com> wrote: >> >>> Hi, >>> My notes: >>> Naming: >>> - CSV_CONNECT_TIME , Connect should maybe be named Connection >>> - ATT_CONNECT_TIME should maybe be ct (for ConnectTime) instead of cn >>> - MeasuringConnectionManager should be >>> PoolingClientConnectionManagerAdapter ? >>> - MeasuringConnectionRequest should be ClientConnectionRequestAdapter ? >>> - MeasuredConnection should be >>> MeasuringConnectionManager is missing Apache License header and javadocs >>> :-) >>> >>> public class MeasuringConnectionRequest should not be public static class >>> MeasuringConnectionRequest ? >>> Same for MeasuredConnection ? >>> >>> MeasuredConnection : >>> connectedTime and startedTime are not used , I suppose it was a work in >>> progress code that was not deleted afterwards. >>> >>> >>> More in depth remarks: >>> - Are you sure about having SampleResult instance variable of >>> MeasuringConnectionManager ? >>> This should be checked as I am afraid you may end up sharing SampleResult >>> between different samples and threads. >>> I need more time to check this. >>> >>> Regards >>> Philippe M. >>> @philmdot >>> >>> >>> >>> >>> On Fri, Dec 5, 2014 at 9:55 PM, Philippe Mouawad < >>> philippe.moua...@gmail.com> wrote: >>> >>>> Nice, will try to review this we. >>>> >>>> >>>> On Friday, December 5, 2014, Rainer Jung >>>> wrote: >>>> >>>>> Am 03.12.2014 um 15:15 schrieb Andrey Pokhilko: >>>>> >>>>>> Happened to be not so much work: >>>>>> https://github.com/apache/jmeter/pull/11/files >>>>>> >>>>>> Please, review it and point me at any changes needed. >>>>>> >>>>> I didn't review the patch but I patched a 2.12 I'm currently using to >>>>> probe a service and it seems to run well here. >>>>> >>&g
Re: Introduce connect times for SampleResult?
Note that I made classes private static, because they seems have no use outside connection manager. Is it OK? Andrey Pokhilko On 12/07/2014 03:37 PM, Philippe Mouawad wrote: > On Sun, Dec 7, 2014 at 1:38 PM, Andrey Pokhilko wrote: > >> Hi Philippe, >> >> This is a great help to have your code review, thanks! I tried to fix >> following items, please verify: >> >> * MeasuringConnectionManager#dnsResolver removed >> * Added Connect time into View Results in Table >> * ATT_CONNECT_TIME changed to ct >> * connectedTime and startedTime are removed, you are right about their >> origin >> * added License header and javadocs to MeasuringConnectionManager >> * fixed NPE source by removing the connManager field >> >> >> The items that I did not fix, but can fix if you will insist on it: >> >> * I don't agree that CSV_CONNECT_TIME should be changed to >> "Connection", for me "connect" is short of "connect time", and >> "connection" is about "connection state" or "connection object" >> > Ok just a matter of opinion :-) > >> * I don't think the 'PoolingClientConnectionManagerAdapter' makes our >> code easier to read. The approach to make Java class names more and >> more long has its limits. Finally, ask yourself, what is more >> obvious in this situation - MeasuringConnectionManager or >> PoolingClientConnectionManagerAdapter ? >> > Ok just a matter of opinion :-) , I named them after pattern, you name > them after their use , ok for me. > > >> * I did not understand what is wrong with MeasuringConnectionRequest >> and MeasuringConnectionRequest classes being inner. What do you >> offer instead? >> > I am asking to make the public static class instead of public class. There > is no benefit of making them public class and you hold uselessly a > reference to MeasuringConnectionManager instance > > * The SampleResult instance variable is the only way to have the same >> style as for latency, when you just call "connectEnd". Otherwise we >> need to get connectedTime and startedTime back and use simple >> getter. The only change that might make sense is to use >> WeakReference to shorten the lifetime of SampleResult. As I see in >> the code there is no ways currently to share the same HTTPClient >> between threads. >> > Ok, as I said in the following mail there was no issue except the NPE. I > will check new PR. > >> Let's discuss, maybe with more opinions from other contributors, what's >> should be finally done with these items. >> >> NPE will be discussed in a different branch of emails. >> >> Andrey Pokhilko >> >> On 12/06/2014 04:34 PM, Philippe Mouawad wrote: >>> Hi, >>> I checked , it seems OK regarding multi-threading. >>> >>> Few more notes: >>> MeasuringConnectionManager#dnsResolver is not used >>> >>> Shouldn't connectTime be added to View Results in Table ? >>> >>> Regards >>> >>> >>> On Sat, Dec 6, 2014 at 2:51 PM, Philippe Mouawad < >> philippe.moua...@gmail.com >>>> wrote: >>>> Hi, >>>> Note there is currently a bugzilla and patch (but partly outdated due to >>>> HttpSampler having been drastically reworked since that time) for this: >>>> >>>>- https://issues.apache.org/bugzilla/show_bug.cgi?id=48799 >>>> >>>> >>>> Regards >>>> >>>> On Sat, Dec 6, 2014 at 2:48 PM, Philippe Mouawad < >>>> philippe.moua...@gmail.com> wrote: >>>> >>>>> Hi, >>>>> My notes: >>>>> Naming: >>>>> - CSV_CONNECT_TIME , Connect should maybe be named Connection >>>>> - ATT_CONNECT_TIME should maybe be ct (for ConnectTime) instead of cn >>>>> - MeasuringConnectionManager should be >>>>> PoolingClientConnectionManagerAdapter ? >>>>> - MeasuringConnectionRequest should be ClientConnectionRequestAdapter ? >>>>> - MeasuredConnection should be >>>>> MeasuringConnectionManager is missing Apache License header and >> javadocs >>>>> :-) >>>>> >>>>> public class MeasuringConnectionRequest should not be public static >> class >>>>> MeasuringConnectionRequest ? >>>>> Same for MeasuredConnection ? >>>>> >>>>&g
Re: Introduce connect times for SampleResult?
Is there anything else that I should add to commit? Changelog records etc? Is there a document for commit requirements? Andrey Pokhilko On 12/15/2014 12:28 AM, Philippe Mouawad wrote: > Hi, > Sounds ok for commit for me. > > Regards > > On Sunday, December 7, 2014, Andrey Pokhilko wrote: > >> Note that I made classes private static, because they seems have no use >> outside connection manager. Is it OK? >> >> Andrey Pokhilko >> >> On 12/07/2014 03:37 PM, Philippe Mouawad wrote: >>> On Sun, Dec 7, 2014 at 1:38 PM, Andrey Pokhilko > > wrote: >>>> Hi Philippe, >>>> >>>> This is a great help to have your code review, thanks! I tried to fix >>>> following items, please verify: >>>> >>>> * MeasuringConnectionManager#dnsResolver removed >>>> * Added Connect time into View Results in Table >>>> * ATT_CONNECT_TIME changed to ct >>>> * connectedTime and startedTime are removed, you are right about their >>>> origin >>>> * added License header and javadocs to MeasuringConnectionManager >>>> * fixed NPE source by removing the connManager field >>>> >>>> >>>> The items that I did not fix, but can fix if you will insist on it: >>>> >>>> * I don't agree that CSV_CONNECT_TIME should be changed to >>>> "Connection", for me "connect" is short of "connect time", and >>>> "connection" is about "connection state" or "connection object" >>>> >>> Ok just a matter of opinion :-) >>> >>>> * I don't think the 'PoolingClientConnectionManagerAdapter' makes our >>>> code easier to read. The approach to make Java class names more and >>>> more long has its limits. Finally, ask yourself, what is more >>>> obvious in this situation - MeasuringConnectionManager or >>>> PoolingClientConnectionManagerAdapter ? >>>> >>> Ok just a matter of opinion :-) , I named them after pattern, you name >>> them after their use , ok for me. >>> >>> >>>> * I did not understand what is wrong with MeasuringConnectionRequest >>>> and MeasuringConnectionRequest classes being inner. What do you >>>> offer instead? >>>> >>> I am asking to make the public static class instead of public class. >> There >>> is no benefit of making them public class and you hold uselessly a >>> reference to MeasuringConnectionManager instance >>> >>> * The SampleResult instance variable is the only way to have the same >>>> style as for latency, when you just call "connectEnd". Otherwise we >>>> need to get connectedTime and startedTime back and use simple >>>> getter. The only change that might make sense is to use >>>> WeakReference to shorten the lifetime of SampleResult. As I see in >>>> the code there is no ways currently to share the same HTTPClient >>>> between threads. >>>> >>> Ok, as I said in the following mail there was no issue except the NPE. I >>> will check new PR. >>> >>>> Let's discuss, maybe with more opinions from other contributors, what's >>>> should be finally done with these items. >>>> >>>> NPE will be discussed in a different branch of emails. >>>> >>>> Andrey Pokhilko >>>> >>>> On 12/06/2014 04:34 PM, Philippe Mouawad wrote: >>>>> Hi, >>>>> I checked , it seems OK regarding multi-threading. >>>>> >>>>> Few more notes: >>>>> MeasuringConnectionManager#dnsResolver is not used >>>>> >>>>> Shouldn't connectTime be added to View Results in Table ? >>>>> >>>>> Regards >>>>> >>>>> >>>>> On Sat, Dec 6, 2014 at 2:51 PM, Philippe Mouawad < >>>> philippe.moua...@gmail.com >>>>>> wrote: >>>>>> Hi, >>>>>> Note there is currently a bugzilla and patch (but partly outdated due >> to >>>>>> HttpSampler having been drastically reworked since that time) for >> this: >>>>>>- https://issues.apache.org/bugzilla/show_bug.cgi?id=48799 >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>&g
Re: Introduce connect times for SampleResult?
What to do with test failure messages like this: [java] Loading file testfiles/AssertionTestPlan.jmx and saving it back changes its size from 6214 to 6306. [java] Number of lines changes from 121 to 123 Should I modify the JMXes in tests? And this: [java] 1) checkI18n(org.apache.jmeter.resources.PackageTest)junit.framework.AssertionFailedError: 1 missing labels, labels missing:Missing labels in bundle:org/apache/jmeter/resources/messages_fr.properties [java] save_connecttime=Save Connect Time [java] table_visualizer_connect=Connect [java] view_results_connect_time=Connect Time: I don't know French, sorry :( And I wonder why it requires it... Andrey Pokhilko On 12/15/2014 08:22 PM, Philippe Mouawad wrote: > Hi, > You need to update docs and component_reference.xml or any doc that > currently mentions other reported indicators, don't forget screenshots if > any are deprecated. > Also fill in changes.xml with bug id at the right place, and when commiting > put in comment the bug ID + the bugzilla full title. > > YOu need to commit files all in 1. > Once done, take the mail your receive with commit and copy the line > starting after author and just before commit files changes details, and put > this in the bugzilla that you close as resolved. > > Regards > > > > > > On Mon, Dec 15, 2014 at 9:18 AM, Andrey Pokhilko wrote: >> Is there anything else that I should add to commit? Changelog records >> etc? Is there a document for commit requirements? >> >> Andrey Pokhilko >> >> On 12/15/2014 12:28 AM, Philippe Mouawad wrote: >>> Hi, >>> Sounds ok for commit for me. >>> >>> Regards >>> >>> On Sunday, December 7, 2014, Andrey Pokhilko wrote: >>> >>>> Note that I made classes private static, because they seems have no use >>>> outside connection manager. Is it OK? >>>> >>>> Andrey Pokhilko >>>> >>>> On 12/07/2014 03:37 PM, Philippe Mouawad wrote: >>>>> On Sun, Dec 7, 2014 at 1:38 PM, Andrey Pokhilko >>> > wrote: >>>>>> Hi Philippe, >>>>>> >>>>>> This is a great help to have your code review, thanks! I tried to fix >>>>>> following items, please verify: >>>>>> >>>>>> * MeasuringConnectionManager#dnsResolver removed >>>>>> * Added Connect time into View Results in Table >>>>>> * ATT_CONNECT_TIME changed to ct >>>>>> * connectedTime and startedTime are removed, you are right about >> their >>>>>> origin >>>>>> * added License header and javadocs to MeasuringConnectionManager >>>>>> * fixed NPE source by removing the connManager field >>>>>> >>>>>> >>>>>> The items that I did not fix, but can fix if you will insist on it: >>>>>> >>>>>> * I don't agree that CSV_CONNECT_TIME should be changed to >>>>>> "Connection", for me "connect" is short of "connect time", and >>>>>> "connection" is about "connection state" or "connection object" >>>>>> >>>>> Ok just a matter of opinion :-) >>>>> >>>>>> * I don't think the 'PoolingClientConnectionManagerAdapter' makes >> our >>>>>> code easier to read. The approach to make Java class names more >> and >>>>>> more long has its limits. Finally, ask yourself, what is more >>>>>> obvious in this situation - MeasuringConnectionManager or >>>>>> PoolingClientConnectionManagerAdapter ? >>>>>> >>>>> Ok just a matter of opinion :-) , I named them after pattern, you >> name >>>>> them after their use , ok for me. >>>>> >>>>> >>>>>> * I did not understand what is wrong with MeasuringConnectionRequest >>>>>> and MeasuringConnectionRequest classes being inner. What do you >>>>>> offer instead? >>>>>> >>>>> I am asking to make the public static class instead of public class. >>>> There >>>>> is no benefit of making them public class and you hold uselessly a >>>>> reference to MeasuringConnectionManager instance >>>>> >>>>> * The SampleResult instance variable is the only way to have the same >>>>>> style as for la
Re: Introduce connect times for SampleResult?
Ok, I commited it without French. But I have no mail after the commit... Andrey Pokhilko On 12/15/2014 08:22 PM, Philippe Mouawad wrote: > Hi, > You need to update docs and component_reference.xml or any doc that > currently mentions other reported indicators, don't forget screenshots if > any are deprecated. > Also fill in changes.xml with bug id at the right place, and when commiting > put in comment the bug ID + the bugzilla full title. > > YOu need to commit files all in 1. > Once done, take the mail your receive with commit and copy the line > starting after author and just before commit files changes details, and put > this in the bugzilla that you close as resolved. > > Regards > > > > > > On Mon, Dec 15, 2014 at 9:18 AM, Andrey Pokhilko wrote: >> Is there anything else that I should add to commit? Changelog records >> etc? Is there a document for commit requirements? >> >> Andrey Pokhilko >> >> On 12/15/2014 12:28 AM, Philippe Mouawad wrote: >>> Hi, >>> Sounds ok for commit for me. >>> >>> Regards >>> >>> On Sunday, December 7, 2014, Andrey Pokhilko wrote: >>> >>>> Note that I made classes private static, because they seems have no use >>>> outside connection manager. Is it OK? >>>> >>>> Andrey Pokhilko >>>> >>>> On 12/07/2014 03:37 PM, Philippe Mouawad wrote: >>>>> On Sun, Dec 7, 2014 at 1:38 PM, Andrey Pokhilko >>> > wrote: >>>>>> Hi Philippe, >>>>>> >>>>>> This is a great help to have your code review, thanks! I tried to fix >>>>>> following items, please verify: >>>>>> >>>>>> * MeasuringConnectionManager#dnsResolver removed >>>>>> * Added Connect time into View Results in Table >>>>>> * ATT_CONNECT_TIME changed to ct >>>>>> * connectedTime and startedTime are removed, you are right about >> their >>>>>> origin >>>>>> * added License header and javadocs to MeasuringConnectionManager >>>>>> * fixed NPE source by removing the connManager field >>>>>> >>>>>> >>>>>> The items that I did not fix, but can fix if you will insist on it: >>>>>> >>>>>> * I don't agree that CSV_CONNECT_TIME should be changed to >>>>>> "Connection", for me "connect" is short of "connect time", and >>>>>> "connection" is about "connection state" or "connection object" >>>>>> >>>>> Ok just a matter of opinion :-) >>>>> >>>>>> * I don't think the 'PoolingClientConnectionManagerAdapter' makes >> our >>>>>> code easier to read. The approach to make Java class names more >> and >>>>>> more long has its limits. Finally, ask yourself, what is more >>>>>> obvious in this situation - MeasuringConnectionManager or >>>>>> PoolingClientConnectionManagerAdapter ? >>>>>> >>>>> Ok just a matter of opinion :-) , I named them after pattern, you >> name >>>>> them after their use , ok for me. >>>>> >>>>> >>>>>> * I did not understand what is wrong with MeasuringConnectionRequest >>>>>> and MeasuringConnectionRequest classes being inner. What do you >>>>>> offer instead? >>>>>> >>>>> I am asking to make the public static class instead of public class. >>>> There >>>>> is no benefit of making them public class and you hold uselessly a >>>>> reference to MeasuringConnectionManager instance >>>>> >>>>> * The SampleResult instance variable is the only way to have the same >>>>>> style as for latency, when you just call "connectEnd". Otherwise >> we >>>>>> need to get connectedTime and startedTime back and use simple >>>>>> getter. The only change that might make sense is to use >>>>>> WeakReference to shorten the lifetime of SampleResult. As I see in >>>>>> the code there is no ways currently to share the same HTTPClient >>>>>> between threads. >>>>>> >>>>> Ok, as I said in the following mail there was no issue except the >> NPE. I >&
Re: svn commit: r1649629 - in /jmeter/trunk: bin/ bin/testfiles/ src/components/org/apache/jmeter/visualizers/ src/core/org/apache/jmeter/control/ src/core/org/apache/jmeter/resources/ src/core/org/ap
About modifying JMXses: As far as I understand how JMeter works, it applies the default (which is "false") when no configuration property provided. But then when it saves the JMX, it writes all the properties, including those with default values. I did change to JMXses since somewhere in the tests there is a check that JMX must stay unchanged upon open and save. If I'm wrong and there is some other way to make those tests passing, please tell it to me and I'll roll back the undesired changes. Andrey Pokhilko On 01/06/2015 05:48 AM, sebb wrote: > On 5 January 2015 at 19:49, wrote: >> Author: undera >> Date: Mon Jan 5 19:49:06 2015 >> New Revision: 1649629 >> >> URL: http://svn.apache.org/r1649629 >> Log: >> 48799 - Add connect time to output metrics >> >> Added: >> >> jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/MeasuringConnectionManager.java >> Modified: >> jmeter/trunk/bin/jmeter.properties >> jmeter/trunk/bin/testfiles/AssertionTestPlan.jmx >> jmeter/trunk/bin/testfiles/AuthManagerTestPlan.jmx >> jmeter/trunk/bin/testfiles/GenTest210.jmx >> jmeter/trunk/bin/testfiles/GenTest27.jmx >> jmeter/trunk/bin/testfiles/GuiTest.jmx >> jmeter/trunk/bin/testfiles/GuiTest231.jmx >> jmeter/trunk/bin/testfiles/HeaderManagerTestPlan.jmx >> jmeter/trunk/bin/testfiles/InterleaveTestPlan.jmx >> jmeter/trunk/bin/testfiles/InterleaveTestPlan2.jmx >> jmeter/trunk/bin/testfiles/LoopTestPlan.jmx >> jmeter/trunk/bin/testfiles/OnceOnlyTestPlan.jmx >> jmeter/trunk/bin/testfiles/SimpleTestPlan.jmx >> >> jmeter/trunk/src/components/org/apache/jmeter/visualizers/SamplerResultTab.java >> >> jmeter/trunk/src/components/org/apache/jmeter/visualizers/TableVisualizer.java >> >> jmeter/trunk/src/core/org/apache/jmeter/control/TransactionController.java >> jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties >> jmeter/trunk/src/core/org/apache/jmeter/samplers/SampleResult.java >> >> jmeter/trunk/src/core/org/apache/jmeter/samplers/SampleSaveConfiguration.java >> >> jmeter/trunk/src/core/org/apache/jmeter/samplers/StatisticalSampleResult.java >> jmeter/trunk/src/core/org/apache/jmeter/save/CSVSaveService.java >> >> jmeter/trunk/src/core/org/apache/jmeter/save/converters/SampleResultConverter.java >> jmeter/trunk/src/core/org/apache/jmeter/visualizers/TableSample.java >> >> jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java >> >> jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/sampler/JDBCSampler.java >> jmeter/trunk/xdocs/changes.xml >> jmeter/trunk/xdocs/usermanual/glossary.xml >> jmeter/trunk/xdocs/usermanual/listeners.xml >> >> Modified: jmeter/trunk/bin/jmeter.properties >> URL: >> http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.properties?rev=1649629&r1=1649628&r2=1649629&view=diff >> == >> --- jmeter/trunk/bin/jmeter.properties (original) >> +++ jmeter/trunk/bin/jmeter.properties Mon Jan 5 19:49:06 2015 >> @@ -465,6 +465,7 @@ log_level.jorphan=INFO >> #jmeter.save.saveservice.subresults=true >> #jmeter.save.saveservice.assertions=true >> #jmeter.save.saveservice.latency=true >> +#jmeter.save.saveservice.connect_time=false >> #jmeter.save.saveservice.samplerData=false >> #jmeter.save.saveservice.responseHeaders=false >> #jmeter.save.saveservice.requestHeaders=false >> >> Modified: jmeter/trunk/bin/testfiles/AssertionTestPlan.jmx >> URL: >> http://svn.apache.org/viewvc/jmeter/trunk/bin/testfiles/AssertionTestPlan.jmx?rev=1649629&r1=1649628&r2=1649629&view=diff >> == >> --- jmeter/trunk/bin/testfiles/AssertionTestPlan.jmx (original) >> +++ jmeter/trunk/bin/testfiles/AssertionTestPlan.jmx Mon Jan 5 19:49:06 2015 > -1 to this change. > Similarly for the other JMX files. > > The code needs to be set up to default to false if the tag is not present. > >> @@ -60,6 +60,7 @@ >> >>true >>true >> + false >>true >>true >>true >> @@ -91,6 +92,7 @@ >> >>true >>true >> + false >>true >>true &
Re: svn commit: r1649629 - in /jmeter/trunk: bin/ bin/testfiles/ src/components/org/apache/jmeter/visualizers/ src/core/org/apache/jmeter/control/ src/core/org/apache/jmeter/resources/ src/core/org/ap
Thanks Felix, I committed all proposed fixes except "not all samplers support this", as I believe this statement is more correct for the future updates, where some more samplers might support it. Andrey Pokhilko On 01/06/2015 11:54 AM, Felix Schumacher wrote: > Hi Andrey, > > I have only a few nitpicks. > > In the constructor of MeasuringConnectionManager I would rename the > variable aDefault to something like schemeRegistry. > > The javadoc for the private class MeasuringConnectionRequest starts > with "And", but I believe you meant "An". > > In the glossary you wrote "estable", but I think it should be > "establish". > > In listeners.xml there is a note about "not all samplers support > this", as I see it by now only httpclient 4 supports it ;) > > Thanks for your first commit. > > Felix > > Am 05.01.2015 um 20:49 schrieb und...@apache.org: >> Author: undera >> Date: Mon Jan 5 19:49:06 2015 >> New Revision: 1649629 >> >> URL: http://svn.apache.org/r1649629 >> Log: >> 48799 - Add connect time to output metrics >> >> Added: >> >> jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/MeasuringConnectionManager.java >> Modified: >> jmeter/trunk/bin/jmeter.properties >> jmeter/trunk/bin/testfiles/AssertionTestPlan.jmx >> jmeter/trunk/bin/testfiles/AuthManagerTestPlan.jmx >> jmeter/trunk/bin/testfiles/GenTest210.jmx >> jmeter/trunk/bin/testfiles/GenTest27.jmx >> jmeter/trunk/bin/testfiles/GuiTest.jmx >> jmeter/trunk/bin/testfiles/GuiTest231.jmx >> jmeter/trunk/bin/testfiles/HeaderManagerTestPlan.jmx >> jmeter/trunk/bin/testfiles/InterleaveTestPlan.jmx >> jmeter/trunk/bin/testfiles/InterleaveTestPlan2.jmx >> jmeter/trunk/bin/testfiles/LoopTestPlan.jmx >> jmeter/trunk/bin/testfiles/OnceOnlyTestPlan.jmx >> jmeter/trunk/bin/testfiles/SimpleTestPlan.jmx >> >> jmeter/trunk/src/components/org/apache/jmeter/visualizers/SamplerResultTab.java >> >> jmeter/trunk/src/components/org/apache/jmeter/visualizers/TableVisualizer.java >> >> jmeter/trunk/src/core/org/apache/jmeter/control/TransactionController.java >> >> jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties >> jmeter/trunk/src/core/org/apache/jmeter/samplers/SampleResult.java >> >> jmeter/trunk/src/core/org/apache/jmeter/samplers/SampleSaveConfiguration.java >> >> jmeter/trunk/src/core/org/apache/jmeter/samplers/StatisticalSampleResult.java >> jmeter/trunk/src/core/org/apache/jmeter/save/CSVSaveService.java >> >> jmeter/trunk/src/core/org/apache/jmeter/save/converters/SampleResultConverter.java >> >> jmeter/trunk/src/core/org/apache/jmeter/visualizers/TableSample.java >> >> jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java >> >> jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/sampler/JDBCSampler.java >> jmeter/trunk/xdocs/changes.xml >> jmeter/trunk/xdocs/usermanual/glossary.xml >> jmeter/trunk/xdocs/usermanual/listeners.xml >> >> Modified: jmeter/trunk/bin/jmeter.properties >> URL: >> http://svn.apache.org/viewvc/jmeter/trunk/bin/jmeter.properties?rev=1649629&r1=1649628&r2=1649629&view=diff >> == >> >> --- jmeter/trunk/bin/jmeter.properties (original) >> +++ jmeter/trunk/bin/jmeter.properties Mon Jan 5 19:49:06 2015 >> @@ -465,6 +465,7 @@ log_level.jorphan=INFO >> #jmeter.save.saveservice.subresults=true >> #jmeter.save.saveservice.assertions=true >> #jmeter.save.saveservice.latency=true >> +#jmeter.save.saveservice.connect_time=false >> #jmeter.save.saveservice.samplerData=false >> #jmeter.save.saveservice.responseHeaders=false >> #jmeter.save.saveservice.requestHeaders=false >> >> Modified: jmeter/trunk/bin/testfiles/AssertionTestPlan.jmx >> URL: >> http://svn.apache.org/viewvc/jmeter/trunk/bin/testfiles/AssertionTestPlan.jmx?rev=1649629&r1=1649628&r2=1649629&view=diff >> == >> >> --- jmeter/trunk/bin/testfiles/AssertionTestPlan.jmx (original) >> +++ jmeter/trunk/bin/testfiles/AssertionTestPlan.jmx Mon Jan 5 >> 19:49:06 2015 >> @@ -60,6 +60,7 @@ >> >> true >> true >> + false >>
Re: svn commit: r1649629 - in /jmeter/trunk: bin/ bin/testfiles/ src/components/org/apache/jmeter/visualizers/ src/core/org/apache/jmeter/control/ src/core/org/apache/jmeter/resources/ src/core/org/ap
I'm sorry, but I don't understand how this relates to the SampleSaveConfiguration, which generates this piece of JMX... I have correct defaults specified for connect times, it is false both in the code and in the jmeter.properties. I used no string "magic" strings in my code, did everything just like it is done for latency. I think this change in JMXses is unavoidable, since JMeter writes into JMX all sample save flags, including those with default values. I see the sense of this behavior to make JMXses consistently portable between different JMeter installation. Am I wrong? Andrey Pokhilko On 01/06/2015 03:45 PM, sebb wrote: > On 6 January 2015 at 08:25, Andrey Pokhilko wrote: >> About modifying JMXses: >> >> As far as I understand how JMeter works, it applies the default (which >> is "false") when no configuration property provided. > Yes, assuming that the default is correctly defined. > >> But then when it >> saves the JMX, it writes all the properties, including those with >> default values. > That depends on how the code writes the values. > There is a property setter that takes a default value; if the value > matches the default, it removes the property instead of writing it. > > This is done to avoid cluttering up the JMX files, and to assist with > backwards compatibiity. > > See for example > > AuthManager.setClearEachIteration(boolean clear) > > Note that the same constant (DEFAULT_CLEAR_VALUE) is used for both get and > set. > It's vital that the same value is used for get and set - and the value > must never change. > >> I did change to JMXses since somewhere in the tests there is a check >> that JMX must stay unchanged upon open and save. If I'm wrong and there >> is some other way to make those tests passing, please tell it to me and >> I'll roll back the undesired changes. >> >> Andrey Pokhilko >> >> On 01/06/2015 05:48 AM, sebb wrote: >>> On 5 January 2015 at 19:49, wrote: >>>> Author: undera >>>> Date: Mon Jan 5 19:49:06 2015 >>>> New Revision: 1649629 >>>> >>>> URL: http://svn.apache.org/r1649629 >>>> Log: >>>> 48799 - Add connect time to output metrics >>>> >>>> Added: >>>> >>>> jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/MeasuringConnectionManager.java >>>> Modified: >>>> jmeter/trunk/bin/jmeter.properties >>>> jmeter/trunk/bin/testfiles/AssertionTestPlan.jmx >>>> jmeter/trunk/bin/testfiles/AuthManagerTestPlan.jmx >>>> jmeter/trunk/bin/testfiles/GenTest210.jmx >>>> jmeter/trunk/bin/testfiles/GenTest27.jmx >>>> jmeter/trunk/bin/testfiles/GuiTest.jmx >>>> jmeter/trunk/bin/testfiles/GuiTest231.jmx >>>> jmeter/trunk/bin/testfiles/HeaderManagerTestPlan.jmx >>>> jmeter/trunk/bin/testfiles/InterleaveTestPlan.jmx >>>> jmeter/trunk/bin/testfiles/InterleaveTestPlan2.jmx >>>> jmeter/trunk/bin/testfiles/LoopTestPlan.jmx >>>> jmeter/trunk/bin/testfiles/OnceOnlyTestPlan.jmx >>>> jmeter/trunk/bin/testfiles/SimpleTestPlan.jmx >>>> >>>> jmeter/trunk/src/components/org/apache/jmeter/visualizers/SamplerResultTab.java >>>> >>>> jmeter/trunk/src/components/org/apache/jmeter/visualizers/TableVisualizer.java >>>> >>>> jmeter/trunk/src/core/org/apache/jmeter/control/TransactionController.java >>>> jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties >>>> jmeter/trunk/src/core/org/apache/jmeter/samplers/SampleResult.java >>>> >>>> jmeter/trunk/src/core/org/apache/jmeter/samplers/SampleSaveConfiguration.java >>>> >>>> jmeter/trunk/src/core/org/apache/jmeter/samplers/StatisticalSampleResult.java >>>> jmeter/trunk/src/core/org/apache/jmeter/save/CSVSaveService.java >>>> >>>> jmeter/trunk/src/core/org/apache/jmeter/save/converters/SampleResultConverter.java >>>> jmeter/trunk/src/core/org/apache/jmeter/visualizers/TableSample.java >>>> >>>> jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java >>>> >>>> jmeter/trunk/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/sampler/JDBCSampler.java >>>> jmeter/trunk/xdocs/changes.xml >>>> jmeter/trunk/xdocs/usermanual/glossary.xml >>>> jmeter/trunk/xdocs/usermanual/listeners.xml >>>> &
Re: svn commit: r1649629 - in /jmeter/trunk: bin/ bin/testfiles/ src/components/org/apache/jmeter/visualizers/ src/core/org/apache/jmeter/control/ src/core/org/apache/jmeter/resources/ src/core/org/ap
If I will rever changes in JMXses, the tests will break. Could you please tell me where to fix in the code the adding for the new flag? Excuse me, but AuthManager is unrelated example, since the flag in SampleSaveConfiguration is not a JMeter property, it is just regular class field with getter and setter... Andrey Pokhilko On 01/06/2015 03:58 PM, sebb wrote: > On 6 January 2015 at 12:45, sebb wrote: >> On 6 January 2015 at 08:25, Andrey Pokhilko wrote: >>> About modifying JMXses: >>> >>> As far as I understand how JMeter works, it applies the default (which >>> is "false") when no configuration property provided. >> Yes, assuming that the default is correctly defined. >> >>> But then when it >>> saves the JMX, it writes all the properties, including those with >>> default values. >> That depends on how the code writes the values. >> There is a property setter that takes a default value; if the value >> matches the default, it removes the property instead of writing it. >> >> This is done to avoid cluttering up the JMX files, and to assist with >> backwards compatibiity. >> >> See for example >> >> AuthManager.setClearEachIteration(boolean clear) >> >> Note that the same constant (DEFAULT_CLEAR_VALUE) is used for both get and >> set. >> It's vital that the same value is used for get and set - and the value >> must never change. > Forgot to add that boolean properties are often read with > getPropertyAsBoolean(String) > This uses an implied default of false. > > Also that this rule currently only applies to new properties. > Existing properties should be left as is for now. > We might want to revisit that if we are sure that dropping the JMX > entries cannot cause any compatibility issues. > That has not been determined yet. > > But at least if the default entries are omitted for new properties, > the JMX files won't get larger and larger. > >>> I did change to JMXses since somewhere in the tests there is a check >>> that JMX must stay unchanged upon open and save. > Yes, part of the point of those unit tests is to check for > incompatibilities between versions. > > The JMX test files should hardly ever need changing. > > If an existing test starts failing when code is changed, then the most > likely cause is a bug in the new code, not an error in the test case. > Test cases should only be changed if it is clear that the test case is > at fault rather than the code. > >>> If I'm wrong and there >>> is some other way to make those tests passing, please tell it to me and >>> I'll roll back the undesired changes. >>> > Please
Re: svn commit: r1649629 - in /jmeter/trunk: bin/ bin/testfiles/ src/components/org/apache/jmeter/visualizers/ src/core/org/apache/jmeter/control/ src/core/org/apache/jmeter/resources/ src/core/org/ap
Thanks for pointing to the right place, I'll work on it right now. Andrey Pokhilko On 01/06/2015 04:10 PM, sebb wrote: > Ah - that class is different; the data is saved in > SampleSaveConfigurationConverter > But the principle is the same; don't save new properties unnecessarily. > > There is a comment at the beginning of the SampleSaveConfiguration > class which details all the changes that have to be made when adding a > new field, this includes: > > * - update SampleSaveConfigurationConverter to add new fields to > marshall() and shouldSerialiseMember() > > The sample config is used in lots of places so changes affect lots of classes. > > Maybe one could do something clever with annotations so that some of > this config was no longer necessary, > But that will be quite a lot of work for something that rarely changes. > > In the meantime, the unit tests hopefully catch any errors. > > On 6 January 2015 at 12:56, Andrey Pokhilko wrote: >> I'm sorry, but I don't understand how this relates to the >> SampleSaveConfiguration, which generates this piece of JMX... I have >> correct defaults specified for connect times, it is false both in the >> code and in the jmeter.properties. I used no string "magic" strings in >> my code, did everything just like it is done for latency. I think this >> change in JMXses is unavoidable, since JMeter writes into JMX all sample >> save flags, including those with default values. I see the sense of this >> behavior to make JMXses consistently portable between different JMeter >> installation. >> >> Am I wrong? >> >> Andrey Pokhilko >> >> On 01/06/2015 03:45 PM, sebb wrote: >>> On 6 January 2015 at 08:25, Andrey Pokhilko wrote: >>>> About modifying JMXses: >>>> >>>> As far as I understand how JMeter works, it applies the default (which >>>> is "false") when no configuration property provided. >>> Yes, assuming that the default is correctly defined. >>> >>>> But then when it >>>> saves the JMX, it writes all the properties, including those with >>>> default values. >>> That depends on how the code writes the values. >>> There is a property setter that takes a default value; if the value >>> matches the default, it removes the property instead of writing it. >>> >>> This is done to avoid cluttering up the JMX files, and to assist with >>> backwards compatibiity. >>> >>> See for example >>> >>> AuthManager.setClearEachIteration(boolean clear) >>> >>> Note that the same constant (DEFAULT_CLEAR_VALUE) is used for both get and >>> set. >>> It's vital that the same value is used for get and set - and the value >>> must never change. >>> >>>> I did change to JMXses since somewhere in the tests there is a check >>>> that JMX must stay unchanged upon open and save. If I'm wrong and there >>>> is some other way to make those tests passing, please tell it to me and >>>> I'll roll back the undesired changes. >>>> >>>> Andrey Pokhilko >>>> >>>> On 01/06/2015 05:48 AM, sebb wrote: >>>>> On 5 January 2015 at 19:49, wrote: >>>>>> Author: undera >>>>>> Date: Mon Jan 5 19:49:06 2015 >>>>>> New Revision: 1649629 >>>>>> >>>>>> URL: http://svn.apache.org/r1649629 >>>>>> Log: >>>>>> 48799 - Add connect time to output metrics >>>>>> >>>>>> Added: >>>>>> >>>>>> jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/MeasuringConnectionManager.java >>>>>> Modified: >>>>>> jmeter/trunk/bin/jmeter.properties >>>>>> jmeter/trunk/bin/testfiles/AssertionTestPlan.jmx >>>>>> jmeter/trunk/bin/testfiles/AuthManagerTestPlan.jmx >>>>>> jmeter/trunk/bin/testfiles/GenTest210.jmx >>>>>> jmeter/trunk/bin/testfiles/GenTest27.jmx >>>>>> jmeter/trunk/bin/testfiles/GuiTest.jmx >>>>>> jmeter/trunk/bin/testfiles/GuiTest231.jmx >>>>>> jmeter/trunk/bin/testfiles/HeaderManagerTestPlan.jmx >>>>>> jmeter/trunk/bin/testfiles/InterleaveTestPlan.jmx >>>>>> jmeter/trunk/bin/testfiles/InterleaveTestPlan2.jmx >>>>>> jmeter/trunk/bin/testfiles/LoopTestPlan.jmx >>>>>> jme
Re: svn commit: r1649629 - in /jmeter/trunk: bin/ bin/testfiles/ src/components/org/apache/jmeter/visualizers/ src/core/org/apache/jmeter/control/ src/core/org/apache/jmeter/resources/ src/core/org/ap
Done Andrey Pokhilko On 01/06/2015 04:16 PM, Andrey Pokhilko wrote: > Thanks for pointing to the right place, I'll work on it right now. > > Andrey Pokhilko > > On 01/06/2015 04:10 PM, sebb wrote: >> Ah - that class is different; the data is saved in >> SampleSaveConfigurationConverter >> But the principle is the same; don't save new properties unnecessarily. >> >> There is a comment at the beginning of the SampleSaveConfiguration >> class which details all the changes that have to be made when adding a >> new field, this includes: >> >> * - update SampleSaveConfigurationConverter to add new fields to >> marshall() and shouldSerialiseMember() >> >> The sample config is used in lots of places so changes affect lots of >> classes. >> >> Maybe one could do something clever with annotations so that some of >> this config was no longer necessary, >> But that will be quite a lot of work for something that rarely changes. >> >> In the meantime, the unit tests hopefully catch any errors. >> >> On 6 January 2015 at 12:56, Andrey Pokhilko wrote: >>> I'm sorry, but I don't understand how this relates to the >>> SampleSaveConfiguration, which generates this piece of JMX... I have >>> correct defaults specified for connect times, it is false both in the >>> code and in the jmeter.properties. I used no string "magic" strings in >>> my code, did everything just like it is done for latency. I think this >>> change in JMXses is unavoidable, since JMeter writes into JMX all sample >>> save flags, including those with default values. I see the sense of this >>> behavior to make JMXses consistently portable between different JMeter >>> installation. >>> >>> Am I wrong? >>> >>> Andrey Pokhilko >>> >>> On 01/06/2015 03:45 PM, sebb wrote: >>>> On 6 January 2015 at 08:25, Andrey Pokhilko wrote: >>>>> About modifying JMXses: >>>>> >>>>> As far as I understand how JMeter works, it applies the default (which >>>>> is "false") when no configuration property provided. >>>> Yes, assuming that the default is correctly defined. >>>> >>>>> But then when it >>>>> saves the JMX, it writes all the properties, including those with >>>>> default values. >>>> That depends on how the code writes the values. >>>> There is a property setter that takes a default value; if the value >>>> matches the default, it removes the property instead of writing it. >>>> >>>> This is done to avoid cluttering up the JMX files, and to assist with >>>> backwards compatibiity. >>>> >>>> See for example >>>> >>>> AuthManager.setClearEachIteration(boolean clear) >>>> >>>> Note that the same constant (DEFAULT_CLEAR_VALUE) is used for both get and >>>> set. >>>> It's vital that the same value is used for get and set - and the value >>>> must never change. >>>> >>>>> I did change to JMXses since somewhere in the tests there is a check >>>>> that JMX must stay unchanged upon open and save. If I'm wrong and there >>>>> is some other way to make those tests passing, please tell it to me and >>>>> I'll roll back the undesired changes. >>>>> >>>>> Andrey Pokhilko >>>>> >>>>> On 01/06/2015 05:48 AM, sebb wrote: >>>>>> On 5 January 2015 at 19:49, wrote: >>>>>>> Author: undera >>>>>>> Date: Mon Jan 5 19:49:06 2015 >>>>>>> New Revision: 1649629 >>>>>>> >>>>>>> URL: http://svn.apache.org/r1649629 >>>>>>> Log: >>>>>>> 48799 - Add connect time to output metrics >>>>>>> >>>>>>> Added: >>>>>>> >>>>>>> jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/MeasuringConnectionManager.java >>>>>>> Modified: >>>>>>> jmeter/trunk/bin/jmeter.properties >>>>>>> jmeter/trunk/bin/testfiles/AssertionTestPlan.jmx >>>>>>> jmeter/trunk/bin/testfiles/AuthManagerTestPlan.jmx >>>>>>> jmeter/trunk/bin/testfiles/GenTest210.jmx >>>>>>> jmeter/trunk/bin/testfiles/GenTest27.jmx >>>>>>>
Re: Release 2.13 ?
+1 I see no reasons not to do it. -- Andrey Pokhilko On 01/24/2015 06:30 PM, Philippe Mouawad wrote: > Hello, > It appears 2.12 suffers from an OOM in GUI mode : > >- https://issues.apache.org/bugzilla/show_bug.cgi?id=57440 > > This OOM seems to be due to RSyntaxTexarea bug: > >- https://github.com/bobbylight/RSyntaxTextArea/issues/99 > > It appeared after the rework of LoggerPanel#processEvent way of appending > event. > > Now that it receivs log event even when closed this OOM has more chances to > appear. > > I reverted to 2.11 way of appending events to fix OOM waiting for answer > from rsyntaxtarea project. > > There was also a bug in the way limit=0 was set that had no effect, I fixed > it as part of the bug. > > There is a workaround which is to set: > > - jmeter.loggerpanel.enable_when_closed=false > > But if user opens panel, OOM will occur if lot of logs occur (specially if > stacktraces). > > If we release, it cannot be named 2.12.1 because we have some "big?" > features in this versions so it would not be a minor one. > > Regarding the frequency and impact of this bug, in our company I had 2 > reports in 5 days of this OOM so I think it is not to be ignored. > > > Thoughts ? >
Re: Release 2.13 ?
Ah, I forgot one thing that I wanted to commit in 2.13: remote retry feature. It is needed when you run distributed test with tens of slaves and some of them fail because of network glitches or other reasons. May I do that before starting release process for 2.13? As usual, I'll show it as GitHub PR first for easy review, and there will be bugzilla with explanation. -- Andrey Pokhilko On 01/25/2015 05:11 PM, Milamber wrote: > Hello, > > +1 for me to release a 2.13 version. (I can act as RM) > +1 too for a new property to disable RSTA on Logger panel before the new > release. > > Milamber > > On 25/01/2015 00:20, sebb wrote: >> OK to name it 2.13 and to release it. >> >> Given that there have been some issues with using RSyntaxTextArea, I >> wonder whether what it provides for the LoggerPanel is worth the >> potential disadvantages. >> >> I have just had a look at the display, and I'm not sure it provides >> much apart from line numbering.. >> >> I can see that RSTA is beneficial for the GUI fields, but these are >> generally quite small, whereas the logging panel can grow without >> bound. >> >> At the moment the user has no choice as to whether to use it. >> >> Rather than release 2.13 and hope that the issues have been solved, I >> think it would be better to at least provide the option to disable >> RSTA for the LoggerPanel. This could be done with a property. >> >> At least then there would be a work round if RSTA proves problematic. >> >> On 24 January 2015 at 19:56, Felix Schumacher >> wrote: >>> Am 24.01.2015 um 16:30 schrieb Philippe Mouawad: >>> >>>> Hello, >>>> It appears 2.12 suffers from an OOM in GUI mode : >>>> >>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57440 >>>> >>>> This OOM seems to be due to RSyntaxTexarea bug: >>>> >>>> - https://github.com/bobbylight/RSyntaxTextArea/issues/99 >>>> >>>> It appeared after the rework of LoggerPanel#processEvent way of appending >>>> event. >>>> >>>> Now that it receivs log event even when closed this OOM has more chances >>>> to >>>> appear. >>>> >>>> I reverted to 2.11 way of appending events to fix OOM waiting for answer >>>> from rsyntaxtarea project. >>>> >>>> There was also a bug in the way limit=0 was set that had no effect, I >>>> fixed >>>> it as part of the bug. >>>> >>>> There is a workaround which is to set: >>>> >>>> - jmeter.loggerpanel.enable_when_closed=false >>>> >>>> But if user opens panel, OOM will occur if lot of logs occur (specially if >>>> stacktraces). >>>> >>>> If we release, it cannot be named 2.12.1 because we have some "big?" >>>> features in this versions so it would not be a minor one. >>>> >>>> Regarding the frequency and impact of this bug, in our company I had 2 >>>> reports in 5 days of this OOM so I think it is not to be ignored. >>>> >>>> >>>> Thoughts ? >>>> >>> +1 to release 2.13. I don't think a we should go for 2.x.y. >>> >>> Regards >>> Felix
Remote retry behavior PR
Hello, I'd like to commit the change to have retries with remote testing and ability to ignore failed nodes and proceed. This will allow to have large-scale tests still running in non-ideal infrastructure of clouds (eg AWS), where some VMs might fail to fire up. The defaults not use this feature, it is available through property settings. PR for review: https://github.com/apache/jmeter/pull/13 Bugzilla: https://issues.apache.org/bugzilla/show_bug.cgi?id=57500 Please review it. I'll add documentation changes once we'll discuss and fix the initial issues of the code. -- Andrey Pokhilko
Re: Remote retry behavior PR
HI Philippe, Thanks for reviewing, I addressed all your suggestions: - properties prefix is "client", just like other properties of similar purpose - changed comments inside jmeter.properties file - changed all 'host' in code into 'address' Andrey Pokhilko On 01/27/2015 01:20 AM, Philippe Mouawad wrote: > Hi, > I reviewed it, looks nice. > > Some notes: > >- rmi prefix should maybe replaced by something more "functional" like >distributed_runner >- properties in jmeter.properties should be commented >- host in code is in fact hostAndPort no ? Maybe rename it > > That's it for now. > > Regards > > Philippe > > On Mon, Jan 26, 2015 at 4:35 PM, Andrey Pokhilko wrote: > >> Hello, >> >> I'd like to commit the change to have retries with remote testing and >> ability to ignore failed nodes and proceed. This will allow to have >> large-scale tests still running in non-ideal infrastructure of clouds >> (eg AWS), where some VMs might fail to fire up. The defaults not use >> this feature, it is available through property settings. >> >> PR for review: https://github.com/apache/jmeter/pull/13 >> Bugzilla: https://issues.apache.org/bugzilla/show_bug.cgi?id=57500 >> >> Please review it. I'll add documentation changes once we'll discuss and >> fix the initial issues of the code. >> >> -- >> Andrey Pokhilko >> >> >
Re: Remote retry behavior PR
Well, I did my best to test it functionally, fixed found issues. If there is no objections in 24 hours, I will commit it. Andrey Pokhilko On 01/26/2015 06:35 PM, Andrey Pokhilko wrote: > Hello, > > I'd like to commit the change to have retries with remote testing and > ability to ignore failed nodes and proceed. This will allow to have > large-scale tests still running in non-ideal infrastructure of clouds > (eg AWS), where some VMs might fail to fire up. The defaults not use > this feature, it is available through property settings. > > PR for review: https://github.com/apache/jmeter/pull/13 > Bugzilla: https://issues.apache.org/bugzilla/show_bug.cgi?id=57500 > > Please review it. I'll add documentation changes once we'll discuss and > fix the initial issues of the code. >
Re: Release 2.13 ?
I have committed remote retry feature into trunk. Now I have no more reasons to delay 2.13 release. Instead, I support it to be out as soon as it is possible. Andrey Pokhilko On 01/25/2015 07:02 PM, Philippe Mouawad wrote: > +1 for inclusion (will reconsider once PR is available :-) ) > Regards > > On Sunday, January 25, 2015, Andrey Pokhilko wrote: > >> Ah, I forgot one thing that I wanted to commit in 2.13: remote retry >> feature. >> >> It is needed when you run distributed test with tens of slaves and some >> of them fail because of network glitches or other reasons. >> >> May I do that before starting release process for 2.13? As usual, I'll >> show it as GitHub PR first for easy review, and there will be bugzilla >> with explanation. >> >> -- >> Andrey Pokhilko >> >> On 01/25/2015 05:11 PM, Milamber wrote: >>> Hello, >>> >>> +1 for me to release a 2.13 version. (I can act as RM) >>> +1 too for a new property to disable RSTA on Logger panel before the new >>> release. >>> >>> Milamber >>> >>> On 25/01/2015 00:20, sebb wrote: >>>> OK to name it 2.13 and to release it. >>>> >>>> Given that there have been some issues with using RSyntaxTextArea, I >>>> wonder whether what it provides for the LoggerPanel is worth the >>>> potential disadvantages. >>>> >>>> I have just had a look at the display, and I'm not sure it provides >>>> much apart from line numbering.. >>>> >>>> I can see that RSTA is beneficial for the GUI fields, but these are >>>> generally quite small, whereas the logging panel can grow without >>>> bound. >>>> >>>> At the moment the user has no choice as to whether to use it. >>>> >>>> Rather than release 2.13 and hope that the issues have been solved, I >>>> think it would be better to at least provide the option to disable >>>> RSTA for the LoggerPanel. This could be done with a property. >>>> >>>> At least then there would be a work round if RSTA proves problematic. >>>> >>>> On 24 January 2015 at 19:56, Felix Schumacher >>>> > wrote: >>>>> Am 24.01.2015 um 16:30 schrieb Philippe Mouawad: >>>>> >>>>>> Hello, >>>>>> It appears 2.12 suffers from an OOM in GUI mode : >>>>>> >>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57440 >>>>>> >>>>>> This OOM seems to be due to RSyntaxTexarea bug: >>>>>> >>>>>> - https://github.com/bobbylight/RSyntaxTextArea/issues/99 >>>>>> >>>>>> It appeared after the rework of LoggerPanel#processEvent way of >> appending >>>>>> event. >>>>>> >>>>>> Now that it receivs log event even when closed this OOM has more >> chances >>>>>> to >>>>>> appear. >>>>>> >>>>>> I reverted to 2.11 way of appending events to fix OOM waiting for >> answer >>>>>> from rsyntaxtarea project. >>>>>> >>>>>> There was also a bug in the way limit=0 was set that had no effect, I >>>>>> fixed >>>>>> it as part of the bug. >>>>>> >>>>>> There is a workaround which is to set: >>>>>> >>>>>> - jmeter.loggerpanel.enable_when_closed=false >>>>>> >>>>>> But if user opens panel, OOM will occur if lot of logs occur >> (specially if >>>>>> stacktraces). >>>>>> >>>>>> If we release, it cannot be named 2.12.1 because we have some "big?" >>>>>> features in this versions so it would not be a minor one. >>>>>> >>>>>> Regarding the frequency and impact of this bug, in our company I had 2 >>>>>> reports in 5 days of this OOM so I think it is not to be ignored. >>>>>> >>>>>> >>>>>> Thoughts ? >>>>>> >>>>> +1 to release 2.13. I don't think a we should go for 2.x.y. >>>>> >>>>> Regards >>>>> Felix >>
Possible NPE in FileServer
Hi, I just met the situation, when this line of code returns null and causing NPE: https://github.com/apache/jmeter/blob/31c3385075bff2140a4c2b6cdaa2c4a4c1a4a76e/src/core/org/apache/jmeter/services/FileServer.java#L286 fileEntry.headerLine will be non-null only if hasHeader parameter is true. Is this what expected? -- Andrey Pokhilko
Re: Possible NPE in FileServer
It occurs when you have CSV Data Set and specified file was not found. Then in the log there is one exception about "file not found" and many of NPE, I guess for every iteration. Andrey Pokhilko On 02/08/2015 04:36 AM, sebb wrote: > On 6 February 2015 at 22:48, Andrey Pokhilko wrote: >> Hi, >> >> I just met the situation, when this line of code returns null and >> causing NPE: >> https://github.com/apache/jmeter/blob/31c3385075bff2140a4c2b6cdaa2c4a4c1a4a76e/src/core/org/apache/jmeter/services/FileServer.java#L286 >> >> fileEntry.headerLine will be non-null only if hasHeader parameter is >> true. Is this what expected? > The Javadoc says the method can return null. > > Where does the NPE occur? > >> -- >> Andrey Pokhilko >>
Re: Possible NPE in FileServer
The log piece looks like this: 2015/02/08 18:26:38 INFO - jmeter.services.FileServer: Stored: /tmp/test.csv 2015/02/08 18:26:38 ERROR - jmeter.threads.JMeterThread: Test failed! java.lang.IllegalArgumentException: Could not read file header line at org.apache.jmeter.services.FileServer.reserveFile(FileServer.java:282) at org.apache.jmeter.config.CSVDataSet.iterationStart(CSVDataSet.java:178) at org.apache.jmeter.control.GenericController.fireIterationStart(GenericController.java:408) at org.apache.jmeter.control.GenericController.fireIterEvents(GenericController.java:400) at org.apache.jmeter.control.GenericController.next(GenericController.java:162) at org.apache.jmeter.control.LoopController.next(LoopController.java:123) at org.apache.jmeter.threads.AbstractThreadGroup.next(AbstractThreadGroup.java:88) at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:259) at java.lang.Thread.run(Thread.java:745) Caused by: java.io.FileNotFoundException: /tmp/test.csv (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:146) at org.apache.jmeter.services.FileServer.createBufferedReader(FileServer.java:399) at org.apache.jmeter.services.FileServer.readLine(FileServer.java:325) at org.apache.jmeter.services.FileServer.readLine(FileServer.java:309) at org.apache.jmeter.services.FileServer.reserveFile(FileServer.java:280) ... 8 more 2015/02/08 18:26:38 INFO - jmeter.threads.ThreadGroup: Started thread group number 2 2015/02/08 18:26:38 INFO - jmeter.threads.JMeterThread: Thread finished: Thread Group 1-1 2015/02/08 18:26:38 INFO - jmeter.engine.StandardJMeterEngine: All thread groups have been started 2015/02/08 18:26:38 INFO - jmeter.threads.JMeterThread: Thread started: Thread Group 2-1 2015/02/08 18:26:38 ERROR - jmeter.threads.JMeterThread: Test failed! java.lang.NullPointerException at java.io.StringReader.(StringReader.java:50) at org.apache.jmeter.save.CSVSaveService.csvSplitString(CSVSaveService.java:1155) at org.apache.jmeter.config.CSVDataSet.iterationStart(CSVDataSet.java:180) at org.apache.jmeter.control.GenericController.fireIterationStart(GenericController.java:408) at org.apache.jmeter.control.GenericController.fireIterEvents(GenericController.java:400) at org.apache.jmeter.control.GenericController.next(GenericController.java:162) at org.apache.jmeter.control.LoopController.next(LoopController.java:123) at org.apache.jmeter.threads.AbstractThreadGroup.next(AbstractThreadGroup.java:88) at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:259) at java.lang.Thread.run(Thread.java:745) 2015/02/08 18:26:38 INFO - jmeter.threads.JMeterThread: Thread finished: Thread Group 2-1 Andrey Pokhilko On 02/08/2015 04:16 PM, sebb wrote: > On 8 February 2015 at 17:08, Andrey Pokhilko wrote: >> It occurs when you have CSV Data Set and specified file was not found. >> Then in the log there is one exception about "file not found" and many >> of NPE, I guess for every iteration. > Which class? > What line number? > >> Andrey Pokhilko >> >> On 02/08/2015 04:36 AM, sebb wrote: >>> On 6 February 2015 at 22:48, Andrey Pokhilko wrote: >>>> Hi, >>>> >>>> I just met the situation, when this line of code returns null and >>>> causing NPE: >>>> https://github.com/apache/jmeter/blob/31c3385075bff2140a4c2b6cdaa2c4a4c1a4a76e/src/core/org/apache/jmeter/services/FileServer.java#L286 >>>> >>>> fileEntry.headerLine will be non-null only if hasHeader parameter is >>>> true. Is this what expected? >>> The Javadoc says the method can return null. >>> >>> Where does the NPE occur? >>> >>>> -- >>>> Andrey Pokhilko >>>>
Re: propsFile = File.createTempFile("jmeter-plugins", ".properties");
Hey, What made you think of it like this? :) Did I do any mistake with class name or what? Andrey Pokhilko On 02/28/2015 11:13 PM, Milamber wrote: > Hello, > > jmeter-plugins will merge with JMeter? :) > > in /Jmeter/test/src/org/apache/jmeter/engine/DistributedRunnerTest.java > line 41. > > Milamber
Re: propsFile = File.createTempFile("jmeter-plugins", ".properties");
Ah, now I see. Yes, I had to copy fixture helper from plugins, because I haven't found existing way to do it in jmeter codebase. I have removed the word. Andrey Pokhilko On 03/01/2015 10:12 AM, Milamber wrote: > On 01/03/2015 06:07, Andrey Pokhilko wrote: >> Hey, >> >> What made you think of it like this? :) > Just the string "jmeter-plugins" in the class. > >> Did I do any mistake with class name or what? > anything. all is good > > >> Andrey Pokhilko >> >> On 02/28/2015 11:13 PM, Milamber wrote: >>> Hello, >>> >>> jmeter-plugins will merge with JMeter? :) >>> >>> in /Jmeter/test/src/org/apache/jmeter/engine/DistributedRunnerTest.java >>> line 41. >>> >>> Milamber
Re: [VOTE] Release JMeter 2.13 RC1
Hi Milamber, I realized that I've put these two change mentions into wrong place inside changes.xml: Bug 57500 - Introduce retry behavior for remote testing Bug 48799 - Add connect time to output metrics I did not notice that this section is commented out, so these changes are not mentioned in generated docs. How should I fix it? Commit to RC branch or into the trunk or something else? Andrey Pokhilko On 03/04/2015 02:57 AM, 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 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 > > > >
Re: [VOTE] Release JMeter 2.13 RC1
Hi, I think having too big screenshots on doc pages makes it difficult to read because of horizontal scrollbar, it prevents text from wrapping. I'd recommend limit width of images (just by setting width attribute) and provide hyperlinks to full-size images. Andrey Pokhilko On 03/04/2015 02:57 AM, 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 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 > > > >
Re: [VOTE] Release JMeter 2.13 RC1
The rule I think is common for all pages. Choise of optimum width is a bit arbitrary. From my experience, screenshots should not be more than 800px width, 600px is even better. It is good to take screenshots with window minimized to desired size, to keep the image from scaling and having maximum detail. Andrey Pokhilko On 03/04/2015 11:26 AM, Milamber wrote: > On 04/03/2015 07:13, Andrey Pokhilko wrote: >> Hi, >> >> I think having too big screenshots on doc pages makes it difficult to >> read because of horizontal scrollbar, it prevents text from wrapping. >> I'd recommend limit width of images (just by setting width attribute) >> and provide hyperlinks to full-size images. > > The doc pages is the user manual or another(s) page(s) ? > > What will be the maximum width for the best view? > > >> Andrey Pokhilko >> >> On 03/04/2015 02:57 AM, 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 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 >>> >>> >>> >>>
Re: [VOTE] Release JMeter 2.13 RC1
Well, I don't think it is worth creating the thumbnails. Just having a rule that "any image more than 600px width should have forced width attribute and hyperlink to open its full version" would solve the problem. Browsers will deal with scaling the image. Andrey Pokhilko On 03/04/2015 01:06 PM, Felix Schumacher wrote: > Am 04.03.2015 09:43, schrieb Andrey Pokhilko: >> The rule I think is common for all pages. >> >> Choise of optimum width is a bit arbitrary. From my experience, >> screenshots should not be more than 800px width, 600px is even better. >> It is good to take screenshots with window minimized to desired size, to >> keep the image from scaling and having maximum detail. > > The problem of the big images is not a new one. The patch for > https://bz.apache.org/bugzilla/show_bug.cgi?id=53764 > adresses part of this problem. The big images don't look nice, but > they will > not keep the paragraphs from wrapping. > > I think we should use ant to make thumbnails from all images with > maximum size > of about 800 px width and use those inside the documentation. Those > thumbnails > should then link to the original ones, just like Andrey suggested. > > If a screenshot can be cropped to a size of the thumbnail it would be > even better, > but I suspect that it will not always work. > > I will try to get the thumbnail generation and linking into to the > patch for bug 53764. > > Regards > Felix > >> >> Andrey Pokhilko >> >> On 03/04/2015 11:26 AM, Milamber wrote: >>> On 04/03/2015 07:13, Andrey Pokhilko wrote: >>>> Hi, >>>> >>>> I think having too big screenshots on doc pages makes it difficult to >>>> read because of horizontal scrollbar, it prevents text from wrapping. >>>> I'd recommend limit width of images (just by setting width attribute) >>>> and provide hyperlinks to full-size images. >>> >>> The doc pages is the user manual or another(s) page(s) ? >>> >>> What will be the maximum width for the best view? >>> >>> >>>> Andrey Pokhilko >>>> >>>> On 03/04/2015 02:57 AM, 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 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 >>>>> >>>>> >>>>> >>>>> >
Re: [VOTE] Release JMeter 2.13 RC1
Philippe, I would ask you as more experienced in JMeter releases, to move those changes into appropriate section. I already did my stupid mistakes in changelog, don't want to prevent another RC from releasing because of more :) Andrey Pokhilko On 03/04/2015 04:55 PM, Philippe Mouawad wrote: > Hi, > > -1 as of my vote for this RC1 as: > >- There are issues in bundle (404, images) >- I will commit in few minutes important changes in >GraphiteBackendListener which I would like to be included in this new >version > > > @Andrei, I think your new features deserve a note in New and Noteworthy as > Core improvement as: > 1/ connect time is a nice enhancement that should be highlighted. > 2/ The second one related to distributed testing in Cloud is also > interesting > > > Regards > > On Wed, Mar 4, 2015 at 12:22 PM, Felix Schumacher < > felix.schumac...@internetallee.de> wrote: > >> >> Am 4. März 2015 11:50:55 MEZ, schrieb Andrey Pokhilko : >>> Well, I don't think it is worth creating the thumbnails. Just having a >>> rule that "any image more than 600px width should have forced width >>> attribute and hyperlink to open its full version" would solve the >>> problem. Browsers will deal with scaling the image. >> Thumbnails will serve another purpose too. They can help reducing wasted >> bandwidth. The component page is really long and you will probably not read >> every section or look at every image. >> >> Regards >> Felix >>> Andrey Pokhilko >>> >>> On 03/04/2015 01:06 PM, Felix Schumacher wrote: >>>> Am 04.03.2015 09:43, schrieb Andrey Pokhilko: >>>>> The rule I think is common for all pages. >>>>> >>>>> Choise of optimum width is a bit arbitrary. From my experience, >>>>> screenshots should not be more than 800px width, 600px is even >>> better. >>>>> It is good to take screenshots with window minimized to desired >>> size, to >>>>> keep the image from scaling and having maximum detail. >>>> The problem of the big images is not a new one. The patch for >>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=53764 >>>> adresses part of this problem. The big images don't look nice, but >>>> they will >>>> not keep the paragraphs from wrapping. >>>> >>>> I think we should use ant to make thumbnails from all images with >>>> maximum size >>>> of about 800 px width and use those inside the documentation. Those >>>> thumbnails >>>> should then link to the original ones, just like Andrey suggested. >>>> >>>> If a screenshot can be cropped to a size of the thumbnail it would be >>>> even better, >>>> but I suspect that it will not always work. >>>> >>>> I will try to get the thumbnail generation and linking into to the >>>> patch for bug 53764. >>>> >>>> Regards >>>> Felix >>>> >>>>> Andrey Pokhilko >>>>> >>>>> On 03/04/2015 11:26 AM, Milamber wrote: >>>>>> On 04/03/2015 07:13, Andrey Pokhilko wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I think having too big screenshots on doc pages makes it difficult >>> to >>>>>>> read because of horizontal scrollbar, it prevents text from >>> wrapping. >>>>>>> I'd recommend limit width of images (just by setting width >>> attribute) >>>>>>> and provide hyperlinks to full-size images. >>>>>> The doc pages is the user manual or another(s) page(s) ? >>>>>> >>>>>> What will be the maximum width for the best view? >>>>>> >>>>>> >>>>>>> Andrey Pokhilko >>>>>>> >>>>>>> On 03/04/2015 02:57 AM, 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 Li
Re: [VOTE] Release JMeter 2.13 RC2
+1 Andrey Pokhilko On 03/09/2015 01:00 AM, Milamber wrote: > Hello, > > The second release candidate for JMeter 2.13 (r1665067) has been > prepared, and your votes are solicited. > > This release brings some new features and fixes some bugs. > > On this occasion, we also refreshes the style of JMeter's website. You > can preview by visiting this URL: > http://people.apache.org/~milamber/jmeter-2.13RC2/docs/ > > 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.13RC2/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_RC2/ > > RAT report: > > http://people.apache.org/~milamber/jmeter-2.13RC2/dist/rat-report-jmeter-2.13RC2.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: > > 53dc44a6379b7b4a57976936f3a65e03 *apache-jmeter-2.13.tgz > 3bf9df356588bb12062f9c082f326b9f *apache-jmeter-2.13.zip > d822e0e822ab03769e206f4fa1d6b0f5 *apache-jmeter-2.13_src.tgz > 25900c01368fdcf7b69ffd27a4f155ad *apache-jmeter-2.13_src.zip > > Site Docs are here: > http://people.apache.org/~milamber/jmeter-2.13RC2/docs/ > > Maven staging repo is accessible here: > https://repository.apache.org/content/repositories/orgapachejmeter-1005/org/apache/jmeter/ > > Tag: > http://svn.apache.org/repos/asf/jmeter/tags/v2_13_RC2/ > > 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.13RC2/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 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 > > > >
Re: Comparison of menu font sizes
I will support Sebb here, my experience says that 80% menu font size is the best. (Although I would totally rework the whole project website to be more modern, Bootstrap-based etc). Andrey Pokhilko On 03/17/2015 11:47 PM, sebb wrote: > On 17 March 2015 at 05:55, Felix Schumacher > wrote: >> >> Am 17. März 2015 02:05:45 MEZ, schrieb sebb : >>> On 16 March 2015 at 20:56, Felix Schumacher >>> wrote: >>>> Am 14.03.2015 um 16:35 schrieb sebb: >>>>> I have created some quick test sites to show how the JMeter index >>> page >>>>> looks with various different menu font sizes. >>>>> >>>>> http://jmeter.apache.org/ - original, i.e. 100% >>>>> >>>>> http://people.apache.org/~sebb/jmeter90/ - 90% >>>>> http://people.apache.org/~sebb/jmeter85/ - 85% >>>>> http://people.apache.org/~sebb/jmeter80/ - 80% >>>>> >>>>> >>>>> On my desktop, the 80% size is perhaps starting to get a bit too >>> small >>>>> in comparison with the body text, but 100% is definitely too big. >>>> In my version on p.a.o/~fschumacher/jmeter I already set the menu >>> font to >>>> 90%. >>>> >>>> What do you want with the smaller versions? In my tests with >>> ~1300x800 we >>>> only get a line or two more. That could be achieved with less gaps >>> between >>>> the boxes also. >>> It's partly to improve the balance between the sizes so the menu does >>> not overpower the body text. >>> >>> Also it allows the menu to be narrower leaving more room for body text >>> on smaller screens. >>> >>> On revisiting the 90% examples I still think that is a bit too big >>> compared with the body text. >> In my eyes making the menu text smaller is too small. Maybe I have bad sight. > The point is that at 90% the menu text still looks bigger than the body text. > > If you can read the body text, then you should be able to read the menu text. > > Or maybe the menu text font is not as readable as it should be. > >>>> We don't have to have boxes around the menu items it was just an >>> example. >>>> We could even put the menu as a flat one to the top of the page (can >>> be seen >>>> in my version, if you use a resolution from 600 to 1000 pixel wide. >>> That works well for narrower screens; I'm not sure I like it for wider >>> screens as one cannot see the second level contents at a glance. >> That is why at 1000px (can be adjusted in the media query) the whole menu is >> again shown on the left hand side. >> >>>>> >>>>> >>>>> It's much the same on a Hudl2 tablet (landscape mode). >>>>> >>>>> >>>>> If the menu text size can be reduced, then the layout can be >>> adjusted >>>>> to give more space to the body text. I have not done that in the >>>>> samples. >>>> If you mean to widen the main text, then I like to point out, that >>> wider >>>> text lines tend to be harder to read. That is the reason, why I put a >>>> max-width of 60em. We could probably add a few em's, if you like. But >>> not >>>> too much (in my eyes). >>> It would help if the design decisions were documented in the CSS file >>> as comments. >> I will put in a few comments. >> >> Felix >>>> Regards >>>> Felix >>>> >>>>> [Note: the sites only have the index page; I did not copy the other >>>>> pages.] >>>>
Post-Sampler Timers
Hi, When I try to introduce JMeter to new people, I frequently see them confused with our way to set "think times" before request. Especially those who used to use some other testing tools, where think-time is _after_ request. I personally think that think-time should be made after request, because its duration depends on the results of the request. If you have got long text as a result of your request, you supposed to spend some time reading it. If you have short error message, you supposed to do your next request much faster. The _delay_ time before request still makes sense, because it allows manipulating throughput and synchronize requests. I would like to contribute to JMeter following changes: 1. Add a property for Timers, marking them as "pre-sampler" or "post-sampler" timers 2. Modify thread execution flow to call pre-timers and post-timers accordingly 3. Modify timers UIs where it is reasonable, adding radio button to change timer mode Any thoughts/objections on this? -- Andrey Pokhilko
Re: Post-Sampler Timers
The scoping will stay the same. The implementation will be pretty straightforward and I don't see any complications, just couple of "if" statements. Andrey Pokhilko On 04/15/2015 12:37 PM, UBIK LOAD PACK Support wrote: > Hi, > Very good idea ! > We always use the following strategy to have this feature: > >- Use TestAction with 0 sleep and nest in it the Timer. This way timer >pauses where it is located for the expected time and not SampleResult is >generated. > > So you idea would help as it is a bit harder to maintain. > One note although, how would you handle scoping ? > Would it stay as is ? If yes, won't code be difficult and clumsy ? > > Regards > @ubikloadpack > > On Wed, Apr 15, 2015 at 11:32 AM, Andrey Pokhilko wrote: > >> Hi, >> >> When I try to introduce JMeter to new people, I frequently see them >> confused with our way to set "think times" before request. Especially >> those who used to use some other testing tools, where think-time is >> _after_ request. >> >> I personally think that think-time should be made after request, because >> its duration depends on the results of the request. If you have got long >> text as a result of your request, you supposed to spend some time >> reading it. If you have short error message, you supposed to do your >> next request much faster. The _delay_ time before request still makes >> sense, because it allows manipulating throughput and synchronize requests. >> >> I would like to contribute to JMeter following changes: >> >> 1. Add a property for Timers, marking them as "pre-sampler" or >> "post-sampler" timers >> 2. Modify thread execution flow to call pre-timers and post-timers >> accordingly >> 3. Modify timers UIs where it is reasonable, adding radio button to >> change timer mode >> >> >> Any thoughts/objections on this? >> >> -- >> Andrey Pokhilko >> >> >
Re: Post-Sampler Timers
But the sampler approach (test action is also a sampler) requires to have a pause element after each sampler, which makes test plan too heavy. Timers have scoping, this allows lean test-plan building. That's why I want to have post-sample timers. Andrey Pokhilko On 04/15/2015 03:12 PM, Shmuel Krakower wrote: > Hi, > I do exactly as ubikloadpack mentioned which makes things a lot easier to > look at. > I don't see much value with pre_sleep and post_sleep. > It would have been nice to have a "sleep sampler", which will reduce the > need to create TestAction with Timer in it, as done today. > > Best, > > > > Shmuel Krakower. > www.Beatsoo.org - re-use your jmeter scripts for application performance > monitoring from worldwide locations for free. > > On Wed, Apr 15, 2015 at 12:37 PM, UBIK LOAD PACK Support < > supp...@ubikloadpack.com> wrote: > >> Hi, >> Very good idea ! >> We always use the following strategy to have this feature: >> >>- Use TestAction with 0 sleep and nest in it the Timer. This way timer >>pauses where it is located for the expected time and not SampleResult is >>generated. >> >> So you idea would help as it is a bit harder to maintain. >> One note although, how would you handle scoping ? >> Would it stay as is ? If yes, won't code be difficult and clumsy ? >> >> Regards >> @ubikloadpack >> >> On Wed, Apr 15, 2015 at 11:32 AM, Andrey Pokhilko wrote: >> >>> Hi, >>> >>> When I try to introduce JMeter to new people, I frequently see them >>> confused with our way to set "think times" before request. Especially >>> those who used to use some other testing tools, where think-time is >>> _after_ request. >>> >>> I personally think that think-time should be made after request, because >>> its duration depends on the results of the request. If you have got long >>> text as a result of your request, you supposed to spend some time >>> reading it. If you have short error message, you supposed to do your >>> next request much faster. The _delay_ time before request still makes >>> sense, because it allows manipulating throughput and synchronize >> requests. >>> I would like to contribute to JMeter following changes: >>> >>> 1. Add a property for Timers, marking them as "pre-sampler" or >>> "post-sampler" timers >>> 2. Modify thread execution flow to call pre-timers and post-timers >>> accordingly >>> 3. Modify timers UIs where it is reasonable, adding radio button to >>> change timer mode >>> >>> >>> Any thoughts/objections on this? >>> >>> -- >>> 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> >>
Re: Post-Sampler Timers
There is no reasons not to scale. The behavior will be consistent and timer will be called after post-processor, allowing to set some variable based on sample result and use that variable as think-time delay. Not each of the timers would need to support the toggle (e.g. Constant Throughput and Synchronizing timers will be pre-sample always), and by default any timer would be "pre-sample" to be compatible with previous versions of JMeter scripts. I see no "next" feature that will lead to exponential growth of logic. Timer either pre-sample or post-sample, there is no "mid-sample" timers... Again, for each timer we can decide if it will offer UI to change its role or not. Timer will not affect sampler time unless used within Transaction controller, so this aspect will also be consistent with current behavior. Subtracting sleep time from total transaction time is a question for Transaction Controller and out of scope for this topic. Andrey Pokhilko On 04/15/2015 05:54 PM, Vladimir Sitnikov wrote: >> 3. Modify timers UIs where it is reasonable, adding radio button to > change timer mode > > Will that scale? > Will that be consistent with pre/post processors? > > Each and every timer would have to support "pre-post mode". > Suppose you add another feature, then it will be an exponential number > of combinations in timer UIs. > > Well, there could probably be "post timer" that has access to the > sampler result and adjust sleep duration accordingly (e.g. sleep 1sec > for each 10KiB or response). > > I wonder if "seeping after sampler execution" would break response > time reporting. > Especially, for "transaction controller" that is known to have obscure code. > > Vladimir
Re: Post-Sampler Timers
My comments are below. I wonder why I hear so many objections, why people search for problems instead of opportunities :) Andrey Pokhilko On 04/15/2015 08:04 PM, Vladimir Sitnikov wrote: > Sorry for long posts. > I think we hit just a tip of the iceberg. > > From my experience, the most important problem of timers is "timers > are listeners, not samplers". > Users assume that timers are executed at the place where they appear > in test plan. > It takes a while to realize that timers are inherited to all the > siblings' child samplers. > > Not sure how to fix that though. Some warning should probably be > displayed if a timer has more than one siblings' child (~ "the timer > is probably misplaced"). This is common problem with all JMeter components, like config items and post-processors. I have nothing to do with this. >> There is no reasons not to scale > I mean not "performance-wise" scalability, but code > maintenance/user-experience scalability. > The question is what efforts will consume the approach of making > timers more complex. > >> Synchronizing timers will be pre-sample always > Well, there might be an interesting pattern to synchronize in > post-sample, so questions might appear "why my timer does not support > pre-post mode". No problem, we can add toggle to any timer. >> Timer either pre-sample or post-sample, there is no "mid-sample" > timers. > > I mean orthogonal features as well. > There might be "pre _and_ post" delays at the same time. So you can add two timers, one for pre-sample and one for post-sample. Makes sense to manage these timers separately, since they reflect delays of different nature. > For instance, I want "test reproducibility" feature. > So I could replay the same delays in different test executions (that > is using some pre-defined random seed). > > I have that feature in my own timer and it proved to be very useful to > compare different test executions. > If the same feature appears in public build, there is a question how > "random seed" should be specified for timers in a consistent way. > >> The behavior will be consistent and timer will be called after post-processor > I mean another kind of consistency: > 1) Currently JMeter has separate sets of "pre processors" and "post > processors". You can't pick "mode of processor" in the processor's UI. > 2) For timers you suggest a bit different approach: single timer while > pre-post mode to be configured in the UI. > That is what I call inconsistent user experience. Good point, but I don't think this toggle worth introducing whole new class of components. Pre/Post processors have different objects they manipulate (next sampler and last sample result). Timers have no difference except moment of their call. And duplicating all timers in two groups looks not graceful idea. >> Subtracting sleep time from total transaction time is a >> question for Transaction Controller and out of scope for this topic > It should be in scope. > Did you verify that your approach does not breaks TC logic? > You shouldn't deliver a feature that does not play well with basic > functionality like TC. > Otherwise users would be very confused. > > Vladimir
Re: Create Macro Feature was Post-Sampler Timers
I prefer my PR not to be linked to a concept of Macro, please consider it as a standalone feature. I will try to explain it in dev list message as soon as I'll have spare time. Andrey Pokhilko On 04/20/2015 11:14 PM, Philippe Mouawad wrote: > Hi, > Continuing thread : > http://mail-archives.apache.org/mod_mbox/jmeter-dev/201504.mbox > /%3CCAOGo0VaaBCc0bugsDy8_ohOfeTdOnr4UuYfmVKz1ph7XRVxDSw%40mail.gmail.com%3E > > And following Andrei's PR: > - https://github.com/apache/jmeter/pull/16/files > > What about the following proposal for implementing Hotkey and Macro. > > To make this feature powerful, I think it should be possible to make HotKey > able to create subtrees. > To avoid user manipulating XML, what about enabling user to create the > SubTree through a Beanshell or Groovy script ? > > User would manipulate the Java Model. > > > Maybe this would require us to create a Public API (this subject has been > raised in the past, and maybe it should be adressed as it seems more and > more users want to create their Test through Java API). > > Thoughts ? > > Regards > Philippe >
Component adding hotkeys
Hi, I have colleagues that do heavy JMeter scripting and they come with idea to speed-up the process: have hotkeys to add JMeter components to test plan. Using a hotkey eliminates the need to walk through context menus. As always, Pareto principle states that 80% of a time people use 20% of components, so small set of hotkeys would cover most of situations. I have implemented this feature as Ctrl+0 .. Ctrl+9 hotkey set, with components configurable through properties. Components are added as a child of current position, if possible, or a sibling at the nearest possible scope. I provided my colleagues with patched JMeter and they found the feature working smoothly. Pull request for easy review is here: https://github.com/apache/jmeter/pull/16 , I will create bugzilla for this when needed. As always I ask if other committers support adding this into main JMeter codebase or not. Some notes/questions from my side: * Where is appropriate place in the docs to document this feature? * Are defaults good? What are most used JMeter components? * Is there a way to specify component names in properties instead of classes? * On my Linux Ctrl+9 does not work for some reason... I wonder if somebody knows why. -- Andrey Pokhilko
Re: Define protocol in AccessLogSampler
+1 , good feature Andrey Pokhilko On 05/10/2015 11:35 PM, Philippe Mouawad wrote: > Hi, > Should we merge this PR ? > https://github.com/apache/jmeter/pull/14 > > Regards > Philippe >
HTTP Sampler to use FileServer
Hi, Through my investigations of file uploads in JMeter I found that Post Files do not use FileServer, thus unable to work correctly with paths relative to JMX location. Or maybe I misunderstand the functionality of FileServer. But it states in the class doc: For instance, putting supporting files in the same directory as * the saved test plan file allows users to refer to the file with just it's * name - this FileServer class will find the file without a problem. I see good value in this feature of paths relative to JMX location. Otherwise it is quite painful to operate test plans with resource files. One more thing is that CSV Data Set works fine because it uses FileServer, so we're inconsistent: one component works with files in one way, another works other way... My questions: 1. Is there intentional reason not to use FileServer in HTTP Sampler? 2. Or should I implement usage for it? -- Andrey Pokhilko
HTTPClient4 missing filename for file uploads
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 --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 --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. 2. Should I fix this as demonstrated (if this is a bug)? -- Andrey Pokhilko
Re: HTTP Sampler to use FileServer
Ok, I treat your words as "Yes, implement it". Will do it in a free minute. Andrey Pokhilko On 05/14/2015 07:55 PM, sebb wrote: > On 14 May 2015 at 17:34, Andrey Pokhilko wrote: >> Hi, >> >> Through my investigations of file uploads in JMeter I found that Post >> Files do not use FileServer, thus unable to work correctly with paths >> relative to JMX location. Or maybe I misunderstand the functionality of >> FileServer. But it states in the class doc: >> >> For instance, putting supporting files in the same directory as >> * the saved test plan file allows users to refer to the file with just it's >> * name - this FileServer class will find the file without a problem. >> >> I see good value in this feature of paths relative to JMX location. >> Otherwise it is quite painful to operate test plans with resource files. >> One more thing is that CSV Data Set works fine because it uses >> FileServer, so we're inconsistent: one component works with files in one >> way, another works other way... >> >> My questions: >> >> 1. Is there intentional reason not to use FileServer in HTTP Sampler? > The FileServer class was originally designed for JMeter-specific > files, rather than data files used by samplers. > This is why it was not used for HTTP POST files. > >> 2. Or should I implement usage for it? > Having said that, I suppose it might be useful to use it for such > files, so long as the default behaviour is consistent. > I.e. JMeter must continue to check the current location first. If the > file is not found, then it could check other locations. > > This will be a behavioural change, so should be carefully noted in the docs. > However I don't think it will change the output of a test unless the > new code finds a file where the old code did not, AND it was > intentional not to find the file. > This seems an unlikely scenario to want to test - it is a test of > JMeter rather than of any server. > >> -- >> Andrey Pokhilko >>
Re: HTTPClient4 missing filename for file uploads
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 -7d159c1302d0y0-- Andrey Pokhilko On 05/14/2015 07:57 PM, sebb wrote: > On 14 May 2015 at 17:36, Andrey Pokhilko 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 >> >> >> --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 >> >> >> --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 >> >> >>
Re: HTTPClient4 missing filename for file uploads
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 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 >> >> >> -----7d159c1302d0y0-- >> >> >> Andrey Pokhilko >> >> On 05/14/2015 07:57 PM, sebb wrote: >>> On 14 May 2015 at 17:36, Andrey Pokhilko 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 >>>> >>>> >>>> --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 >>>> >>>> >>>> --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 >>>> >>>> >>>>
Re: HTTPClient4 missing filename for file uploads
Right. Andrey Pokhilko On 05/15/2015 12:55 PM, UBIK LOAD PACK Support wrote: > AFAIU, setting name would not break existing behaviour and fix the > situation right ? > > > On Fri, May 15, 2015 at 11:50 AM, Andrey Pokhilko 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 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 >>>> >>>> >>>> -7d159c1302d0y0-- >>>> >>>> >>>> Andrey Pokhilko >>>> >>>> On 05/14/2015 07:57 PM, sebb wrote: >>>>> On 14 May 2015 at 17:36, Andrey Pokhilko 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 >>>>>> >>>>>> >>>>>> --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 >>>>>> >>>>>> >>>>>> --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 >>>>>> >>>>>> >>>>>> >> >
Re: HTTPClient4 missing filename for file uploads
Very predictable. Andrey Pokhilko On 05/15/2015 02:24 PM, sebb wrote: > Seems to me that this is not a bug in JMeter. > > It may perhaps be a bug in a later version of HttpComponents, but > JMeter is not currently using that version. > Before adding code to JMeter, I think we need to determine whether it > is a bug in HC. > > I don't think we need to fix JMeter to support customised installations. > Since JMeter is open source, the user can apply the fix for themselves. > > Once we have determined whether of not this is a bug in HC, we can > determine whether or not JMeter needs to be updated when it is > upgraded to the latest version of HC. > > > > On 15 May 2015 at 11:04, Andrey Pokhilko wrote: >> Right. >> >> Andrey Pokhilko >> >> On 05/15/2015 12:55 PM, UBIK LOAD PACK Support wrote: >>> AFAIU, setting name would not break existing behaviour and fix the >>> situation right ? >>> >>> >>> On Fri, May 15, 2015 at 11:50 AM, Andrey Pokhilko 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 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 >>>>>> >>>>>> >>>>>> -7d159c1302d0y0-- >>>>>> >>>>>> >>>>>> Andrey Pokhilko >>>>>> >>>>>> On 05/14/2015 07:57 PM, sebb wrote: >>>>>>> On 14 May 2015 at 17:36, Andrey Pokhilko 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 >>>>>>>> >>>>>>>> >>>>>>>> --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 >>>>>>>> >>>>>>>> >>>>>>>> --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 >>>>>>>> >>>>>>>> >>>>>>>>
Re: HTTPClient4 missing filename for file uploads
It is not a bug in HC, they just deprecated that method since 4.3 and broke old behavior for deprecated method. Even if we'll ask them to fix it and restore old behavior, they might say that we're using old version so to get the fix we'll need to upgrade our lib (which was already discussed and not likely to happen soon). Andrey Pokhilko On 05/15/2015 02:25 PM, sebb wrote: > On 15 May 2015 at 12:24, sebb wrote: >> Seems to me that this is not a bug in JMeter. >> >> It may perhaps be a bug in a later version of HttpComponents, but >> JMeter is not currently using that version. >> Before adding code to JMeter, I think we need to determine whether it >> is a bug in HC. >> >> I don't think we need to fix JMeter to support customised installations. >> Since JMeter is open source, the user can apply the fix for themselves. > Or indeed apply the fix to the HC mime code. > >> Once we have determined whether of not this is a bug in HC, we can >> determine whether or not JMeter needs to be updated when it is >> upgraded to the latest version of HC. >> >> >> >> On 15 May 2015 at 11:04, Andrey Pokhilko wrote: >>> Right. >>> >>> Andrey Pokhilko >>> >>> On 05/15/2015 12:55 PM, UBIK LOAD PACK Support wrote: >>>> AFAIU, setting name would not break existing behaviour and fix the >>>> situation right ? >>>> >>>> >>>> On Fri, May 15, 2015 at 11:50 AM, Andrey Pokhilko 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 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 >>>>>>> >>>>>>> >>>>>>> -7d159c1302d0y0-- >>>>>>> >>>>>>> >>>>>>> Andrey Pokhilko >>>>>>> >>>>>>> On 05/14/2015 07:57 PM, sebb wrote: >>>>>>>> On 14 May 2015 at 17:36, Andrey Pokhilko 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> --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 >>>>>>>>> >>>>>>>>> >>>>>>>>> --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 >>>>>>>>> >>>>>>>>> >>>>>>>>>
Re: Ultimate Thread Group
Hi, Maybe just providing couple of links from documentation might help users to find the plugin quickly, without needing to merge complex code (it needs charting classes for preview etc). Andrey Pokhilko On 05/17/2015 09:40 PM, Philippe Mouawad wrote: > Hello, > I find And I think I am not the only one that core jmeter lack from the > feature provided by Ultimate Thread Group which is really nice. > > I would find it great if this one and Stepping Thread Group could be > contributed to core JMeter . > > @Andrei , would this be feasible if a consensus was reached on this ? > > > Thanks > regards > >
Re: Ultimate Thread Group
Since JMeter 2.9 there was no compatibility problems for jp@gc with new releases of JMeter. I don't see the issue and need to make any automated check for that. JMeter releases have very detailed changelog and I have time to test compatibility before JMeter releases. >From my experience, Ultimate Thread Group is rarely needed. Most of the times stock Thread Group with proper settings is enough with one exception of stepping profile. Andrey Pokhilko On 05/19/2015 01:48 PM, Philippe Mouawad wrote: > So I think jmeter-plugins is favored :) as we say "is THE companion". > > Regarding tests , I think JP has improved its tests and we try to be > retro-compatible and document any change for 3rd parties. > sebb is really keen on maintaining this retro compat ;) > > But other automated ideas are welcome. > > Regards > > On Tuesday, May 19, 2015, Philippe Mouawad > wrote: > >> Hi, >> In 2.13 documentatio was updated: >> >> - http://jmeter.apache.org/usermanual/boss.html >> >> Regards >> >> On Tuesday, May 19, 2015, Vladimir Sitnikov > > wrote: >> >>>> We cannot favour one 3rd party plugin over another >>> We can/should favour all. >>> >>> JMeter's front page screams at you with "Highly Extensible core", >>> while it does not justify the claims. >>> It would be much better to put references to the relevant sections of >>> documentations and/or wiki. >>> >>> "Highly extensible" claim with zero useful extensions is of no use. >>> We all know there are good extensions, why don't we list some, so >>> users could easier get feel of the possibilities? >>> >>> Current JMeter wiki does reference lots of external sources: >>> http://wiki.apache.org/jmeter/ >>> >>> Here's what I got right from that http://wiki.apache.org/jmeter: >>> http://wiki.apache.org/jmeter/JMeterMavenPlugin >>> http://wiki.apache.org/jmeter/MysqlCollectorPlugin >>> http://wiki.apache.org/jmeter/MonitoringServers >>> http://wiki.apache.org/jmeter/LogAnalysis >>> etc. >>> >>> In other words, current JMeter's documentation favours some of the >>> plugins over another. >>> >>> >>>> We don't test and cannot recommend particular 3rd party plugins. >>> At least Philippe, Andrey, and myself use "jmeter plugins" on a regular >>> basis. >>> I have no idea if JMeter release procedure includes integration >>> testing with jmeter-plugins, but I believe JMeter should at lest >>> verify that "new JMeter version does not break plugins". >>> Obviously, JMeter cannot test against all the possible plugins, but it >>> is a good idea to test for compatibility with well-known plugins. >>> >>> I think j-p provides much higher level of quality than "mentioned in >>> JMeter's documentation >>> http://wiki.apache.org/jmeter/MysqlCollectorPlugin";, so the reference >>> to j-p in the JMeter's documentation is well deserved. >>> >>> Here's what PostgreSQL does in similar case: >>> 1) The list of "external projects" right in the PostgreSQL core >>> documentation: >>> http://www.postgresql.org/docs/9.4/interactive/external-projects.html >>> "PostgreSQL is a complex software project, and managing the project is >>> difficult. We have found that many enhancements to PostgreSQL can be >>> more efficiently developed separately from the core project." >>> >>> 2) The list with _lots_ of external plugins/articles right in the >>> official wiki: >>> https://wiki.postgresql.org/wiki/Converting_from_other_Databases_to_PostgreSQL >>> , https://wiki.postgresql.org/wiki/Performance_Optimization >>> >>> Vladimir >>> >> >> -- >> Cordialement. >> Philippe Mouawad. >> >> >> >>
Re: JMeter compoents API: setProperty vs setXXX
Hi, >From my experience there is no common rules among components, part of them provide public constants, part of them provide setter methods. You have to have API docs at your hand and use each component according to its interface. Andrey Pokhilko On 05/22/2015 04:07 PM, Vladimir Sitnikov wrote: > Hi, > > I'm trying to understand what is the recommended way to create > components via java API. > > Initially I thought properties should be set via setProperty while > names are provided via constants like > org.apache.jmeter.testelement.TestPlan#FUNCTIONAL_MODE. > > However CounterConfig breaks this nice picture: > org.apache.jmeter.modifiers.CounterConfig#START and other properties > are private. > > BeanShellPreProcessor goes even further and it completely ignores > "setProperties". > > > Can you please advise me what is the suggested way to create test > elements via API? >
Re: Linking to 3rd party products
IMO: 1. Let's completely remove all the mentions of particular plugins from the "boss.html". I don't think it's the most efficient place to let people know about extensions to JMeter. And now it definitely violates ASF policy. 2. Let's add vendor-neutral call to search for extensions in the most visible places, like downloads page, main page, anywhere else. This will comply with ASF policy and at the same time will tell wide masses that they can add a lot of value to their JMeter by using 3rd party plugins. Something like "You can add a lot of additional features to your JMeter by installing various custom plugins. Search for them in the internet!" might work. Andrey Pokhilko On 05/23/2015 11:00 AM, Milamber wrote: > > > On 23/05/2015 08:06, Philippe Mouawad wrote: >> Let me rephrase, >> >> What exact sentence of policy are you refering to as potentially showing >> page (boss) does not comply with Apache policy ? > > For example this sentence: > > "Listings must be sorted equitably and consistently. PMCs are free to > set any sort of policy in terms of listing order, but should be > consistent about applying it to not show favoritisim." > > And the "THE" for JMeter-plugins (the THE marks some favoritism) > > > > Also, the listing on boss page isn't a full list of software around > JMeter, so this list marks some favoritism. > > > I agree with sebb, the best place for a list of software around JMeter > is the Wiki. > Perhaps, in boss page, change the "18.5 How can I enhance JMeter ?" > section to replace the current list with a link towards the Wiki > JMeterPlugins page only. > > Milamber > > >> >> Thanks >> >> On Saturday, May 23, 2015, Philippe Mouawad >> wrote: >> >>> Hello, >>> What exact sentence of policy are you refering to as potentially not >>> complying with Apache policy ? >>> >>> Thanks >>> Regards >>> >>> On Saturday, May 23, 2015, sebb >> > wrote: >>> >>>> The policy on linking to 3rd party products is here: >>>> >>>> https://www.apache.org/foundation/marks/linking#productsupport >>>> >>>> I think the current references in the core docs [1] don't fully follow >>>> the guidelines. >>>> >>>> In particular, there is a strong suggestion that "JMeter-Plugins" is >>>> favoured by the JMeter project. >>>> That is not allowed by the policy; we can only make factual and >>>> impartial statements about 3rd party resources. >>>> >>>> The Wiki has long been used to provide links to 3rd party services and >>>> software. >>>> Most of these are not listed on the main website [1]. >>>> >>>> So at present I think the core docs [1] are not impartial and are also >>>> not complete. >>>> These faiings need to be fixed. >>>> >>>> The Wiki seems to me to be the best place to maintain the links. >>>> It's currently simpler and quicker to update, and allows 3rd parties >>>> to contribute easily. >>>> >>>> [1] http://jmeter.apache.org/usermanual/boss.html >>>> >>> >>> -- >>> Cordialement. >>> Philippe Mouawad. >>> >>> >>> >>> >
Re: HTTPClient4 missing filename for file uploads
Sebastian, I want to re-raise this topic again. The change is small and harmless, does not increase complexity, does not break any compatibilities. But it fixes compatibility with newer HT versions. Why you don't want to help people with custom plugins or libraries if it has no disadvantages? If your "I think..." is soft enough, may I commit this change, please? Andrey Pokhilko On 05/15/2015 03:06 PM, sebb wrote: > On 15 May 2015 at 12:41, Andrey Pokhilko wrote: >> It is not a bug in HC, they just deprecated that method since 4.3 and >> broke old behavior for deprecated method. > That's unfortunate, especially if it was not essential. > >> Even if we'll ask them to fix >> it and restore old behavior, they might say that we're using old version >> so to get the fix we'll need to upgrade our lib (which was already >> discussed and not likely to happen soon). > It might still be worth raising on the HC mailing list, as there are > likely other apps that are affected. > At the very least, the release notes ought to mention this behavioural change. > > I think it is out of scope for JMeter to fix its code to support > non-standard versions of jars. > > This thread has documented at least two work-rounds that end-users can apply. > >> Andrey Pokhilko >> >> On 05/15/2015 02:25 PM, sebb wrote: >>> On 15 May 2015 at 12:24, sebb wrote: >>>> Seems to me that this is not a bug in JMeter. >>>> >>>> It may perhaps be a bug in a later version of HttpComponents, but >>>> JMeter is not currently using that version. >>>> Before adding code to JMeter, I think we need to determine whether it >>>> is a bug in HC. >>>> >>>> I don't think we need to fix JMeter to support customised installations. >>>> Since JMeter is open source, the user can apply the fix for themselves. >>> Or indeed apply the fix to the HC mime code. >>> >>>> Once we have determined whether of not this is a bug in HC, we can >>>> determine whether or not JMeter needs to be updated when it is >>>> upgraded to the latest version of HC. >>>> >>>> >>>> >>>> On 15 May 2015 at 11:04, Andrey Pokhilko wrote: >>>>> Right. >>>>> >>>>> Andrey Pokhilko >>>>> >>>>> On 05/15/2015 12:55 PM, UBIK LOAD PACK Support wrote: >>>>>> AFAIU, setting name would not break existing behaviour and fix the >>>>>> situation right ? >>>>>> >>>>>> >>>>>> On Fri, May 15, 2015 at 11:50 AM, Andrey Pokhilko 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 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" * >>>>>>>>>
Re: HTTPClient4 missing filename for file uploads
I did not raise bug in HttpClient project as it is not a bug, they just deprecated this constructor. I'd be happy to not require updated HttpClient, but latest versions of Selenium require it. And I can't use old Selenium libs because of support for latest browsers. Andrey Pokhilko On 05/26/2015 09:29 PM, Philippe Mouawad wrote: > No objection for me. > Although having 3rd party plugins use different versions of dependencies > used by core exposes to issues and as such should be avoided. > > In this particular case , if we upgrade we should anyway update the code to > use the updated method. > > Did you raise a bug on HttpClient project ? > > Thanks > > > On Tuesday, May 26, 2015, Andrey Pokhilko wrote: > >> Sebastian, >> >> I want to re-raise this topic again. >> >> The change is small and harmless, does not increase complexity, does not >> break any compatibilities. But it fixes compatibility with newer HT >> versions. >> >> Why you don't want to help people with custom plugins or libraries if it >> has no disadvantages? >> If your "I think..." is soft enough, may I commit this change, please? >> >> Andrey Pokhilko >> >> On 05/15/2015 03:06 PM, sebb wrote: >>> On 15 May 2015 at 12:41, Andrey Pokhilko > >> wrote: >>>> It is not a bug in HC, they just deprecated that method since 4.3 and >>>> broke old behavior for deprecated method. >>> That's unfortunate, especially if it was not essential. >>> >>>> Even if we'll ask them to fix >>>> it and restore old behavior, they might say that we're using old version >>>> so to get the fix we'll need to upgrade our lib (which was already >>>> discussed and not likely to happen soon). >>> It might still be worth raising on the HC mailing list, as there are >>> likely other apps that are affected. >>> At the very least, the release notes ought to mention this behavioural >> change. >>> I think it is out of scope for JMeter to fix its code to support >>> non-standard versions of jars. >>> >>> This thread has documented at least two work-rounds that end-users can >> apply. >>>> Andrey Pokhilko >>>> >>>> On 05/15/2015 02:25 PM, sebb wrote: >>>>> On 15 May 2015 at 12:24, sebb > wrote: >>>>>> Seems to me that this is not a bug in JMeter. >>>>>> >>>>>> It may perhaps be a bug in a later version of HttpComponents, but >>>>>> JMeter is not currently using that version. >>>>>> Before adding code to JMeter, I think we need to determine whether it >>>>>> is a bug in HC. >>>>>> >>>>>> I don't think we need to fix JMeter to support customised >> installations. >>>>>> Since JMeter is open source, the user can apply the fix for >> themselves. >>>>> Or indeed apply the fix to the HC mime code. >>>>> >>>>>> Once we have determined whether of not this is a bug in HC, we can >>>>>> determine whether or not JMeter needs to be updated when it is >>>>>> upgraded to the latest version of HC. >>>>>> >>>>>> >>>>>> >>>>>> On 15 May 2015 at 11:04, Andrey Pokhilko > >> wrote: >>>>>>> Right. >>>>>>> >>>>>>> Andrey Pokhilko >>>>>>> >>>>>>> On 05/15/2015 12:55 PM, UBIK LOAD PACK Support wrote: >>>>>>>> AFAIU, setting name would not break existing behaviour and fix the >>>>>>>> situation right ? >>>>>>>> >>>>>>>> >>>>>>>> On Fri, May 15, 2015 at 11:50 AM, Andrey Pokhilko > > 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 wil
Re: HTTPClient4 missing filename for file uploads
I contacted HTTP Components team and regression was fixed in branch 4.5.x Andrey Pokhilko On 05/27/2015 06:13 AM, Philippe Mouawad wrote: > I think for faster fix: > - it should be fixed in jmeter as anyway we use a deprecrated method > (probably removed in future version of httpmime). We can see it as a > workaround but this approach has been taken in the past for httpclient bugs. > > - report a bug to httpmime > > Otherwise we slow down the fix for our project , seen from customer > perspective of jmeter , the issue is in jmeter. > That's the important thing for me. > > If workaround was big or ugly I would not do it, but here it's clean(use up > to date method) and fast and Andrei analyzed it already. > > > > > > Regards > > On Wednesday, May 27, 2015, sebb wrote: > >> On 26 May 2015 at 20:17, Philippe Mouawad > > wrote: >>> Hi, >>> I think it would be over engineering. >>> I had previous experience with Class Loader isolation, it is rather >> complex >>> and sometimes debugging issues is really not easy. >>> >>> I think it is pretty feasible to either follow same dependencies or use >>> something like jarjar to embed other versions. >>> >>> @Andrei, I think it can be considered as a regression in httpmime. >> Agreed. >> >>> Do we agree that if we upgrade httpmime we need to do the change, so >> let's >>> fix it. >> No, I think it should be fixed in httpmime. >> Or at least that approach should be tried first, because the cause is >> httpmime and fixing it there will fix it for everyone. >> >>> Regards >>> >>> >>> >>> On Tue, May 26, 2015 at 8:49 PM, Vladimir Sitnikov < >>> sitnikov.vladi...@gmail.com > wrote: >>> >>>> Can we isolate "in-core" classloaders from plugin classloaders? >>>> >>>> For instance, allow a plugin use "per-plugin" class loader, so if the >>>> plugin author opts-in for her own classloader, then the plugin sees >>>> just JMeter core files and the jars from the plugin's folder. >>>> >>>> That would eliminate "we can't both keep version and upgrade" issues. >>>> >>>> Vladimir >>>> >>> >>> >>> -- >>> Cordialement. >>> Philippe Mouawad. >
Re: Update to minimum Java 7
+100500 Andrey Pokhilko On 06/01/2015 04:14 PM, sebb wrote: > I think we should require a minimum of Java 7 for the next JMeter release. > (It currently requires 1.6) > > This is because: > - Java 7 supports proper certificate generation for the HTTP recorder. > It will probably allow some code simplification. > - the Javadoc vulnerability CVE-2013-1571 has been fixed since Java 7 > update 25 (June 2013). We could drop the patch. > - any others? > > Of course Java 7 is just about EOL, but I've not yet seen any > compelling reasons to require a minimum of Java 8. If there are such > reasons (other than Java 7 is EOL) please raise them here. > > A very minor consideration is that Javadoc 7 seems to have been fixed > to generate lower-case HTML tags - e.g. rather than . I > assume that will remain the case. So there will be a once-off SVN > difference when older API docs are replaced with new ones.
Re: Component adding hotkeys
Hi, I fixed issue with Ctrl+9, changed defaults slightly, added doc and bugzilla https://bz.apache.org/bugzilla/show_bug.cgi?id=57988 If there are no objections, I will commit this change within 24 hours. Andrey Pokhilko On 04/30/2015 03:49 PM, Philippe Mouawad wrote: > Hi, > I think it's a nice idea, we have same the same feedback. > > For me it should be in core once linux issue is fixed, what about tested > platforms: > - Windows 8? 7 ? > - Linux > - Mac OSX ? which os ? > > Regarding other questions, answers inline. > > Regards > On Monday, April 27, 2015, Andrey Pokhilko > wrote: > >> Hi, >> >> I have colleagues that do heavy JMeter scripting and they come with idea >> to speed-up the process: have hotkeys to add JMeter components to test >> plan. Using a hotkey eliminates the need to walk through context menus. >> As always, Pareto principle states that 80% of a time people use 20% of >> components, so small set of hotkeys would cover most of situations. >> >> I have implemented this feature as Ctrl+0 .. Ctrl+9 hotkey set, with >> components configurable through properties. Components are added as a >> child of current position, if possible, or a sibling at the nearest >> possible scope. I provided my colleagues with patched JMeter and they >> found the feature working smoothly. >> >> Pull request for easy review is here: >> https://github.com/apache/jmeter/pull/16 , I will create bugzilla for >> this when needed. >> >> As always I ask if other committers support adding this into main JMeter >> codebase or not. >> >> Some notes/questions from my side: >> >> * Where is appropriate place in the docs to document this feature? > Somewhere where Search Feature and templates are documented > > > >> * Are defaults good? What are most used JMeter components? > > I would remove or put them at end: > View Results Tree > User Defined Variables > Test Fragment > > as although popular you rarely add more than 2 or 3. > > I would add : > - Css/JQuery extractor > - Jsr223 Post processor > - Test Action for the timer discussion we had > - JSR223 Pre processir > -Debug Sampler > > > >> * Is there a way to specify component names in properties instead of >> classes? > > There are name shortcuts in saveservice.properties > > > >> * On my Linux Ctrl+9 does not work for some reason... I wonder if >> somebody knows why. >> >> -- >> Andrey Pokhilko >> >>
Re: HTTP Sampler to use FileServer
I have prepared the changes, please review it and let me know if it is ok to commit it into svn: https://github.com/apache/jmeter/pull/23/files Andrey Pokhilko On 05/14/2015 07:55 PM, sebb wrote: > On 14 May 2015 at 17:34, Andrey Pokhilko wrote: >> Hi, >> >> Through my investigations of file uploads in JMeter I found that Post >> Files do not use FileServer, thus unable to work correctly with paths >> relative to JMX location. Or maybe I misunderstand the functionality of >> FileServer. But it states in the class doc: >> >> For instance, putting supporting files in the same directory as >> * the saved test plan file allows users to refer to the file with just it's >> * name - this FileServer class will find the file without a problem. >> >> I see good value in this feature of paths relative to JMX location. >> Otherwise it is quite painful to operate test plans with resource files. >> One more thing is that CSV Data Set works fine because it uses >> FileServer, so we're inconsistent: one component works with files in one >> way, another works other way... >> >> My questions: >> >> 1. Is there intentional reason not to use FileServer in HTTP Sampler? > The FileServer class was originally designed for JMeter-specific > files, rather than data files used by samplers. > This is why it was not used for HTTP POST files. > >> 2. Or should I implement usage for it? > Having said that, I suppose it might be useful to use it for such > files, so long as the default behaviour is consistent. > I.e. JMeter must continue to check the current location first. If the > file is not found, then it could check other locations. > > This will be a behavioural change, so should be carefully noted in the docs. > However I don't think it will change the output of a test unless the > new code finds a file where the old code did not, AND it was > intentional not to find the file. > This seems an unlikely scenario to want to test - it is a test of > JMeter rather than of any server. > >> -- >> Andrey Pokhilko >>
Re: Component adding hotkeys
Not having a Thread Group in hotkeys disbles "fluent start", when you just opened JMeter and immediately start building Test Plan with hotkeys. My UX feeling says that we should still have it. Ctrl+0 is the most rightsided key, that reflects rarity of usage. Having Debug Sampler and View Results Tree also required UX-wise, because you need them not frequently, but always urgently when you want to troubleshoot your script and instant usage will gratify hurrying user. Finally, user can always set up his preferred keys to reflect his style of usage. Andrey Pokhilko On 06/03/2015 03:34 AM, sebb wrote: > On 2 June 2015 at 20:42, Philippe Mouawad wrote: >> Hi, >> Thanks for taking into account some notes. >> >> 1/ I would put these defaults: >> gui.quick_0=ThreadGroupGui > Although that is needed for every test, often only one is needed. > It seems wasteful to use up a quick key for this. > > Maybe a ThreadGroup should be automatically added to a new test plan. > Or a template added that includes a ThreadGroup (possibly plus a > Listener at plan level), and make that the default. > >> gui.quick_1=HttpTestSampleGui >> gui.quick_2=RegexExtractorGui >> gui.quick_3=HtmlExtractorGui >> gui.quick_4=AssertionGui >> gui.quick_5=ConstantTimerGui >> gui.quick_6=GaussianRandomTimerGui >> gui.quick_7=TestActionGui >> gui.quick_8=JSR223PostProcessor >> gui.quick_9=JSR223PreProcessor >> >> >> As for me DebugSampler is not added very frequently, same for >> ViewResultsTree. > I tend to use ViewResultsTree a lot, but again usually only one is needed. > >> 2/ Is it a good thing to try to add element somewhere in the tree >> hierarchy ? I would fail if current node does not allow it. >> >> Regards >> >> On Tue, Jun 2, 2015 at 12:46 PM, Andrey Pokhilko wrote: >> >>> Hi, >>> >>> I fixed issue with Ctrl+9, changed defaults slightly, added doc and >>> bugzilla https://bz.apache.org/bugzilla/show_bug.cgi?id=57988 >>> >>> If there are no objections, I will commit this change within 24 hours. >>> >>> Andrey Pokhilko >>> >>> On 04/30/2015 03:49 PM, Philippe Mouawad wrote: >>>> Hi, >>>> I think it's a nice idea, we have same the same feedback. >>>> >>>> For me it should be in core once linux issue is fixed, what about tested >>>> platforms: >>>> - Windows 8? 7 ? >>>> - Linux >>>> - Mac OSX ? which os ? >>>> >>>> Regarding other questions, answers inline. >>>> >>>> Regards >>>> On Monday, April 27, 2015, Andrey Pokhilko >>> > wrote: >>>> >>>>> Hi, >>>>> >>>>> I have colleagues that do heavy JMeter scripting and they come with idea >>>>> to speed-up the process: have hotkeys to add JMeter components to test >>>>> plan. Using a hotkey eliminates the need to walk through context menus. >>>>> As always, Pareto principle states that 80% of a time people use 20% of >>>>> components, so small set of hotkeys would cover most of situations. >>>>> >>>>> I have implemented this feature as Ctrl+0 .. Ctrl+9 hotkey set, with >>>>> components configurable through properties. Components are added as a >>>>> child of current position, if possible, or a sibling at the nearest >>>>> possible scope. I provided my colleagues with patched JMeter and they >>>>> found the feature working smoothly. >>>>> >>>>> Pull request for easy review is here: >>>>> https://github.com/apache/jmeter/pull/16 , I will create bugzilla for >>>>> this when needed. >>>>> >>>>> As always I ask if other committers support adding this into main JMeter >>>>> codebase or not. >>>>> >>>>> Some notes/questions from my side: >>>>> >>>>> * Where is appropriate place in the docs to document this feature? >>>> Somewhere where Search Feature and templates are documented >>>> >>>> >>>> >>>>> * Are defaults good? What are most used JMeter components? >>>> I would remove or put them at end: >>>> View Results Tree >>>> User Defined Variables >>>> Test Fragment >>>> >>>> as although popular you rarely add more than 2 or 3. >>>> >>>> I would add : >>>> - Css/JQuery extractor >>>> - Jsr223 Post processor >>>> - Test Action for the timer discussion we had >>>> - JSR223 Pre processir >>>> -Debug Sampler >>>> >>>> >>>> >>>>> * Is there a way to specify component names in properties instead of >>>>> classes? >>>> There are name shortcuts in saveservice.properties >>>> >>>> >>>> >>>>> * On my Linux Ctrl+9 does not work for some reason... I wonder if >>>>> somebody knows why. >>>>> >>>>> -- >>>>> Andrey Pokhilko >>>>> >>>>> >>> >> >> -- >> Cordialement. >> Philippe Mouawad.
Re: Component adding hotkeys
"Most used" depends on every user. I believe first keys 1-5 will be most used and we already set them fine. I have just committed it into SVN, it is your right to change everything as you see it :) I set it like I see it. Andrey Pokhilko On 06/03/2015 01:19 PM, Philippe Mouawad wrote: > On Wed, Jun 3, 2015 at 8:54 AM, Andrey Pokhilko > wrote: > >> Not having a Thread Group in hotkeys disbles "fluent start", when you >> just opened JMeter and immediately start building Test Plan with >> hotkeys. My UX feeling says that we should still have it. Ctrl+0 is the >> most rightsided key, that reflects rarity of usage. >> > Agreed > >> Having Debug Sampler and View Results Tree also required UX-wise, >> because you need them not frequently, but always urgently when you want >> to troubleshoot your script and instant usage will gratify hurrying user. >> > But not having CSS/JQuery extractor is not a good thing, In our scripting > experience it is among the top 5 elements used. > Although new element it is great for html extraction and makes tests more > maintainable > >> Finally, user can always set up his preferred keys to reflect his style >> of usage. >> > But hotkeys should reflect most used components. > >> Andrey Pokhilko >> >> On 06/03/2015 03:34 AM, sebb wrote: >>> On 2 June 2015 at 20:42, Philippe Mouawad > > wrote: >>>> Hi, >>>> Thanks for taking into account some notes. >>>> >>>> 1/ I would put these defaults: >>>> gui.quick_0=ThreadGroupGui >>> Although that is needed for every test, often only one is needed. >>> It seems wasteful to use up a quick key for this. >>> >>> Maybe a ThreadGroup should be automatically added to a new test plan. >>> Or a template added that includes a ThreadGroup (possibly plus a >>> Listener at plan level), and make that the default. >>> >>>> gui.quick_1=HttpTestSampleGui >>>> gui.quick_2=RegexExtractorGui >>>> gui.quick_3=HtmlExtractorGui >>>> gui.quick_4=AssertionGui >>>> gui.quick_5=ConstantTimerGui >>>> gui.quick_6=GaussianRandomTimerGui >>>> gui.quick_7=TestActionGui >>>> gui.quick_8=JSR223PostProcessor >>>> gui.quick_9=JSR223PreProcessor >>>> >>>> >>>> As for me DebugSampler is not added very frequently, same for >>>> ViewResultsTree. >>> I tend to use ViewResultsTree a lot, but again usually only one is >> needed. >>>> 2/ Is it a good thing to try to add element somewhere in the tree >>>> hierarchy ? I would fail if current node does not allow it. >>>> >>>> Regards >>>> >>>> On Tue, Jun 2, 2015 at 12:46 PM, Andrey Pokhilko > > wrote: >>>>> Hi, >>>>> >>>>> I fixed issue with Ctrl+9, changed defaults slightly, added doc and >>>>> bugzilla https://bz.apache.org/bugzilla/show_bug.cgi?id=57988 >>>>> >>>>> If there are no objections, I will commit this change within 24 hours. >>>>> >>>>> Andrey Pokhilko >>>>> >>>>> On 04/30/2015 03:49 PM, Philippe Mouawad wrote: >>>>>> Hi, >>>>>> I think it's a nice idea, we have same the same feedback. >>>>>> >>>>>> For me it should be in core once linux issue is fixed, what about >> tested >>>>>> platforms: >>>>>> - Windows 8? 7 ? >>>>>> - Linux >>>>>> - Mac OSX ? which os ? >>>>>> >>>>>> Regarding other questions, answers inline. >>>>>> >>>>>> Regards >>>>>> On Monday, April 27, 2015, Andrey Pokhilko > >>>>>> > ');>> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I have colleagues that do heavy JMeter scripting and they come with >> idea >>>>>>> to speed-up the process: have hotkeys to add JMeter components to >> test >>>>>>> plan. Using a hotkey eliminates the need to walk through context >> menus. >>>>>>> As always, Pareto principle states that 80% of a time people use 20% >> of >>>>>>> components, so small set of hotkeys would cover most of situations. >>>>>>> >>>>>>> I have implemented this feature as Ctrl+0 .. Ctrl+9 hotkey set, with >>>>>>> components configura
Re: HTTP Sampler to use FileServer
Thanks for reviewing, committed revision 1683328 Andrey Pokhilko On 06/02/2015 10:52 PM, Philippe Mouawad wrote: > thanks, look ok to me, except for missing javadocs and comments. > > Regards > Philippe > > On Tue, Jun 2, 2015 at 3:20 PM, Andrey Pokhilko wrote: > >> I have prepared the changes, please review it and let me know if it is >> ok to commit it into svn: >> >> https://github.com/apache/jmeter/pull/23/files >> >> Andrey Pokhilko >> >> On 05/14/2015 07:55 PM, sebb wrote: >>> On 14 May 2015 at 17:34, Andrey Pokhilko wrote: >>>> Hi, >>>> >>>> Through my investigations of file uploads in JMeter I found that Post >>>> Files do not use FileServer, thus unable to work correctly with paths >>>> relative to JMX location. Or maybe I misunderstand the functionality of >>>> FileServer. But it states in the class doc: >>>> >>>> For instance, putting supporting files in the same directory as >>>> * the saved test plan file allows users to refer to the file with just >> it's >>>> * name - this FileServer class will find the file without a problem. >>>> >>>> I see good value in this feature of paths relative to JMX location. >>>> Otherwise it is quite painful to operate test plans with resource files. >>>> One more thing is that CSV Data Set works fine because it uses >>>> FileServer, so we're inconsistent: one component works with files in one >>>> way, another works other way... >>>> >>>> My questions: >>>> >>>> 1. Is there intentional reason not to use FileServer in HTTP Sampler? >>> The FileServer class was originally designed for JMeter-specific >>> files, rather than data files used by samplers. >>> This is why it was not used for HTTP POST files. >>> >>>> 2. Or should I implement usage for it? >>> Having said that, I suppose it might be useful to use it for such >>> files, so long as the default behaviour is consistent. >>> I.e. JMeter must continue to check the current location first. If the >>> file is not found, then it could check other locations. >>> >>> This will be a behavioural change, so should be carefully noted in the >> docs. >>> However I don't think it will change the output of a test unless the >>> new code finds a file where the old code did not, AND it was >>> intentional not to find the file. >>> This seems an unlikely scenario to want to test - it is a test of >>> JMeter rather than of any server. >>> >>>> -- >>>> Andrey Pokhilko >>>> >> >
Re: Component adding hotkeys
Sounds strange, as I tested them properly working on colleague's Mac with wireless keyboard and mine KUbuntu Linux 14.04. Andrey Pokhilko On 06/06/2015 10:20 AM, Milamber wrote: > > On Linux (Debian 8 / Gnome 3 / Java7/8) no shortcut works. > Works on Windows 7, but need to do : Ctrl + Shift + 1,2,3, etc (on > French Azerty keyboard the number are available with Shift+X) > > On 05/06/2015 22:06, Philippe Mouawad wrote: >> Hello, >> I started testing this evening and I have an issue, on Mac Book pro >> there >> is no numeric keypad. >> So I had to change the properties to this and it works: >> gui.quick_à=ThreadGroupGui >> gui.quick_&=HttpTestSampleGui >> gui.quick_é=RegexExtractorGui >> gui.quick_"=AssertionGui >> gui.quick_'=ConstantTimerGui >> gui.quick_(=TestActionGui >> gui.quick_§=JSR223PostProcessor >> gui.quick_è=JSR223PreProcessor >> gui.quick_!=DebugSampler >> gui.quick_ç=ViewResultsFullVisualizer >> >> >> Is there a better way on Mac Book Pro ? >> Regards >> >> On Wed, Jun 3, 2015 at 1:17 PM, Andrey Pokhilko wrote: >> >>> "Most used" depends on every user. I believe first keys 1-5 will be >>> most >>> used and we already set them fine. I have just committed it into >>> SVN, it >>> is your right to change everything as you see it :) I set it like I >>> see it. >>> >>> Andrey Pokhilko >>> >>> On 06/03/2015 01:19 PM, Philippe Mouawad wrote: >>>> On Wed, Jun 3, 2015 at 8:54 AM, Andrey Pokhilko >>> > wrote: >>>> >>>>> Not having a Thread Group in hotkeys disbles "fluent start", when you >>>>> just opened JMeter and immediately start building Test Plan with >>>>> hotkeys. My UX feeling says that we should still have it. Ctrl+0 >>>>> is the >>>>> most rightsided key, that reflects rarity of usage. >>>>> >>>> Agreed >>>> >>>>> Having Debug Sampler and View Results Tree also required UX-wise, >>>>> because you need them not frequently, but always urgently when you >>>>> want >>>>> to troubleshoot your script and instant usage will gratify hurrying >>> user. >>>> But not having CSS/JQuery extractor is not a good thing, In our >>>> scripting >>>> experience it is among the top 5 elements used. >>>> Although new element it is great for html extraction and makes >>>> tests more >>>> maintainable >>>> >>>>> Finally, user can always set up his preferred keys to reflect his >>>>> style >>>>> of usage. >>>>> >>>> But hotkeys should reflect most used components. >>>> >>>>> Andrey Pokhilko >>>>> >>>>> On 06/03/2015 03:34 AM, sebb wrote: >>>>>> On 2 June 2015 at 20:42, Philippe Mouawad >>>>>> >>>> > wrote: >>>>>>> Hi, >>>>>>> Thanks for taking into account some notes. >>>>>>> >>>>>>> 1/ I would put these defaults: >>>>>>> gui.quick_0=ThreadGroupGui >>>>>> Although that is needed for every test, often only one is needed. >>>>>> It seems wasteful to use up a quick key for this. >>>>>> >>>>>> Maybe a ThreadGroup should be automatically added to a new test >>>>>> plan. >>>>>> Or a template added that includes a ThreadGroup (possibly plus a >>>>>> Listener at plan level), and make that the default. >>>>>> >>>>>>> gui.quick_1=HttpTestSampleGui >>>>>>> gui.quick_2=RegexExtractorGui >>>>>>> gui.quick_3=HtmlExtractorGui >>>>>>> gui.quick_4=AssertionGui >>>>>>> gui.quick_5=ConstantTimerGui >>>>>>> gui.quick_6=GaussianRandomTimerGui >>>>>>> gui.quick_7=TestActionGui >>>>>>> gui.quick_8=JSR223PostProcessor >>>>>>> gui.quick_9=JSR223PreProcessor >>>>>>> >>>>>>> >>>>>>> As for me DebugSampler is not added very frequently, same for >>>>>>> ViewResultsTree. >>>>>> I tend to use ViewResultsTree a lot, but again usually only one is >>>>> needed. >>>>>>> 2/ Is it a good thing to try to add element somewhere in the tr
Re: Component adding hotkeys
I did not think of this feature to be used with numeric keyboard, I planned it to be used with regular number keys above QWERTY keys. Do you use those keys? Numeric keyboard is indeed not consistent over different stations. Andrey Pokhilko On 06/07/2015 01:20 PM, Milamber wrote: > > In addition, some tests on Windows 7 (VM in my virtualbox on my Linux). > > The shortcut works: 1, 2, 3, 4, 5, not 6, 7, 8, not 9, not 0 > > 2015/06/07 11:12:38 INFO - jmeter.gui.MainFrame: Event gui.quick_1: > HttpTestSampleGui > 2015/06/07 11:12:39 INFO - jmeter.gui.MainFrame: Event gui.quick_2: > RegexExtractorGui > 2015/06/07 11:12:40 INFO - jmeter.gui.MainFrame: Event gui.quick_3: > AssertionGui > 2015/06/07 11:12:41 INFO - jmeter.gui.MainFrame: Event gui.quick_4: > ConstantTimerGui > 2015/06/07 11:12:41 INFO - jmeter.gui.MainFrame: Event gui.quick_5: > TestActionGui > <== missing 6 (I think that is an issue with the Collapse shortcut > (Ctrl+- : on FR Keybord, the minus is the same touch than the number 6 > (shift+- ==> 6) > 2015/06/07 11:12:44 INFO - jmeter.gui.MainFrame: Event gui.quick_7: > JSR223PreProcessor > 2015/06/07 11:12:44 INFO - jmeter.gui.MainFrame: Event gui.quick_8: > DebugSampler > 2015/06/07 11:12:45 INFO - jmeter.gui.MainFrame: Event gui.quick_8: > DebugSampler > 2015/06/07 11:12:46 INFO - jmeter.gui.MainFrame: Event > gui.quick_null: null < 9 > 2015/06/07 11:12:46 WARN - jmeter.gui.MainFrame: No component set > through property: gui.quick_null > 2015/06/07 11:13:00 INFO - jmeter.gui.MainFrame: Event > gui.quick_null: null < 0 > > Note, for this tests, I don't use Ctrl+Shift+number (don't work), I > need enable CapsLocks, and after Ctrl+number... not very friendly. > > > > On 07/06/2015 10:46, Milamber wrote: >> >> >> On 07/06/2015 07:52, Andrey Pokhilko wrote: >>> Sounds strange, as I tested them properly working on colleague's Mac >>> with wireless keyboard and mine KUbuntu Linux 14.04. >> >> for Linux, probably a behavior of Gnome. I play with your code for >> quick key by adding some logs/debug, on my gnome, not possible to >> catch the Ctrl+number (or ctrl+shift-number). >> >> If I change the keystroke Crtl+0 to Ctrl+U (example), the code catch >> the shortcut, but the algorithm don't works (tweak on the string >> gui.quick_X) >> >> >> Log with tail -f jmeter.log >> 2015/06/07 09:17:43 WARN - jmeter.gui.MainFrame: No component set >> through property: gui.quick_ >> ==> The last char is the code "0015" (display on my terminal a box >> with small number 0015) >> >> Log view with "less" command; >> 2015/06/07 09:17:43 WARN - jmeter.gui.MainFrame: No component set >> through property: gui.quick_^U >> ==> seems meaning Ctrl+U I think >> >> >> >>> >>> Andrey Pokhilko >>> >>> On 06/06/2015 10:20 AM, Milamber wrote: >>>> On Linux (Debian 8 / Gnome 3 / Java7/8) no shortcut works. >>>> Works on Windows 7, but need to do : Ctrl + Shift + 1,2,3, etc (on >>>> French Azerty keyboard the number are available with Shift+X) >>>> >>>> On 05/06/2015 22:06, Philippe Mouawad wrote: >>>>> Hello, >>>>> I started testing this evening and I have an issue, on Mac Book pro >>>>> there >>>>> is no numeric keypad. >>>>> So I had to change the properties to this and it works: >>>>> gui.quick_à=ThreadGroupGui >>>>> gui.quick_&=HttpTestSampleGui >>>>> gui.quick_é=RegexExtractorGui >>>>> gui.quick_"=AssertionGui >>>>> gui.quick_'=ConstantTimerGui >>>>> gui.quick_(=TestActionGui >>>>> gui.quick_§=JSR223PostProcessor >>>>> gui.quick_è=JSR223PreProcessor >>>>> gui.quick_!=DebugSampler >>>>> gui.quick_ç=ViewResultsFullVisualizer >>>>> >>>>> >>>>> Is there a better way on Mac Book Pro ? >>>>> Regards >>>>> >>>>> On Wed, Jun 3, 2015 at 1:17 PM, Andrey Pokhilko wrote: >>>>> >>>>>> "Most used" depends on every user. I believe first keys 1-5 will be >>>>>> most >>>>>> used and we already set them fine. I have just committed it into >>>>>> SVN, it >>>>>> is your right to change everything as you see it :) I set it like I >>>>>> see it. >>>>>> >>>>>> Andrey Pokhilko >>>>>> >&
Re: Component adding hotkeys
I did not think of this feature to be used with numeric keyboard, I planned it to be used with regular number keys above QWERTY keys. Do you use those keys? Numeric keyboard is indeed not consistent over different stations and we should not rely on it. Andrey Pokhilko On 06/07/2015 01:20 PM, Milamber wrote: > > In addition, some tests on Windows 7 (VM in my virtualbox on my Linux). > > The shortcut works: 1, 2, 3, 4, 5, not 6, 7, 8, not 9, not 0 > > 2015/06/07 11:12:38 INFO - jmeter.gui.MainFrame: Event gui.quick_1: > HttpTestSampleGui > 2015/06/07 11:12:39 INFO - jmeter.gui.MainFrame: Event gui.quick_2: > RegexExtractorGui > 2015/06/07 11:12:40 INFO - jmeter.gui.MainFrame: Event gui.quick_3: > AssertionGui > 2015/06/07 11:12:41 INFO - jmeter.gui.MainFrame: Event gui.quick_4: > ConstantTimerGui > 2015/06/07 11:12:41 INFO - jmeter.gui.MainFrame: Event gui.quick_5: > TestActionGui > <== missing 6 (I think that is an issue with the Collapse shortcut > (Ctrl+- : on FR Keybord, the minus is the same touch than the number 6 > (shift+- ==> 6) > 2015/06/07 11:12:44 INFO - jmeter.gui.MainFrame: Event gui.quick_7: > JSR223PreProcessor > 2015/06/07 11:12:44 INFO - jmeter.gui.MainFrame: Event gui.quick_8: > DebugSampler > 2015/06/07 11:12:45 INFO - jmeter.gui.MainFrame: Event gui.quick_8: > DebugSampler > 2015/06/07 11:12:46 INFO - jmeter.gui.MainFrame: Event > gui.quick_null: null < 9 > 2015/06/07 11:12:46 WARN - jmeter.gui.MainFrame: No component set > through property: gui.quick_null > 2015/06/07 11:13:00 INFO - jmeter.gui.MainFrame: Event > gui.quick_null: null < 0 > > Note, for this tests, I don't use Ctrl+Shift+number (don't work), I > need enable CapsLocks, and after Ctrl+number... not very friendly. > > > > On 07/06/2015 10:46, Milamber wrote: >> >> >> On 07/06/2015 07:52, Andrey Pokhilko wrote: >>> Sounds strange, as I tested them properly working on colleague's Mac >>> with wireless keyboard and mine KUbuntu Linux 14.04. >> >> for Linux, probably a behavior of Gnome. I play with your code for >> quick key by adding some logs/debug, on my gnome, not possible to >> catch the Ctrl+number (or ctrl+shift-number). >> >> If I change the keystroke Crtl+0 to Ctrl+U (example), the code catch >> the shortcut, but the algorithm don't works (tweak on the string >> gui.quick_X) >> >> >> Log with tail -f jmeter.log >> 2015/06/07 09:17:43 WARN - jmeter.gui.MainFrame: No component set >> through property: gui.quick_ >> ==> The last char is the code "0015" (display on my terminal a box >> with small number 0015) >> >> Log view with "less" command; >> 2015/06/07 09:17:43 WARN - jmeter.gui.MainFrame: No component set >> through property: gui.quick_^U >> ==> seems meaning Ctrl+U I think >> >> >> >>> >>> Andrey Pokhilko >>> >>> On 06/06/2015 10:20 AM, Milamber wrote: >>>> On Linux (Debian 8 / Gnome 3 / Java7/8) no shortcut works. >>>> Works on Windows 7, but need to do : Ctrl + Shift + 1,2,3, etc (on >>>> French Azerty keyboard the number are available with Shift+X) >>>> >>>> On 05/06/2015 22:06, Philippe Mouawad wrote: >>>>> Hello, >>>>> I started testing this evening and I have an issue, on Mac Book pro >>>>> there >>>>> is no numeric keypad. >>>>> So I had to change the properties to this and it works: >>>>> gui.quick_à=ThreadGroupGui >>>>> gui.quick_&=HttpTestSampleGui >>>>> gui.quick_é=RegexExtractorGui >>>>> gui.quick_"=AssertionGui >>>>> gui.quick_'=ConstantTimerGui >>>>> gui.quick_(=TestActionGui >>>>> gui.quick_§=JSR223PostProcessor >>>>> gui.quick_è=JSR223PreProcessor >>>>> gui.quick_!=DebugSampler >>>>> gui.quick_ç=ViewResultsFullVisualizer >>>>> >>>>> >>>>> Is there a better way on Mac Book Pro ? >>>>> Regards >>>>> >>>>> On Wed, Jun 3, 2015 at 1:17 PM, Andrey Pokhilko wrote: >>>>> >>>>>> "Most used" depends on every user. I believe first keys 1-5 will be >>>>>> most >>>>>> used and we already set them fine. I have just committed it into >>>>>> SVN, it >>>>>> is your right to change everything as you see it :) I set it like I >>>>>> see it. >>>>>> >>>>>> Andrey Pokhilko
Re: Component adding hotkeys
Tried on my colleague's mac, works as Command+0 .. Command+9 flawlessly. java version "1.8.0_31" Darwin MacBook-Pro.local 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64 Andrey Pokhilko On 06/06/2015 12:06 AM, Philippe Mouawad wrote: > Hello, > I started testing this evening and I have an issue, on Mac Book pro there > is no numeric keypad. > So I had to change the properties to this and it works: > gui.quick_à=ThreadGroupGui > gui.quick_&=HttpTestSampleGui > gui.quick_é=RegexExtractorGui > gui.quick_"=AssertionGui > gui.quick_'=ConstantTimerGui > gui.quick_(=TestActionGui > gui.quick_§=JSR223PostProcessor > gui.quick_è=JSR223PreProcessor > gui.quick_!=DebugSampler > gui.quick_ç=ViewResultsFullVisualizer > > > Is there a better way on Mac Book Pro ? > Regards > > On Wed, Jun 3, 2015 at 1:17 PM, Andrey Pokhilko wrote: > >> "Most used" depends on every user. I believe first keys 1-5 will be most >> used and we already set them fine. I have just committed it into SVN, it >> is your right to change everything as you see it :) I set it like I see it. >> >> Andrey Pokhilko >> >> On 06/03/2015 01:19 PM, Philippe Mouawad wrote: >>> On Wed, Jun 3, 2015 at 8:54 AM, Andrey Pokhilko >> > wrote: >>> >>>> Not having a Thread Group in hotkeys disbles "fluent start", when you >>>> just opened JMeter and immediately start building Test Plan with >>>> hotkeys. My UX feeling says that we should still have it. Ctrl+0 is the >>>> most rightsided key, that reflects rarity of usage. >>>> >>> Agreed >>> >>>> Having Debug Sampler and View Results Tree also required UX-wise, >>>> because you need them not frequently, but always urgently when you want >>>> to troubleshoot your script and instant usage will gratify hurrying >> user. >>> But not having CSS/JQuery extractor is not a good thing, In our scripting >>> experience it is among the top 5 elements used. >>> Although new element it is great for html extraction and makes tests more >>> maintainable >>> >>>> Finally, user can always set up his preferred keys to reflect his style >>>> of usage. >>>> >>> But hotkeys should reflect most used components. >>> >>>> Andrey Pokhilko >>>> >>>> On 06/03/2015 03:34 AM, sebb wrote: >>>>> On 2 June 2015 at 20:42, Philippe Mouawad >>> > wrote: >>>>>> Hi, >>>>>> Thanks for taking into account some notes. >>>>>> >>>>>> 1/ I would put these defaults: >>>>>> gui.quick_0=ThreadGroupGui >>>>> Although that is needed for every test, often only one is needed. >>>>> It seems wasteful to use up a quick key for this. >>>>> >>>>> Maybe a ThreadGroup should be automatically added to a new test plan. >>>>> Or a template added that includes a ThreadGroup (possibly plus a >>>>> Listener at plan level), and make that the default. >>>>> >>>>>> gui.quick_1=HttpTestSampleGui >>>>>> gui.quick_2=RegexExtractorGui >>>>>> gui.quick_3=HtmlExtractorGui >>>>>> gui.quick_4=AssertionGui >>>>>> gui.quick_5=ConstantTimerGui >>>>>> gui.quick_6=GaussianRandomTimerGui >>>>>> gui.quick_7=TestActionGui >>>>>> gui.quick_8=JSR223PostProcessor >>>>>> gui.quick_9=JSR223PreProcessor >>>>>> >>>>>> >>>>>> As for me DebugSampler is not added very frequently, same for >>>>>> ViewResultsTree. >>>>> I tend to use ViewResultsTree a lot, but again usually only one is >>>> needed. >>>>>> 2/ Is it a good thing to try to add element somewhere in the tree >>>>>> hierarchy ? I would fail if current node does not allow it. >>>>>> >>>>>> Regards >>>>>> >>>>>> On Tue, Jun 2, 2015 at 12:46 PM, Andrey Pokhilko >>> > wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I fixed issue with Ctrl+9, changed defaults slightly, added doc and >>>>>>> bugzilla https://bz.apache.org/bugzilla/show_bug.cgi?id=57988 >>>>>>> >>>>>>> If there are no objections, I will commit this change within 24 >> hours. >
