On 16 Sep 2012, at 23:14, Camillo Bruni <[email protected]> wrote:
>>> the culprit IMO is ZnClient>>#executeWithRetriesRemaining: which does a >>> on: Exception do:[ ... retry ]. so that means on an HTTPProgress you >>> initiate a retry? (and wait for retryDelay), AUCH! :D >> >> Yeah, that is probably it, and that is horrible, terrible. .. ;-) >> In #executeWithTimeout a special #exceptionSetForIfFail is used to avoid >> that, if I remember correctly. >> Tomorrow, I'll have another look, with a fresh head. > > cool ;) I assume a simple Exception => Error will do :P Well, no ;-) I think it would be better to only do a retry on NetworkErrors and ZnParseErrors. On the other hand, the ifFail functionality should trigger on any Error. We'll see. Thanks again for the help, you made Pharo faster by removing my explicit Delays ;-) Sven Sven Van Caekenberghe uploaded a new version of Zinc-HTTP to project Zinc HTTP Components: http://www.squeaksource.com/ZincHTTPComponents/Zinc-HTTP-SvenVanCaekenberghe.301.mcz ==================== Summary ==================== Name: Zinc-HTTP-SvenVanCaekenberghe.301 Author: SvenVanCaekenberghe Time: 17 September 2012, 10:10:49 am UUID: 85632c09-a6c4-40e9-b29b-1c5e86d07ead Ancestors: Zinc-HTTP-SvenVanCaekenberghe.300 Fixed a bug where HTTPProgress notifications would trigger a retry. Thanks Camillo Bruni for finding this problem and suggesting a solution. Now, retries are only triggered by (NetworkError, ZnParseError), while the #ifFailBlock will be trigger on any Error. Furthermore, #noteRetrying: and noteIgnoringExceptionOnReusedConnection: will report on the actual exception. The default #ifFailBlock is now [ :exception | exception pass ] for some cleaner code. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
