Sorry for the late reply, About customizing retry method whitelist:
> You case is a bit soecific no ? True, it's very undesirable scenario, but that's what you get with AWS ALB for now - I believe there are lots and lots of other users that will face the same problem. Having said that, I am in discussion with AWS about if they will fix it and with what timeline - current behavior is complete nonsense... > In this case, the bug is larger than what I thought as for now we consider > PUT as non idempotent. +DELETE also like sebb said. > 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 Thanks! I'll try to find time to check that tomorrow... > 2/ I confirm stalecheck is still available. Can you clarify what is the difference to having httpclient4.validate_after_inactivity=0? Tuukka On Thu, Mar 9, 2017 at 2:23 PM, Philippe Mouawad <[email protected] > wrote: > Thanks for link sebb. > > In this case, the bug is larger than what I thought as for now we consider > PUT as non idempotent. > > I'll commit a new fix. > Regards > > On Thu, Mar 9, 2017 at 12:20 PM, sebb <[email protected]> wrote: > > > On 9 March 2017 at 06:42, 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. > > > > PUT *is* idempotent. > > > > It may change the state of the server the first time it is sent, but > > subsequent PUTs should not change the state further. > > So it can be repeated as required. > > > > Similarly for DELETE > > > > https://tools.ietf.org/html/rfc2616#section-9.1.2 > > > > >> > > >> 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] <javascript:;>> 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] <javascript:;> > > >> > > 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] <javascript:;> > > >> > > > 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. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > -- > Cordialement. > Philippe Mouawad. >
