[Pharo-project] Zinc timeouts
I am trying to make the .sources downloads more stable and give proper feedback. I ran into the following problem with Zinc: | client | (client := ZnClient new) numberOfRetries: 1; timeout: 5; ifFail: [ :e | "ignore" ] url: 'http://an.url.that.does.not.exists.ch/foo'; downloadTo: '.' asFileReference; close Running this code hangs the image indefinitely (so far > 2min). Actually I would like to put #numberOfRetries to 0, since I want to fail as soon as possible during startup. However putting that the retry count to 0 yields an Exception caused by #downloadTo: ZnClient(Object)>>error: "Request not yet executed" ZnClient>>isSuccess ZnClient>>downloadTo: If I omit the #ifFail: block I get a warning about the wrong url, which is of course not what I want during startup? Is this a Zinc bug?
Hi Camillo, On 13 Jan 2013, at 18:19, Camillo Bruni <camillobruni@gmail.com> wrote:
I am trying to make the .sources downloads more stable and give proper feedback. I ran into the following problem with Zinc:
| client | (client := ZnClient new) numberOfRetries: 1; timeout: 5; ifFail: [ :e | "ignore" ] url: 'http://an.url.that.does.not.exists.ch/foo'; downloadTo: '.' asFileReference; close
Running this code hangs the image indefinitely (so far > 2min).
This is basically a DNS lookup problem, I thought that was under control: [ ZnClientTests run: #testIfFailNonExistingHost ] timeToRun. 2 See also ZnNetworkingUtils>>socketStreamToUrlDirectly:
Actually I would like to put #numberOfRetries to 0, since I want to fail as soon as possible during startup. However putting that the retry count to 0 yields an Exception caused by #downloadTo:
ZnClient(Object)>>error: "Request not yet executed" ZnClient>>isSuccess ZnClient>>downloadTo:
If I omit the #ifFail: block I get a warning about the wrong url, which is of course not what I want during startup?
Is this a Zinc bug?
I will test a bit more later on... Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 2013-01-13, at 19:19, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Camillo,
On 13 Jan 2013, at 18:19, Camillo Bruni <camillobruni@gmail.com> wrote:
I am trying to make the .sources downloads more stable and give proper feedback. I ran into the following problem with Zinc:
| client | (client := ZnClient new) numberOfRetries: 1; timeout: 5; ifFail: [ :e | "ignore" ] url: 'http://an.url.that.does.not.exists.ch/foo'; downloadTo: '.' asFileReference; close
Running this code hangs the image indefinitely (so far > 2min).
This is basically a DNS lookup problem, I thought that was under control:
[ ZnClientTests run: #testIfFailNonExistingHost ] timeToRun. 2
this test passes here, so the basic features are ok. But I think there is a strange interaction between the lookup/timeout and #downloadTo / streaming..
See also ZnNetworkingUtils>>socketStreamToUrlDirectly:
I will take a look at that tomorrow, thanks.
On 13 Jan 2013, at 19:39, Camillo Bruni <camillobruni@gmail.com> wrote:
But I think there is a strange interaction between the lookup/timeout and #downloadTo / streaming..
Yes, and that in the case of an Exception I would guess. It would be best to add some more tests. We'll see tomorrow.
Camillo, On 13 Jan 2013, at 20:18, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Jan 2013, at 19:39, Camillo Bruni <camillobruni@gmail.com> wrote:
But I think there is a strange interaction between the lookup/timeout and #downloadTo / streaming..
Yes, and that in the case of an Exception I would guess. It would be best to add some more tests.
We'll see tomorrow.
I spent some time debugging this today, I think I found the problem, but I still have to retrace my steps and do some more testing. In any case, I will be submitting a patch for NetNameResolver and NameLookupFailure in particular, there is something very odd with this exception. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 2013-01-14, at 17:44, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Camillo,
On 13 Jan 2013, at 20:18, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Jan 2013, at 19:39, Camillo Bruni <camillobruni@gmail.com> wrote:
But I think there is a strange interaction between the lookup/timeout and #downloadTo / streaming..
Yes, and that in the case of an Exception I would guess. It would be best to add some more tests.
We'll see tomorrow.
I spent some time debugging this today, I think I found the problem, but I still have to retrace my steps and do some more testing.
In any case, I will be submitting a patch for NetNameResolver and NameLookupFailure in particular, there is something very odd with this exception.
uuh nice ;) I think that will also solve another issue, where the image would hang if you submit to certain monticello repositories that are no longer online..
On 14 Jan 2013, at 17:48, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-01-14, at 17:44, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Camillo,
On 13 Jan 2013, at 20:18, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Jan 2013, at 19:39, Camillo Bruni <camillobruni@gmail.com> wrote:
But I think there is a strange interaction between the lookup/timeout and #downloadTo / streaming..
Yes, and that in the case of an Exception I would guess. It would be best to add some more tests.
We'll see tomorrow.
I spent some time debugging this today, I think I found the problem, but I still have to retrace my steps and do some more testing.
In any case, I will be submitting a patch for NetNameResolver and NameLookupFailure in particular, there is something very odd with this exception.
uuh nice ;) I think that will also solve another issue, where the image would hang if you submit to certain monticello repositories that are no longer online..
Issue with slice: http://code.google.com/p/pharo/issues/detail?id=7255 Yes, any DNS failure resulted in strange exception handling, IMO. This could indeed improve a couple more bogus situations. The following should work after you load the slice: ZnClient new timeout: 5; url: 'http://an.url.that.does.not.exists.ch/foo'; logToTranscript; downloadTo: FileSystem workingDirectory. Thanks for reporting the problem, Camilllo. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Issue with slice: http://code.google.com/p/pharo/issues/detail?id=7255
Yes, any DNS failure resulted in strange exception handling, IMO. This could indeed improve a couple more bogus situations.
thanks
The following should work after you load the slice:
ZnClient new timeout: 5; url: 'http://an.url.that.does.not.exists.ch/foo'; logToTranscript; downloadTo: FileSystem workingDirectory.
I just tried, seems like your slice improves your example, though I still get issues when changing the number of retries: ZnClient new numberOfRetries: 1; "0 works..." timeout: 5; url: 'http://an.url.that.does.not.exists.ch/foo'; logToTranscript; downloadTo: FileSystem workingDirectory. looks like it is still somewhere in the net resolver... strange
On 14 Jan 2013, at 21:54, Camillo Bruni <camillobruni@gmail.com> wrote:
Issue with slice: http://code.google.com/p/pharo/issues/detail?id=7255
Yes, any DNS failure resulted in strange exception handling, IMO. This could indeed improve a couple more bogus situations.
thanks
The following should work after you load the slice:
ZnClient new timeout: 5; url: 'http://an.url.that.does.not.exists.ch/foo'; logToTranscript; downloadTo: FileSystem workingDirectory.
I just tried, seems like your slice improves your example, though I still get issues when changing the number of retries:
ZnClient new numberOfRetries: 1; "0 works..." timeout: 5; url: 'http://an.url.that.does.not.exists.ch/foo'; logToTranscript; downloadTo: FileSystem workingDirectory.
looks like it is still somewhere in the net resolver... strange
Well, I must admit that I don't really understand why/where it hangs ;-) I saw there was a problem with NameLookupFailure and I fixed what I thought was wrong. Retry happens when something goes wrong, i.e. some exception is thrown. It shouldn't make any difference what actually happened. But testing retry behaviour is hard, I will think about a way to do that in a unit test. Sven
On 2013-01-14, at 22:05, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 14 Jan 2013, at 21:54, Camillo Bruni <camillobruni@gmail.com> wrote:
Issue with slice: http://code.google.com/p/pharo/issues/detail?id=7255
Yes, any DNS failure resulted in strange exception handling, IMO. This could indeed improve a couple more bogus situations.
thanks
The following should work after you load the slice:
ZnClient new timeout: 5; url: 'http://an.url.that.does.not.exists.ch/foo'; logToTranscript; downloadTo: FileSystem workingDirectory.
I just tried, seems like your slice improves your example, though I still get issues when changing the number of retries:
ZnClient new numberOfRetries: 1; "0 works..." timeout: 5; url: 'http://an.url.that.does.not.exists.ch/foo'; logToTranscript; downloadTo: FileSystem workingDirectory.
looks like it is still somewhere in the net resolver... strange
Well, I must admit that I don't really understand why/where it hangs ;-) I saw there was a problem with NameLookupFailure and I fixed what I thought was wrong.
Retry happens when something goes wrong, i.e. some exception is thrown. It shouldn't make any difference what actually happened.
But testing retry behaviour is hard, I will think about a way to do that in a unit test.
I can imagine :/, I will try to step through a bit further to get close to the problem.
On 14 Jan 2013, at 22:07, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-01-14, at 22:05, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 14 Jan 2013, at 21:54, Camillo Bruni <camillobruni@gmail.com> wrote:
Issue with slice: http://code.google.com/p/pharo/issues/detail?id=7255
Yes, any DNS failure resulted in strange exception handling, IMO. This could indeed improve a couple more bogus situations.
thanks
The following should work after you load the slice:
ZnClient new timeout: 5; url: 'http://an.url.that.does.not.exists.ch/foo'; logToTranscript; downloadTo: FileSystem workingDirectory.
I just tried, seems like your slice improves your example, though I still get issues when changing the number of retries:
ZnClient new numberOfRetries: 1; "0 works..." timeout: 5; url: 'http://an.url.that.does.not.exists.ch/foo'; logToTranscript; downloadTo: FileSystem workingDirectory.
looks like it is still somewhere in the net resolver... strange
Well, I must admit that I don't really understand why/where it hangs ;-) I saw there was a problem with NameLookupFailure and I fixed what I thought was wrong.
Retry happens when something goes wrong, i.e. some exception is thrown. It shouldn't make any difference what actually happened.
But testing retry behaviour is hard, I will think about a way to do that in a unit test.
I can imagine :/, I will try to step through a bit further to get close to the problem.
With Camillo's fix for NetNameResolver's ResolverMutex retrying NameLookupFailires now seems to work. Sven
participants (2)
-
Camillo Bruni -
Sven Van Caekenberghe