Re: JMeter 3.1 httpclient4.retrycount does not work
On Mon, Mar 20, 2017 at 11:11 AM, Tuukka Mustonen wrote: > Thanks! > > I am not sure about the property name though - in normal retrying, > idempotent requests (but not non-idempotent) are indeed resent. It does no > harm - two subsequent idemponent requests result in same data as just one. > > So, property "request_sent_retry_enabled" sounds like it would enable > retrying (or a subset of it) in general (to actually retry failures where > request was sent but response wasn't read properly). I think better name > would be something like "retry_all_methods"? > Why not ? > > Also, what remains a bit weird here is that in my tests HC 4 retrying is > broken in JMeter 3.1 (but worked in snapshot build) but it works for you? > It worked for me indeed at the exclusion of the bug I opened regarding method with Entity Enclosed. > Tuukka > > > On Sat, Mar 18, 2017 at 7:35 PM, Philippe Mouawad < > philippe.moua...@gmail.com> wrote: > > > Hi Tuukka, > > Thanks for your feedback. > > This feature has now been added cleanly and documented to trunk within > bug: > > https://bz.apache.org/bugzilla/show_bug.cgi?id=60888 > > > > # true if it's OK to retry requests that have been sent > > # This will retry Idempotent and non Idempotent requests > > # This should usually be false, but it can be useful > > # when testing against some Load Balancers like Amazon ELB > > #httpclient4.request_sent_retry_enabled=false > > > > See: > > - > > https://github.com/apache/httpclient/blob/4.5.x/ > > httpclient/src/main/java/org/apache/http/impl/client/ > > DefaultHttpRequestRetryHandler.java#L160 > > > > As you can guess, settings this to true means that a request could be > > received twice as we retry requests already sent. > > So this means that even Non Idempotent requests are retried. > > > > > > Regards > > Philippe > > > > On Wed, Mar 15, 2017 at 4:45 PM, Tuukka Mustonen < > > tuukka.musto...@gmail.com> > > wrote: > > > > > Ok, I added test that uses POST/PATCH/DELETE/GET methods. > > > > > > With #6020 build of JMeter > > > and httpclient4.request_sent_retry_enabled=false, there were some > > retries, > > > but mostly not. I think it retried GET (and maybe DELETE) methods but > not > > > anything else. > > > > > > With httpclient4.request_sent_retry_enabled=true, all failed requests > > were > > > retried and this resulted in zero errors. > > > > > > So yeah, this new option is something I would need/want with ALB (until > > > they fix the issue, I still haven't received reply if AWS considers it > a > > > bug or a feature). > > > > > > Though I am still not sure what it actually does: > > > > > > *"However, can you crystalize what that new property is supposed to do? > > As > > > I wrote above I thought it was to retry also non-idempotent methods, > but > > I > > > guess it's actually supposed to do something else?"* > > > > > > Tuukka > > > > > > > > > On Fri, Mar 10, 2017 at 12:08 PM, Tuukka Mustonen < > > > tuukka.musto...@gmail.com > > > > wrote: > > > > > > > > You confirm it's this night nightly or yesterday's one ? > > > > > Did you use the property: > > > > > httpclient4.request_sent_retry_enabled=true > > > > > > > > It was this build: https://builds.apache.org/job/JMeter-trunk/6020/ > > > > > > > > No, I didn't enable that property - I thought that property was to > also > > > > retry non-idempotent methods. > > > > > > > > > If you used httpclient4.request_sent_retry_enabled=true and it > works > > > > while > > > > > it doesn't with httpclient4.request_sent_retry_enabled=false > > > > > It's a good reason to add it. > > > > > BUt if it already works with : > > > > > httpclient4.request_sent_retry_enabled=false > > > > > > > > > > Then it might not be useful. Can you give feedback on this ? > > > > > > > > Yeah, I didn't declare it at so I guess it's not needed then... > > > > > > > > However, can you crystalize what that new property is supposed to do? > > As > > > I > > > > wrote above I thought it was to retry also non-idempotent methods, > but > > I > > > > guess it's actually supposed to do something else? > > > > > > > > > And we'll wait a week for your test on non idempotent methods. > > > > > > > > Ok. > > > > > > > > > Yes but it's not a good setting, in this case better use > stalecheck. > > > > > > > > Ok. > > > > > > > > Tuukka > > > > > > > > > > > > On Fri, Mar 10, 2017 at 11:27 AM, Philippe Mouawad < > > > > philippe.moua...@gmail.com> wrote: > > > > > > > >> On Fri, Mar 10, 2017 at 8:08 AM, Tuukka Mustonen < > > > >> tuukka.musto...@gmail.com> > > > >> wrote: > > > >> > > > >> > > > +DELETE also like sebb said. > > > >> > > > > > > >> > > True but iIt was not concerned by bug. > > > >> > > > > >> > Maybe I got something wrong, but you did paste DELETE originally > as > > > >> > non-idemponent in list of non-retryable methods: > > > >> > > > > >> > Delete not being implementation of HttpEntityEnclosingRequest, it > > was > > > >> not > > > >> concerned by issue. > > > >> Yes I thought wrongly Dele
Re: [apache Jmeter]
Hello, What is the error you get and what is in jmeter.log ? Thanks On Mon, Mar 20, 2017 at 3:42 PM, paulo faria wrote: > > Hi > > > Not sure if this is the right email to ask for this but ... here it goes: > > > Im using a VM with centos 7, and trying to test the jmeter. > > Im able to open the gui, but gave me an error on loading a saved test > file( that i was using to see jmeter working). > > To try to fix the error i got the plugin manager, but when i select it in > the gui i get a error mensage about the proxy, and so i tried with this > cmd: ./jmeter -H -P -N localhost but still not > working... > > > Best regards > > Paulo Faria > -- Cordialement. Philippe Mouawad.
Re: JMeter 3.1 httpclient4.retrycount does not work
On 20 March 2017 at 13:30, Tuukka Mustonen wrote: > I would expect failed/retried requests to be not calculated into results? > Otherwise they would indicate better performance than what there is (I'm > personally interested in successful throughput with 0 failures). > Depends what the test is intended to measure. If it is looking at requests processed, then retries are requests and need to be counted. > *> Either way, if retries are enabled this needs to be allowed for > when analysing results.* > > Not sure what you mean here? Retries affect the time taken and the number of requests sent/replies received. As such they can affect the result analysis and thus need to be allowed for. So although retries may do no harm to the server state, they may 'harm' the results if not taken into consideration. > To clarify my point: retrying for idempotent requests is enabled when > setting httpclient4.retrycount=1 so (even with > request_sent_retry_enabeld=false as per default). What this new property > just adds on top of that is retries are attempted also for non-idempotent > methods, thus imo name "retry_all_methods" would be better...? > > Tuukka > > > On Mon, Mar 20, 2017 at 12:34 PM, sebb wrote: > >> On 20 March 2017 at 10:11, Tuukka Mustonen >> wrote: >> > Thanks! >> > >> > I am not sure about the property name though - in normal retrying, >> > idempotent requests (but not non-idempotent) are indeed resent. It does >> no >> > harm - two subsequent idemponent requests result in same data as just >> one. >> >> Whilst it's true that multiple idempotent requests don't change the >> server state, they do affect the test results. >> >> I'm not sure if the retries are counted in the stats or not. >> >> If not, then the calculated throughput will be reduced. >> If they are included, then more requests will be counted than were >> expected. >> >> Either way, if retries are enabled this needs to be allowed for when >> analysing results. >> >> > So, property "request_sent_retry_enabled" sounds like it would enable >> > retrying (or a subset of it) in general (to actually retry failures where >> > request was sent but response wasn't read properly). I think better name >> > would be something like "retry_all_methods"? >> > >> > Also, what remains a bit weird here is that in my tests HC 4 retrying is >> > broken in JMeter 3.1 (but worked in snapshot build) but it works for you? >> > >> > Tuukka >> > >> > >> > On Sat, Mar 18, 2017 at 7:35 PM, Philippe Mouawad < >> > philippe.moua...@gmail.com> wrote: >> > >> >> Hi Tuukka, >> >> Thanks for your feedback. >> >> This feature has now been added cleanly and documented to trunk within >> bug: >> >> https://bz.apache.org/bugzilla/show_bug.cgi?id=60888 >> >> >> >> # true if it's OK to retry requests that have been sent >> >> # This will retry Idempotent and non Idempotent requests >> >> # This should usually be false, but it can be useful >> >> # when testing against some Load Balancers like Amazon ELB >> >> #httpclient4.request_sent_retry_enabled=false >> >> >> >> See: >> >> - >> >> https://github.com/apache/httpclient/blob/4.5.x/ >> >> httpclient/src/main/java/org/apache/http/impl/client/ >> >> DefaultHttpRequestRetryHandler.java#L160 >> >> >> >> As you can guess, settings this to true means that a request could be >> >> received twice as we retry requests already sent. >> >> So this means that even Non Idempotent requests are retried. >> >> >> >> >> >> Regards >> >> Philippe >> >> >> >> On Wed, Mar 15, 2017 at 4:45 PM, Tuukka Mustonen < >> >> tuukka.musto...@gmail.com> >> >> wrote: >> >> >> >> > Ok, I added test that uses POST/PATCH/DELETE/GET methods. >> >> > >> >> > With #6020 build of JMeter >> >> > and httpclient4.request_sent_retry_enabled=false, there were some >> >> retries, >> >> > but mostly not. I think it retried GET (and maybe DELETE) methods but >> not >> >> > anything else. >> >> > >> >> > With httpclient4.request_sent_retry_enabled=true, all failed requests >> >> were >> >> > retried and this resulted in zero errors. >> >> > >> >> > So yeah, this new option is something I would need/want with ALB >> (until >> >> > they fix the issue, I still haven't received reply if AWS considers >> it a >> >> > bug or a feature). >> >> > >> >> > Though I am still not sure what it actually does: >> >> > >> >> > *"However, can you crystalize what that new property is supposed to >> do? >> >> As >> >> > I wrote above I thought it was to retry also non-idempotent methods, >> but >> >> I >> >> > guess it's actually supposed to do something else?"* >> >> > >> >> > Tuukka >> >> > >> >> > >> >> > On Fri, Mar 10, 2017 at 12:08 PM, Tuukka Mustonen < >> >> > tuukka.musto...@gmail.com >> >> > > wrote: >> >> > >> >> > > > You confirm it's this night nightly or yesterday's one ? >> >> > > > Did you use the property: >> >> > > > httpclient4.request_sent_retry_enabled=true >> >> > > >> >> > > It was this build: https://builds.apache.org/job/JMeter-trunk/6020/ >> >> > > >> >> > > No, I di
[apache Jmeter]
Hi Not sure if this is the right email to ask for this but ... here it goes: Im using a VM with centos 7, and trying to test the jmeter. Im able to open the gui, but gave me an error on loading a saved test file( that i was using to see jmeter working). To try to fix the error i got the plugin manager, but when i select it in the gui i get a error mensage about the proxy, and so i tried with this cmd: ./jmeter -H -P -N localhost but still not working... Best regards Paulo Faria
Re: JMeter 3.1 httpclient4.retrycount does not work
I would expect failed/retried requests to be not calculated into results? Otherwise they would indicate better performance than what there is (I'm personally interested in successful throughput with 0 failures). *> Either way, if retries are enabled this needs to be allowed for when analysing results.* Not sure what you mean here? To clarify my point: retrying for idempotent requests is enabled when setting httpclient4.retrycount=1 so (even with request_sent_retry_enabeld=false as per default). What this new property just adds on top of that is retries are attempted also for non-idempotent methods, thus imo name "retry_all_methods" would be better...? Tuukka On Mon, Mar 20, 2017 at 12:34 PM, sebb wrote: > On 20 March 2017 at 10:11, Tuukka Mustonen > wrote: > > Thanks! > > > > I am not sure about the property name though - in normal retrying, > > idempotent requests (but not non-idempotent) are indeed resent. It does > no > > harm - two subsequent idemponent requests result in same data as just > one. > > Whilst it's true that multiple idempotent requests don't change the > server state, they do affect the test results. > > I'm not sure if the retries are counted in the stats or not. > > If not, then the calculated throughput will be reduced. > If they are included, then more requests will be counted than were > expected. > > Either way, if retries are enabled this needs to be allowed for when > analysing results. > > > So, property "request_sent_retry_enabled" sounds like it would enable > > retrying (or a subset of it) in general (to actually retry failures where > > request was sent but response wasn't read properly). I think better name > > would be something like "retry_all_methods"? > > > > Also, what remains a bit weird here is that in my tests HC 4 retrying is > > broken in JMeter 3.1 (but worked in snapshot build) but it works for you? > > > > Tuukka > > > > > > On Sat, Mar 18, 2017 at 7:35 PM, Philippe Mouawad < > > philippe.moua...@gmail.com> wrote: > > > >> Hi Tuukka, > >> Thanks for your feedback. > >> This feature has now been added cleanly and documented to trunk within > bug: > >> https://bz.apache.org/bugzilla/show_bug.cgi?id=60888 > >> > >> # true if it's OK to retry requests that have been sent > >> # This will retry Idempotent and non Idempotent requests > >> # This should usually be false, but it can be useful > >> # when testing against some Load Balancers like Amazon ELB > >> #httpclient4.request_sent_retry_enabled=false > >> > >> See: > >> - > >> https://github.com/apache/httpclient/blob/4.5.x/ > >> httpclient/src/main/java/org/apache/http/impl/client/ > >> DefaultHttpRequestRetryHandler.java#L160 > >> > >> As you can guess, settings this to true means that a request could be > >> received twice as we retry requests already sent. > >> So this means that even Non Idempotent requests are retried. > >> > >> > >> Regards > >> Philippe > >> > >> On Wed, Mar 15, 2017 at 4:45 PM, Tuukka Mustonen < > >> tuukka.musto...@gmail.com> > >> wrote: > >> > >> > Ok, I added test that uses POST/PATCH/DELETE/GET methods. > >> > > >> > With #6020 build of JMeter > >> > and httpclient4.request_sent_retry_enabled=false, there were some > >> retries, > >> > but mostly not. I think it retried GET (and maybe DELETE) methods but > not > >> > anything else. > >> > > >> > With httpclient4.request_sent_retry_enabled=true, all failed requests > >> were > >> > retried and this resulted in zero errors. > >> > > >> > So yeah, this new option is something I would need/want with ALB > (until > >> > they fix the issue, I still haven't received reply if AWS considers > it a > >> > bug or a feature). > >> > > >> > Though I am still not sure what it actually does: > >> > > >> > *"However, can you crystalize what that new property is supposed to > do? > >> As > >> > I wrote above I thought it was to retry also non-idempotent methods, > but > >> I > >> > guess it's actually supposed to do something else?"* > >> > > >> > Tuukka > >> > > >> > > >> > On Fri, Mar 10, 2017 at 12:08 PM, Tuukka Mustonen < > >> > tuukka.musto...@gmail.com > >> > > wrote: > >> > > >> > > > You confirm it's this night nightly or yesterday's one ? > >> > > > Did you use the property: > >> > > > httpclient4.request_sent_retry_enabled=true > >> > > > >> > > It was this build: https://builds.apache.org/job/JMeter-trunk/6020/ > >> > > > >> > > No, I didn't enable that property - I thought that property was to > also > >> > > retry non-idempotent methods. > >> > > > >> > > > If you used httpclient4.request_sent_retry_enabled=true and it > works > >> > > while > >> > > > it doesn't with httpclient4.request_sent_retry_enabled=false > >> > > > It's a good reason to add it. > >> > > > BUt if it already works with : > >> > > > httpclient4.request_sent_retry_enabled=false > >> > > > > >> > > > Then it might not be useful. Can you give feedback on this ? > >> > > > >> > > Yeah, I didn't declare it at so I guess it's not needed then... > >> > > > >> > > H
Re: Ant Error - Premature end of file.
Hi Felix, It's working now, I am able to get result as "BUILD SUCCESSFUL". (Runnig CMD from normal user as well as admin both works.) *Changes:* I created new XML file and put below lines in it and saved as .jtl extension. Now I am facing another issue.When I run Test.html, I am getting blank values in report. I have used a valid jmx file which was working in GUI mode and I got results as well. Need to start new thread or shall continue with same thread. [image: Inline image 1] On Sun, Mar 19, 2017 at 6:42 PM, Felix Schumacher < felix.schumac...@internetallee.de> wrote: > Am 16.03.2017 um 13:13 schrieb praveen tiwari: > >> Hi All, >> >> I am trying to run jmeter from ant and getting below error, reference ( >> http://testingfreak.com/step-by-step-process-to-run-jmx- >> file-through-command-prompt-using-ant-and-generate-html-report/) >> >> *Changes in Build.xml (highlighted in yellow):* >> >> -Djmeter.home=.. - C:\apache-jmeter-r1787116 >> >> -Dreport.title="My Report" - title for html report (default is >> 'Load Test Results') >> >> >> >> >> >> >> >> >> >> *Error:* >> >> C:\apache-ant-1.10.1\bin>ant >> Buildfile: C:\apache-ant-1.10.1\bin\build.xml >> >> run: >> [echo] funcMode = false >> [jmeter] Executing test plan: C:\apache-ant-1.10.1\bin\Test.jmx ==> >> C:\apache-ant-1.10.1\bin\Test.jtl >> >> _message_xalan: >> >> xslt-report: >> [xslt] Processing C:\apache-ant-1.10.1\bin\Test.jtl to >> C:\apache-ant-1.10.1\bin\Test.html >> [xslt] Loading stylesheet C:\apache-ant-1.10.1\bin\ >> jmeter-results-detail-report_21.xsl >> [xslt] C:\apache-ant-1.10.1\bin\Test.jtl:1:1: Fatal Error! >> Premature >> end of file. >> [xslt] Failed to process C:\apache-ant-1.10.1\bin\Test.jtl >> >> BUILD FAILED >> C:\apache-ant-1.10.1\bin\build.xml:124: Fatal error during transformation >> using C:\apache-ant-1.10.1\bin\jmeter-results-detail-report_21.xsl: >> Premature end of file.; SystemID: file:/C:/apache-ant-1.10.1/bin >> /Test.jtl; >> Line#: 1; Column#: 1 >> >> Total time: 4 seconds >> >> C:\apache-ant-1.10.1\bin> >> >> Can you please help, let me know if you need additional information. >> > Does the file Test.jtl really exist in C:\apache-ant-1.10.1\bin? > Can you access it with the user, that is running the ant script? > > I tried to do the following steps: > > 1. Download JMeter from jmeter.apache.org into /tmp and extract it there > 2. go into /tmp/apache-jmeter-3.1/extras > 3. run ant > 4. open Test.html in a web browser > > No problems detected. > > Regards, > Felix > >> >> > > - > To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org > For additional commands, e-mail: user-h...@jmeter.apache.org > > -- Praveen Kumar Tiwari
Re: JMeter 3.1 httpclient4.retrycount does not work
On 20 March 2017 at 10:11, Tuukka Mustonen wrote: > Thanks! > > I am not sure about the property name though - in normal retrying, > idempotent requests (but not non-idempotent) are indeed resent. It does no > harm - two subsequent idemponent requests result in same data as just one. Whilst it's true that multiple idempotent requests don't change the server state, they do affect the test results. I'm not sure if the retries are counted in the stats or not. If not, then the calculated throughput will be reduced. If they are included, then more requests will be counted than were expected. Either way, if retries are enabled this needs to be allowed for when analysing results. > So, property "request_sent_retry_enabled" sounds like it would enable > retrying (or a subset of it) in general (to actually retry failures where > request was sent but response wasn't read properly). I think better name > would be something like "retry_all_methods"? > > Also, what remains a bit weird here is that in my tests HC 4 retrying is > broken in JMeter 3.1 (but worked in snapshot build) but it works for you? > > Tuukka > > > On Sat, Mar 18, 2017 at 7:35 PM, Philippe Mouawad < > philippe.moua...@gmail.com> wrote: > >> Hi Tuukka, >> Thanks for your feedback. >> This feature has now been added cleanly and documented to trunk within bug: >> https://bz.apache.org/bugzilla/show_bug.cgi?id=60888 >> >> # true if it's OK to retry requests that have been sent >> # This will retry Idempotent and non Idempotent requests >> # This should usually be false, but it can be useful >> # when testing against some Load Balancers like Amazon ELB >> #httpclient4.request_sent_retry_enabled=false >> >> See: >> - >> https://github.com/apache/httpclient/blob/4.5.x/ >> httpclient/src/main/java/org/apache/http/impl/client/ >> DefaultHttpRequestRetryHandler.java#L160 >> >> As you can guess, settings this to true means that a request could be >> received twice as we retry requests already sent. >> So this means that even Non Idempotent requests are retried. >> >> >> Regards >> Philippe >> >> On Wed, Mar 15, 2017 at 4:45 PM, Tuukka Mustonen < >> tuukka.musto...@gmail.com> >> wrote: >> >> > Ok, I added test that uses POST/PATCH/DELETE/GET methods. >> > >> > With #6020 build of JMeter >> > and httpclient4.request_sent_retry_enabled=false, there were some >> retries, >> > but mostly not. I think it retried GET (and maybe DELETE) methods but not >> > anything else. >> > >> > With httpclient4.request_sent_retry_enabled=true, all failed requests >> were >> > retried and this resulted in zero errors. >> > >> > So yeah, this new option is something I would need/want with ALB (until >> > they fix the issue, I still haven't received reply if AWS considers it a >> > bug or a feature). >> > >> > Though I am still not sure what it actually does: >> > >> > *"However, can you crystalize what that new property is supposed to do? >> As >> > I wrote above I thought it was to retry also non-idempotent methods, but >> I >> > guess it's actually supposed to do something else?"* >> > >> > Tuukka >> > >> > >> > On Fri, Mar 10, 2017 at 12:08 PM, Tuukka Mustonen < >> > tuukka.musto...@gmail.com >> > > wrote: >> > >> > > > You confirm it's this night nightly or yesterday's one ? >> > > > Did you use the property: >> > > > httpclient4.request_sent_retry_enabled=true >> > > >> > > It was this build: https://builds.apache.org/job/JMeter-trunk/6020/ >> > > >> > > No, I didn't enable that property - I thought that property was to also >> > > retry non-idempotent methods. >> > > >> > > > If you used httpclient4.request_sent_retry_enabled=true and it works >> > > while >> > > > it doesn't with httpclient4.request_sent_retry_enabled=false >> > > > It's a good reason to add it. >> > > > BUt if it already works with : >> > > > httpclient4.request_sent_retry_enabled=false >> > > > >> > > > Then it might not be useful. Can you give feedback on this ? >> > > >> > > Yeah, I didn't declare it at so I guess it's not needed then... >> > > >> > > However, can you crystalize what that new property is supposed to do? >> As >> > I >> > > wrote above I thought it was to retry also non-idempotent methods, but >> I >> > > guess it's actually supposed to do something else? >> > > >> > > > And we'll wait a week for your test on non idempotent methods. >> > > >> > > Ok. >> > > >> > > > Yes but it's not a good setting, in this case better use stalecheck. >> > > >> > > Ok. >> > > >> > > Tuukka >> > > >> > > >> > > On Fri, Mar 10, 2017 at 11:27 AM, Philippe Mouawad < >> > > philippe.moua...@gmail.com> wrote: >> > > >> > >> On Fri, Mar 10, 2017 at 8:08 AM, Tuukka Mustonen < >> > >> tuukka.musto...@gmail.com> >> > >> wrote: >> > >> >> > >> > > > +DELETE also like sebb said. >> > >> > > > >> > >> > > True but iIt was not concerned by bug. >> > >> > >> > >> > Maybe I got something wrong, but you did paste DELETE originally as >> > >> > non-idemponent in list of non-retryable methods: >> > >> > >> > >> > Delete
Re: Jmeter Hangs - Running 150 HTTP Requests
Hi Felix, Unfortunately I won't be able to share HTML file. Content type in most requests are as below: font/x-woff2 application/json; charset=utf-8 text/javascript;charset=utf-8 image/gif text/html; charset=utf-8 text/javascript;charset=ISO-8859-1 text/css; charset=utf-8 On Sun, Mar 19, 2017 at 5:51 PM, Felix Schumacher < felix.schumac...@internetallee.de> wrote: > Am 16.03.2017 um 13:04 schrieb praveen tiwari: > >> Hi Felix, >> >> - Sampler Result >> >> Thread Name: Thread Group 1-1 >> Sample Start: 2017-03-16 04:07:53 PDT >> Load time: 1810 >> Connect Time: 1158 >> Latency: 1526 >> Size in bytes: 32526 >> Headers size in bytes: 1351 >> Body size in bytes: 31175 >> Sample Count: 1 >> Error Count: 0 >> Response code: 200 >> Response message: OK >> >> Response headers: >> HTTP/1.1 200 OK >> Cache-Control: private >> Content-Type: text/html; charset=utf-8 >> >> When I copy the response in word, it contains 1801 words. >> >> - How long does it take, until I can use the gui again? >> Time elapsed in my stopwatch is 11 min:03Sec:60ms >> Is this due to some configuration issues on my machine? >> >> *Configuration:* >> RAM: 2GB Processor: Intel(R) Xeon(R) CPU E5620 @2.40GHz 2.39 GHz >> Operating System: Microsoft Windows 2012 R2 standard >> > > Can you share a sample html file? I tried to recreate it with a simple > html file that was around 32kb, but no luck so far. > > If you can't: What characters are contained (ASCII plus some UTF-8, Mostly > UTF-8, ...; new-lines, no-break spaces, ...) > > Regards, > Felix > > >> For new question, I will start new thread. >> >> >> On Thu, Mar 16, 2017 at 4:50 PM, Felix Schumacher < >> felix.schumac...@internetallee.de> wrote: >> >> Am 16.03.2017 11:58, schrieb praveen tiwari: >>> >>> Hi Felix, - Yes I have large responses. Can you post a sample of such a response, or give general statistics >>> about >>> it, like >>> * the content-type >>> * the size >>> * line length(s) >>> * type of characters >>> >>> >>> - Regarding your first option, if I disable the result tree element while running, how will be I able to see the results for debugging. When I record a script, I need to execute it once to see the response and get regular expression. I tried running in Non-GUI mode but after that I am not able to see the request in view result tree. Posted other mail in group with subject "Jmeter in Non-GUI Mode - Blank Request and Response". - Regarding second option, I downloaded latest files from " https://ci.apache.org/projects/jmeter/nightlies/";, this version also hangs when I execute whole flow and try to click on requests to see the result. How long does it take, until you can use the gui again? >>> I believe Phillippe has reported the long rendering already to Oracle. >>> >>> >>> *Files downloaded:* apache-jmeter-r1787116 apache-jmeter-r1787116_src Not able to find help for "Run ant download_jars from the top-level directory to fetch the dependencies." mentioned on above site. You don't have to compile the nightlies, just unzip them. (You don't >>> need >>> the src to run JMeter) >>> >>> >>> In addition, I am trying to run jmeter from ant and getting below error, reference ( http://testingfreak.com/step-by-step-process-to-run-jmx-file -through-command-prompt-using-ant-and-generate-html-report/ ) This seems to be a new question. Please start a new mail thread. >>> >>> Regards, >>> Felix >>> >>> >>> *Changes in Build.xml (highlighted in yellow):* -Djmeter.home=.. - C:\apache-jmeter-r1787116 -Dreport.title="My Report" - title for html report (default is 'Load Test Results') *Error:* C:\apache-ant-1.10.1\bin>ant Buildfile: C:\apache-ant-1.10.1\bin\build.xml run: [echo] funcMode = false [jmeter] Executing test plan: C:\apache-ant-1.10.1\bin\Test.jmx ==> C:\apache-ant-1.10.1\bin\Test.jtl _message_xalan: xslt-report: [xslt] Processing C:\apache-ant-1.10.1\bin\Test.jtl to C:\apache-ant-1.10.1\bin\Test.html [xslt] Loading stylesheet C:\apache-ant-1.10.1\bin\jmeter-results-detail-report_21.xsl [xslt] C:\apache-ant-1.10.1\bin\Test.jtl:1:1: Fatal Error! Premature end of file. [xslt] Failed to process C:\apache-ant-1.10.1\bin\Test.jtl BUILD FAILED C:\apache-ant-1.10.1\bin\build.xml:124: Fatal error during transformation using C:\apache-ant-1.10.1\bin\jmeter-results-detail-report_21.xsl: Premature end of file.; SystemID: file:/C:/apache-ant-1.10.1/bin /Test.jtl; Line#: 1; Column#: 1 Total time: 4 seconds C:\apache-ant-1.10.1\bin> Can you please help, let me know if you need additional information.
Re: JMeter 3.1 httpclient4.retrycount does not work
Thanks! I am not sure about the property name though - in normal retrying, idempotent requests (but not non-idempotent) are indeed resent. It does no harm - two subsequent idemponent requests result in same data as just one. So, property "request_sent_retry_enabled" sounds like it would enable retrying (or a subset of it) in general (to actually retry failures where request was sent but response wasn't read properly). I think better name would be something like "retry_all_methods"? Also, what remains a bit weird here is that in my tests HC 4 retrying is broken in JMeter 3.1 (but worked in snapshot build) but it works for you? Tuukka On Sat, Mar 18, 2017 at 7:35 PM, Philippe Mouawad < philippe.moua...@gmail.com> wrote: > Hi Tuukka, > Thanks for your feedback. > This feature has now been added cleanly and documented to trunk within bug: > https://bz.apache.org/bugzilla/show_bug.cgi?id=60888 > > # true if it's OK to retry requests that have been sent > # This will retry Idempotent and non Idempotent requests > # This should usually be false, but it can be useful > # when testing against some Load Balancers like Amazon ELB > #httpclient4.request_sent_retry_enabled=false > > See: > - > https://github.com/apache/httpclient/blob/4.5.x/ > httpclient/src/main/java/org/apache/http/impl/client/ > DefaultHttpRequestRetryHandler.java#L160 > > As you can guess, settings this to true means that a request could be > received twice as we retry requests already sent. > So this means that even Non Idempotent requests are retried. > > > Regards > Philippe > > On Wed, Mar 15, 2017 at 4:45 PM, Tuukka Mustonen < > tuukka.musto...@gmail.com> > wrote: > > > Ok, I added test that uses POST/PATCH/DELETE/GET methods. > > > > With #6020 build of JMeter > > and httpclient4.request_sent_retry_enabled=false, there were some > retries, > > but mostly not. I think it retried GET (and maybe DELETE) methods but not > > anything else. > > > > With httpclient4.request_sent_retry_enabled=true, all failed requests > were > > retried and this resulted in zero errors. > > > > So yeah, this new option is something I would need/want with ALB (until > > they fix the issue, I still haven't received reply if AWS considers it a > > bug or a feature). > > > > Though I am still not sure what it actually does: > > > > *"However, can you crystalize what that new property is supposed to do? > As > > I wrote above I thought it was to retry also non-idempotent methods, but > I > > guess it's actually supposed to do something else?"* > > > > Tuukka > > > > > > On Fri, Mar 10, 2017 at 12:08 PM, Tuukka Mustonen < > > tuukka.musto...@gmail.com > > > wrote: > > > > > > You confirm it's this night nightly or yesterday's one ? > > > > Did you use the property: > > > > httpclient4.request_sent_retry_enabled=true > > > > > > It was this build: https://builds.apache.org/job/JMeter-trunk/6020/ > > > > > > No, I didn't enable that property - I thought that property was to also > > > retry non-idempotent methods. > > > > > > > If you used httpclient4.request_sent_retry_enabled=true and it works > > > while > > > > it doesn't with httpclient4.request_sent_retry_enabled=false > > > > It's a good reason to add it. > > > > BUt if it already works with : > > > > httpclient4.request_sent_retry_enabled=false > > > > > > > > Then it might not be useful. Can you give feedback on this ? > > > > > > Yeah, I didn't declare it at so I guess it's not needed then... > > > > > > However, can you crystalize what that new property is supposed to do? > As > > I > > > wrote above I thought it was to retry also non-idempotent methods, but > I > > > guess it's actually supposed to do something else? > > > > > > > And we'll wait a week for your test on non idempotent methods. > > > > > > Ok. > > > > > > > Yes but it's not a good setting, in this case better use stalecheck. > > > > > > Ok. > > > > > > Tuukka > > > > > > > > > On Fri, Mar 10, 2017 at 11:27 AM, Philippe Mouawad < > > > philippe.moua...@gmail.com> wrote: > > > > > >> On Fri, Mar 10, 2017 at 8:08 AM, Tuukka Mustonen < > > >> tuukka.musto...@gmail.com> > > >> wrote: > > >> > > >> > > > +DELETE also like sebb said. > > >> > > > > > >> > > True but iIt was not concerned by bug. > > >> > > > >> > Maybe I got something wrong, but you did paste DELETE originally as > > >> > non-idemponent in list of non-retryable methods: > > >> > > > >> > Delete not being implementation of HttpEntityEnclosingRequest, it > was > > >> not > > >> concerned by issue. > > >> Yes I thought wrongly Delete was not idempotent > > >> > > >> > > - Idempotent HTTP methods which are by default those that do not > > >> > implement > > >> > > > HttpEntityEnclosingRequest, so not POST, PUT,DELETE, PATCH, GET > > With > > >> > body > > >> > > > >> > > 1/ To diagnose set those classes in debug mode: > > >> > > org.apache.http.impl.client.DefaultRequestDirector > > >> > > > > >> > > You should see: > > >> > > Retrying connect to > > >> > > Retrying request to > > >>
