I agree to sebb here. Andrey Pokhilko
On 08.04.2017 13:32, sebb wrote: > On 7 April 2017 at 17:45, Philippe Mouawad <[email protected]> wrote: >> On Fri, Apr 7, 2017 at 6:39 PM, sebb <[email protected]> wrote: >> >>> On 7 April 2017 at 17:35, Philippe Mouawad <[email protected]> >>> wrote: >>>> On Fri, Apr 7, 2017 at 6:30 PM, sebb <[email protected]> wrote: >>>> >>>>> On 7 April 2017 at 17:27, Philippe Mouawad <[email protected]> >>>>> wrote: >>>>>> On Fri, Apr 7, 2017 at 10:44 AM, sebb <[email protected]> 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 < >>> [email protected]> >>>>>>> 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.
