> On 2019-01-19, at 10:27 AM, Chris Muller <asqueaker at gmail.com> wrote:
> 
> The problem is you have your timeout set to low,

Well, strictly speaking, the #httpGet.... method has that problem, not any code I touched. A longer timeout does sound like a better solution.

It looks like WebClient is using the Socket standardTimeout by default and that is 45. I guessed that would be milliseconds though there is no comment saying so in Socket class>>#standardTimeout .. but Socket class>>#standardDeadline makes it look more like that would be 45 seconds. And SocketStream>>#timeout: refers to it as seconds so that would mean a really long seeming timeout. I'm pretty sure that in my initial problem email there was no delay anywhere near that long before the first notifier opened.

> not the server
> not receiving the request.  Retry'ing doesn't make the initial request
> come back any sooner, you're simply hammering the server with
> duplicate request(s).

Good point. It would be nice to cleanly handle all the possible errors with properly error specific responses;. One would need to know more about network handling than I to do it comprehensively.

And this is why I was asking for input from people with more familiarity with  network stuff.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
The halfway point between right and wrong is still damn wrong. Compromise isn't always a solution