Yes, more exactly if you run: 'http://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/2.5_month.csv' asUrl retrieveContents
try get this stack trace: https://dl.dropboxusercontent.com/u/83145561/Debugger-Stack-Socket-2016-03-02-134847.fuel I can open the url in my browser. Cheers. Uko > On 02 Mar 2016, at 13:35, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > >> On 02 Mar 2016, at 13:28, Yuriy Tymchuk <yuriy.tymc...@me.com> wrote: >> >> For me it’s also happening when I run >> RTMapLocationExample>>#exampleSeismOnEarth > > I do not have that code. What is the URL that fails to load ? > >> Uko >> >>> On 30 Sep 2015, at 10:36, Andrei Chis <chisvasileand...@gmail.com> wrote: >>> >>> In my case it's still failing with 'Connection closed while waiting for >>> data.' >>> >>> Cheers, >>> Andrei >>> >>> On Wed, Sep 30, 2015 at 9:29 AM, Sven Van Caekenberghe <s...@stfx.eu> wrote: >>> >>>> On 30 Sep 2015, at 08:16, Volkert <volk...@komponentenwerkstatt.de> wrote: >>>> >>>> For your information: today i tried again and know it works as expected ... >>> >>> OK, thanks for letting us know. >>> >>>> Same net >>>> Same pharo-vm/image >>>> Same ubuntu/kernel >>>> >>>> Strange .... maybe the "blood moon" on monday ... >>> >>> Yes, weird. >>> >>>> $ ./pharo Pharo.image eval >>>> "'http://bl.ocks.org/ostock/raw/4063318/dji.csv' asUrl retrieveContents" >>>> 'Date,Open,High,Low,Close,Volume,Adj Close >>>> 2010-10-01,10789.72,10907.41,10759.14,10829.68,4298910000,10829.68 >>>> 2010-09-30,10835.96,10960.99,10732.27,10788.05,4284160000,10788.05 >>>> 2010-09-29,10857.98,10901.96,10759.75,10835.28,3990280000,10835.28 >>>> 2010-09-28,10809.85,10905.44,10714.03,10858.14,4025840000,10858.14 >>>> 2010-09-27,10860.03,10902.52,10776.44,10812.04,3587860000,10812.04 >>>> 2010-09-24,10664.39,10897.83,10664.39,10860.26,4123950000,10860.26 >>>> 2010-09-23,10738.48,10779.65,10610.12,10662.42,3847850000,10662.42 >>>> 2010-09-22,10761.11,10829.75,10682.40,10739.31,3911070000,10739.31 >>>> 2010-09-21,10753.39,10844.89,10674.83,10761.03,4175660000,10761.03 >>>> 2010-09-20,10608.08,10783.51,10594.38,10753.62,3364080000,10753.62 >>>> >>>> .... >>>> >>>> >>>> On 25.09.2015 19:58, stepharo wrote: >>>>> Thanks for spotting this problem. >>>>> >>>>> >>>>> Le 21/9/15 11:33, Volkert a écrit : >>>>>> Switching the socket implementation works ... >>>>>> >>>>>> $./pharo Pharo.image eval "ZnNetworkingUtils default socketStreamClass: >>>>>> SocketStream. 'http://bl.ocks.org/mbostock/raw/4063318/dji.csv' asUrl >>>>>> retrieveContents" >>>>>> 'Date,Open,High,Low,Close,Volume,Adj Close >>>>>> 2010-10-01,10789.72,10907.41,10759.14,10829.68,4298910000,10829.68 >>>>>> 2010-09-30,10835.96,10960.99,10732.27,10788.05,4284160000,10788.05 >>>>>> 2010-09-29,10857.98,10901.96,10759.75,10835.28,3990280000,10835.28 >>>>>> 2010-09-28,10809.85,10905.44,10714.03,10858.14,4025840000,10858.14 >>>>>> 2010-09-27,10860.03,10902.52,10776.44,10812.04,3587860000,10812.04 >>>>>> >>>>>> .... >>>>>> >>>>>> The dedault implementation not ... >>>>>> >>>>>> $ ./pharo Pharo.image eval >>>>>> "'http://bl.ocks.org/mbostock/raw/4063318/dji.csv' asUrl >>>>>> retrieveContents"==== Startup Error: ConnectionClosed: Connection closed >>>>>> while waiting for data. >>>>>> [ ConnectionClosed signal: 'Connection closed while waiting for data.' ] >>>>>> in Socket>>waitForDataFor: in Block: [ ConnectionClosed signal: >>>>>> 'Connection closed whil...etc... >>>>>> Socket>>waitForDataFor:ifClosed:ifTimedOut: >>>>>> Socket>>waitForDataFor: >>>>>> ZdcSocketStream(ZdcAbstractSocketStream)>>socketWaitForData >>>>>> ZdcSocketStream>>readInto:startingAt:count: >>>>>> ZnUTF8Encoder>>optimizedReadInto:startingAt:count:fromStream: >>>>>> ZnUTF8Encoder>>readInto:startingAt:count:fromStream: >>>>>> [ >>>>>> read := encoder >>>>>> readInto: buffer >>>>>> startingAt: 1 >>>>>> count: buffer size >>>>>> fromStream: readStream ] in ZnStringEntity>>readFrom: in Block: [ ... >>>>>> BlockClosure>>on:do: >>>>>> ZnStringEntity>>readFrom: >>>>>> ZnEntity class>>readFrom:usingType:andLength: >>>>>> ZnEntityReader>>readFrom:usingType:andLength: >>>>>> ZnEntityReader>>readEntityFromStream >>>>>> [ entity := self readEntityFromStream ] in ZnEntityReader>>readEntity in >>>>>> Block: [ entity := self readEntityFromStream ] >>>>>> [ >>>>>> p psValueAt: index put: anObject. >>>>>> aBlock value ] in >>>>>> ZnDefaultCharacterEncoder(DynamicVariable)>>value:during: in Block: [ ... >>>>>> BlockClosure>>ensure: >>>>>> ZnDefaultCharacterEncoder(DynamicVariable)>>value:during: >>>>>> ZnDefaultCharacterEncoder class(DynamicVariable class)>>value:during: >>>>>> ZnEntityReader>>withDefaultUtf8Decoding: >>>>>> ZnEntityReader>>readEntity >>>>>> ZnResponse(ZnMessage)>>readEntityFrom: >>>>>> ZnResponse>>readEntityFrom: >>>>>> ZnResponse(ZnMessage)>>readFrom: >>>>>> ZnResponse class(ZnMessage class)>>readFrom: >>>>>> ZnClient>>readResponse >>>>>> ZnClient>>executeRequestResponse >>>>>> [ self executeRequestResponse ] in ZnClient>>getConnectionAndExecute in >>>>>> Block: [ self executeRequestResponse ] >>>>>> BlockClosure>>ensure: >>>>>> ZnClient>>getConnectionAndExecute >>>>>> ZnClient>>executeWithRedirectsRemaining: >>>>>> Got startup errors: >>>>>> ConnectionClosed: Connection closed while waiting for data. >>>>>> >>>>>> Volkert >>>>>> >>>>>> >>>>>> >>>>>> On 21.09.2015 12:07, Sven Van Caekenberghe wrote: >>>>>>>> On 21 Sep 2015, at 11:45, Andrei Chis <chisvasileand...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> So adding #beOneShot on some networks that are behind proxies, fails >>>>>>>> the request. >>>>>>> Well, I was already afraid that (possibly transparent) proxies were >>>>>>> involved. >>>>>>> >>>>>>> The problem is, it is simply impossible for me to debug this remotely. >>>>>>> >>>>>>> One things that you could try is switching the socket stream >>>>>>> implementation used by Zn, >>>>>>> >>>>>>> ZnNetworkingUtils default socketStreamClass: SocketStream. >>>>>>> >>>>>>> to no longer use ZdcSocketStream. >>>>>>> >>>>>>> Sven >>>>>>> >>>>>>> PS: Note that this is global setting >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> > >
