ExternalSemaphores table may be not well initialized? I can help having a look this afternoon :) On Mon, Feb 17, 2014 at 11:11 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
Hi Pavel,
I just tried on a machine of mine.
I changed testNetwork.st to
Transcript show: (ZnClient new logToTranscript; get: ' http://zn.stfx.eu/zn/numbers.txt'); cr.
That way you get a bit more progress info. As I suspected the request is written and the failure is while reading the response. I tried connecting to a local Zinc server which confirmed this as well: the request comes in on the server and it writes the response.
This is the output now:
root@stfx:~# ./pharo PharoKernel.image testNetwork.st
2014-02-17 10:00:59 463573 I Wrote a ZnRequest(GET /random) 2014-02-17 10:00:59 463573 D Sent headers
User-Agent: Zinc HTTP Components 1.0
Accept: */*
Host: localhost:1701
=============================================================================== Notice: Errors in script loaded from /root/testNetwork.st
=============================================================================== Errors in script loaded from /root/testNetwork.st ==== Startup Error: ConnectionClosed: Connection closed while waiting for data. Socket>>waitForDataFor: in Block: [ ConnectionClosed signal: 'Connection closed whil...etc... Socket>>waitForDataFor:ifClosed:ifTimedOut: Socket>>waitForDataFor: Socket>>receiveDataSignallingTimeout:into:startingAt: SocketStream>>receiveData SocketStream>>next ZnLineReader>>processNext ZnLineReader>>nextLine ZnStatusLine>>readFrom: ZnStatusLine class>>readFrom: ZnResponse>>readHeaderFrom: ZnResponse(ZnMessage)>>readFrom: ZnResponse class(ZnMessage class)>>readFrom: ZnClient>>executeRequestResponse ZnClient>>getConnectionAndExecute in Block: [ self executeRequestResponse ] BlockClosure>>ensure: ZnClient>>getConnectionAndExecute ZnClient>>executeWithRedirectsRemaining: ZnClient>>executeWithRetriesRemaining: in Block: [ self executeWithRedirectsRemaining: self maxNumb...etc... BlockClosure>>on:do: ZnClient>>executeWithRetriesRemaining: ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: self numberOfR...etc... BlockClosure>>on:do: ZnClient>>executeWithTimeout in Block: [ ... ZnClient>>withTimeoutDo: in Block: [ ^ block value ] ZnConnectionTimeout(DynamicVariable)>>value:during: in Block:
You are using regular socket streams, which is good. For now I can't think of a reasons why the reading would fail, if I think of something, I will let you know.
It is pretty hard to debug this way ;-)
Sven
On 17 Feb 2014, at 10:22, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
(NetNameResolver addressForName: 'www.esug.org') returns good value...
-- Pavel
2014-02-17 9:32 GMT+01:00 Pavel Krivanek <pavel.krivanek@gmail.com>: Hi,
thank you for the tip. It seems that it is not directly Zinc related. But if you want something to play with, do:
- load the bootstrapped image:
https://ci.inria.fr/pharo-contribution/view/Pharo-Kernel-3.0/job/PharoKernel...
./pharo PharoKernel.image fix.st ./pharo PharoKernel.image loadNetwork.st ./pharo PharoKernel.image testNetwork.st
The CI slaves revolt now so I cannot make it more comfortable :-)
Cheers, -- Pavel
2014-02-16 22:58 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
Hi Pavel,
On 16 Feb 2014, at 22:23, Pavel Krivanek <pavel.krivanek@gmail.com>
wrote:
Hi Sven,
we can successfully load network packages to the bootstrapped image
but when we try to test it using:
ZnClient new get: 'http://zn.stfx.eu/zn/numbers.txt'.
we get "ConnectionClosed: Connection closed while waiting for data"
error after few seconds. Do you have some idea, what may be wrong? Probably something is not initialized well but I have no clue what.
Cheers, -- Pavel
Hard to say. I would guess that you are already on the point of waiting for a server response, so you already successfully initialised networking, resolved DNS, opened a TCP socket and wrote the request over it. On the other hand, one of those steps might not have been done right, since you get no response.
Any chance of a stack trace ? Or an image ? But that would be a headless one I guess ;-)
Sven