On 7 April 2017 at 17:45, Philippe Mouawad <philippe.moua...@gmail.com> wrote: > On Fri, Apr 7, 2017 at 6:39 PM, sebb <seb...@gmail.com> wrote: > >> On 7 April 2017 at 17:35, Philippe Mouawad <philippe.moua...@gmail.com> >> wrote: >> > On Fri, Apr 7, 2017 at 6:30 PM, sebb <seb...@gmail.com> wrote: >> > >> >> On 7 April 2017 at 17:27, Philippe Mouawad <philippe.moua...@gmail.com> >> >> wrote: >> >> > On Fri, Apr 7, 2017 at 10:44 AM, sebb <seb...@gmail.com> wrote: >> >> > >> >> >> If a user property is renamed, it may break some tests. >> >> >> >> >> > It was introduced only few days ago for tuukka. >> >> >> >> OK, in which case it can be renamed or deleted with impunity. >> >> >> > Do you think the new name is better ? clearer for users ? >> > >> > >> > - request_sent_retry_enabled >> > - retry_all_methods >> > - Or maybe retry_all_http_methods >> >> What does the property control? >> > The retry of requests that have already been sent (not idempotent). You can > read the mentioned thread. > > The use case is a bit edgy (AWS LB) but I think it is useful for a lot of > use cases as Cloud deployments are increasing.
I'm not convinced that it is a good idea to implement this. It seems wrong for JMeter to retry failed requests in such a case as it goes against the RFCs. After all, what will browsers do? They cannot automatically retry non-idempotent requests. They have to defer to the user who can decide whether or not to try again. In some cases it may be obvious that a retry is OK. In other cases it's not obvious (e.g. click to purchase) and the user must use other means to determine whether to retry or not. JMeter cannot know which POSTs are OK to retry and which are not. Far better to accept the failure for what it is rather than try and hide it. Or perhaps add such a retry as an option on individual HTTP requests. That would be closer to how a it works in real life - certain requests are known to be OK to retry. The setting should probably not be included on the HTTP Config screen. Or if it is, ensure the consequences are clearly spelled out. However if the consensus is to add the global retry property, then the name should make it clear (and the documentation ditto) For example: # set this property to automatically retry non-idempotent requests. # This should rarely if ever be used, because the resulting state of the server is undefined #retry_non_idempotent_methods But I don't think it's a good idea to allow global retries of non-idempotent methods. > Excerpt: > -------------------------------------------------------------------------------------------------------- > 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). > > -------------------------------------------------------------------------------------------------------- > > > >> > >> > >> >> > >> >> >> >> >> >> It is possible to rename, but you need to keep the old name as an >> >> >> alias for at least one revision, and usage of the old alias should >> >> >> generate a warning log message. >> >> >> >> >> >> On 6 April 2017 at 20:44, Philippe Mouawad < >> philippe.moua...@gmail.com> >> >> >> wrote: >> >> >> > Hello, >> >> >> > As per discussion "JMeter 3.1 httpclient4.retrycount does not >> work" on >> >> >> user >> >> >> > mailing list, >> >> >> > do you think we should rename this property ? >> >> >> > >> >> >> > Thanks >> >> >> > Regards >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Cordialement. >> >> > Philippe Mouawad. >> >> >> > >> > >> > >> > -- >> > Cordialement. >> > Philippe Mouawad. >> > > > > -- > Cordialement. > Philippe Mouawad.
