Hello Tukka, 1/ To diagnose set those classes in debug mode: org.apache.http.impl.client.DefaultRequestDirector
You should see: Retrying connect to Retrying request to Log level can be set in log4j2.xml 2/ I confirm stalecheck is still available. To enable it ensure you set in user.properties (you may have to point to absolute path, check logs): hc.parameters.file=hc.parameters And in hc.parameters: http.connection.stalecheck$Boolean=true Regards @philmdot On Thu, Mar 9, 2017 at 7:42 AM, Philippe Mouawad <[email protected] > wrote: > > > On Thursday, March 9, 2017, Tuukka Mustonen <[email protected]> > wrote: > >> Hi Philippe and thanks for speedy actions! >> >> 1) Retrying only idempotent requests makes sense, as usual. But this >> (retry >> on idempotent) seems to be only documented on wiki page ( >> https://wiki.apache.org/jmeter/JMeterSocketClosed). You should add it >> also >> to http://jmeter.apache.org/usermanual/component_reference.html. >> >> 2) In this case, the requests are GETs (and without body) so they should >> be >> retried. > > Yes. > I debugged it and I confirm they are unless you face the exceptions I > mentionned. > >> >> So the bug you fixed shouldn't affect this scenario. > > Yes > >> >> There must be >> something else - any pointers to what logging module/level I should enable >> to inspect the (failing) retry logic? > > As you can see there is no logging in this HC4 class > Try the calling class. I' ll provide its name later > >> >> 3) AFAIK PUT is idempotent - shouldn't you retry also that? > > No it's not IMU, it changes state of server. > >> >> 4) In this case, once I add tests for POST/PATCH/DELETE etc. I also want >> to >> retry these non-idempotent requests (to tolerate ALBs ugly behavior). >> These >> are "just" performance tests so I don't care if I'm creating duplicate >> data. Is there way to specify custom method whitelist to retry any HTTP >> method? I see requestSentRetryEnabled in HC4 source code - can I enable >> that somehow? > > Not for now. > You case is a bit soecific no ? > >> >> 5) *Related question: >> is http.connection.stalecheck$Boolean=false (in hc.parameters file) valid >> anymore on JMeter 3.x with improved retry/stale logic >> (and httpclient4.validate_after_inactivity)? The line is still there in >> bundled hc.parameters file...* > > i'll double check > >> >> Tuukka >> >> >> On Thu, Mar 9, 2017 at 12:25 AM, Philippe Mouawad < >> [email protected]> wrote: >> >> > Hello, >> > The issue with Get with body should be fixed now: >> > - https://bz.apache.org/bugzilla/show_bug.cgi?id=60837 >> > >> > Regards >> > Philippe >> > >> > On Wed, Mar 8, 2017 at 8:53 PM, Philippe Mouawad < >> > [email protected] >> > > wrote: >> > >> > > Hello Tuukka, >> > > >> > > In my recent tests I didn't face any issue with >> httpclient4.retrycount. >> > > For me it works but be aware that JMeter (HC4) does not retry all >> > > requests, it only retries those it is allowed to : >> > > - Idempotent HTTP methods which are by default those that do not >> > implement >> > > HttpEntityEnclosingRequest, so not POST, PUT,DELETE, PATCH, GET With >> body >> > > (<= That might be a bug thinking more about it) >> > > - Non retriable exceptions (InterruptedIOException.class, >> > > UnknownHostException.class, ConnectException.class, >> SSLException.class) >> > > - + Some other reasons >> > > >> > > See: >> > > https://github.com/apache/httpclient/blob/4.5.x/ >> > > httpclient/src/main/java/org/apache/http/impl/client/ >> > > DefaultHttpRequestRetryHandler.java#L129 >> > > >> > > >> > > Regards >> > > Philippe >> > > >> > > >> > > On Wed, Mar 8, 2017 at 2:14 PM, Tuukka Mustonen < >> > [email protected] >> > > > wrote: >> > > >> > >> My problem is that AWS Application Load Balancer (ALB) terminates all >> > >> existing connections during configuration changes (including >> > >> auto-scaling). >> > >> As my perf tests trigger auto-scaling, I want to retry failed >> requests >> > >> that >> > >> ALB connection termination causes. >> > >> >> > >> This results in a bunch of NoHttpResponseException whenever scaling >> > occurs >> > >> (=when ALB terminates existing connections). >> > >> >> > >> (And yeah, this load balancer behavior is weird and ugly but it's >> what >> > >> they >> > >> confirmed). >> > >> >> > >> Using HttpClient 4, In user.properties I have set: >> > >> >> > >> httpclient4.retrycount=1 >> > >> >> > >> But that does nothing. I even tried: >> > >> >> > >> httpclient4.retrycount=100000000 >> > >> >> > >> But zero effect. >> > >> >> > >> Switching to HttpClient 3.1 reproduces the problem. However, with >> > >> HttpClient 3 and: >> > >> >> > >> httpclient3.retrycount=1 >> > >> >> > >> The problem vanishes so I assume retrying then works. >> > >> >> > >> I couldn't find where retry-attempts are logged so I have no "proof" >> > that >> > >> HttpClient 4 wouldn't actually retry, but a) retrycount makes >> difference >> > >> on >> > >> HttpClient 3.1 but not on 4 b) I would assume my whole process should >> > >> crash >> > >> with retrycount=100000000 if it was really applied. >> > >> >> > >> Related question: is http.connection.stalecheck$Boolean=false (in >> > >> hc.parameters file) valid anymore on JMeter 3.x with improved >> > retry/stale >> > >> logic (and httpclient4.validate_after_inactivity)? The line is still >> > >> there >> > >> in bundled hc.parameters file... >> > >> >> > >> Tested on JMeter 3.1. >> > >> >> > >> Any open (or already fixed) tickets about this? Couldn't find any... >> > >> >> > >> FYI: to describe better what happens during ALB connection >> termination: >> > >> >> > >> ...Successful communication with keep-alive... >> > >> - ALB responds to a request, and sends Connection: keep-alive so >> JMeter >> > >> leaves the connection open >> > >> - JMeter sends a new request >> > >> - ALB may might or might not ack it (not sure if there was pattern) >> > >> - ALB closes connection on TCP level (FIN) >> > >> - Connection gets closed and so sent request failed and needs to be >> > >> retried >> > >> >> > >> I think this generates NoHttpResponseException in JMeter. >> > >> >> > >> Tuukka >> > >> >> > > >> > > >> > > >> > > -- >> > > Cordialement. >> > > Philippe Mouawad. >> > > >> > > >> > > >> > >> > >> > -- >> > Cordialement. >> > Philippe Mouawad. >> > >> > > > -- > Cordialement. > Philippe Mouawad. > > > > -- Cordialement. Philippe Mouawad.
