Re: [Pharo-users] Strange 'Connection closed while waiting for data.' Zinc error

[Christopher Fuhrman]

Hi - I'm resurrecting an old question

I found on forum.world.st (sorry for the formatting)

Dec 26, 2017; 10:14am Sven wrote:

> > On 26 Dec 2017, at 08:21, Yuriy Tymchuk wrote:
> >
> > Hi Sven,
> >
> > No, I’m on Mac (OS 10.13).
> That is not good then, Uko, but again, there is no way to start debugging
> this without a reliable test case that I can run too.
>

I hit this today while testing on localhost: a PlantUML server.

I think I can give you a simple(ish) way to recreate:

   - clone the repo at  https://github.com/plantuml/plantuml-server
   - install Java
   - install maven
   - In the clone directory, run:
   *mvn jetty:run*

In Pharo, it's just:

ZnEasy getPng: 'http://localhost:8080/plantuml/img/IzIrIm80'.

Cheers,
Christopher
p.s. the workaround with *ZnNetworkingUtils default socketStreamClass:
SocketStream.* is OK for me. I'm running Pharo 8 on Windows 10 (WSL) and
the server's running on the Windows part.

Sven
> > Cheers.
> > Uko

Re: [Pharo-users] Strange 'Connection closed while waiting for data.' Zinc error

[Sven Van Caekenberghe]

> On 26 Dec 2017, at 08:21, Yuriy Tymchuk  wrote:
> 
> Hi Sven,
> 
> No, I’m on Mac (OS 10.13).

That is not good then, Uko, but again, there is no way to start debugging this 
without a reliable test case that I can run too.

Sven

> Cheers.
> Uko
> 
>> On 25 Dec 2017, at 20:03, Sven Van Caekenberghe  wrote:
>> 
>> 
>> 
>>> On 25 Dec 2017, at 18:03, Yuriy Tymchuk  wrote:
>>> 
>>> Hi,
>>> 
>>> setting the reuse timeout to 0 or making a one shot client does not help. 
>>> But while googling I found the exact issue described on the Pharo issue 
>>> tracker: https://pharo.fogbugz.com/f/cases/18588/
>>> 
>>> The proposed workaround also worked for me:
>>> ZnNetworkingUtils default socketStreamClass: SocketStream.
>> 
>> You are on Windows I guess ?
>> 
>>> Cheers,
>>> Uko
>>> 
 On 25 Dec 2017, at 05:42, Andrew Glynn  wrote:
 
 The only time I've seen that behaviour is with the combination of a slow 
 server and a proxy such as CloudFlare where the sysadmin has set tcp_wait 
 to some ridiculously small number.  Have you tried setting the connection 
 reuse timeout to 0, or setting 'beOneShot'?
 
 Zinc doesn't support the additions in HTTP/2, but I can't offhand think of 
 any reason that should cause that specific behaviour. I've had sufficient 
 problems with HTTP/2 over slow connections (I live where there are no land 
 lines of any kind) that I replaced the HTTP/2 code in Nginx with code from 
 pureftpd in order to access my server at home when I'm out.
 
 Andrew
 
 On 2017-12-24, 3:30 PM, "Pharo-users on behalf of Yuriy Tymchuk" 
  
 wrote:
 
 Hi,
 
 I’m trying to hack something with Pharo 6.1 and Phillips Hue[1] (they have 
 a simple REST API). When I try to do a GET request with Zinc like this:
 
 ZnClient new
url: 
 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/';
get
 
 I get a “ConnectionClosed: Connection closed while waiting for data” 
 exception. The service provides a JSON response that I can get without a 
 problem by using a web browser or curl. Also if I try to access fewer data 
 (e.g. adding /1 to the url, so it gets only one resource) I don’t get the 
 exception.
 
 What is even more strange, when I resume the exception I get the desired 
 response i.e. this works:
 
 [ ZnClient new
url: 
 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/';
get ]
 
on: ConnectionClosed
do: [ :ex |
ex resumeUnchecked: ex defaultResumeValue ]
 
 Of course I cannot share the server that is on my local network for 
 resting, but maybe anyone knows it there are any known issues with Zinc, 
 or if there are ways for me to debug the issue further.
 
 Cheers.
 Uko
 
 [1]: https://www.developers.meethue.com
 
 
 
 
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-users] Strange 'Connection closed while waiting for data.' Zinc error

[Yuriy Tymchuk]

Hi Sven,

No, I’m on Mac (OS 10.13).

Cheers.
Uko

> On 25 Dec 2017, at 20:03, Sven Van Caekenberghe  wrote:
> 
> 
> 
>> On 25 Dec 2017, at 18:03, Yuriy Tymchuk  wrote:
>> 
>> Hi,
>> 
>> setting the reuse timeout to 0 or making a one shot client does not help. 
>> But while googling I found the exact issue described on the Pharo issue 
>> tracker: https://pharo.fogbugz.com/f/cases/18588/
>> 
>> The proposed workaround also worked for me:
>> ZnNetworkingUtils default socketStreamClass: SocketStream.
> 
> You are on Windows I guess ?
> 
>> Cheers,
>> Uko
>> 
>>> On 25 Dec 2017, at 05:42, Andrew Glynn  wrote:
>>> 
>>> The only time I've seen that behaviour is with the combination of a slow 
>>> server and a proxy such as CloudFlare where the sysadmin has set tcp_wait 
>>> to some ridiculously small number.  Have you tried setting the connection 
>>> reuse timeout to 0, or setting 'beOneShot'?
>>> 
>>> Zinc doesn't support the additions in HTTP/2, but I can't offhand think of 
>>> any reason that should cause that specific behaviour. I've had sufficient 
>>> problems with HTTP/2 over slow connections (I live where there are no land 
>>> lines of any kind) that I replaced the HTTP/2 code in Nginx with code from 
>>> pureftpd in order to access my server at home when I'm out.
>>> 
>>> Andrew
>>> 
>>> On 2017-12-24, 3:30 PM, "Pharo-users on behalf of Yuriy Tymchuk" 
>>>  
>>> wrote:
>>> 
>>>  Hi,
>>> 
>>>  I’m trying to hack something with Pharo 6.1 and Phillips Hue[1] (they have 
>>> a simple REST API). When I try to do a GET request with Zinc like this:
>>> 
>>>  ZnClient new
>>> url: 
>>> 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/';
>>> get
>>> 
>>>  I get a “ConnectionClosed: Connection closed while waiting for data” 
>>> exception. The service provides a JSON response that I can get without a 
>>> problem by using a web browser or curl. Also if I try to access fewer data 
>>> (e.g. adding /1 to the url, so it gets only one resource) I don’t get the 
>>> exception.
>>> 
>>>  What is even more strange, when I resume the exception I get the desired 
>>> response i.e. this works:
>>> 
>>>  [ ZnClient new
>>> url: 
>>> 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/';
>>> get ]
>>> 
>>> on: ConnectionClosed
>>> do: [ :ex |
>>> ex resumeUnchecked: ex defaultResumeValue ]
>>> 
>>>  Of course I cannot share the server that is on my local network for 
>>> resting, but maybe anyone knows it there are any known issues with Zinc, or 
>>> if there are ways for me to debug the issue further.
>>> 
>>>  Cheers.
>>>  Uko
>>> 
>>>  [1]: https://www.developers.meethue.com
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-users] Strange 'Connection closed while waiting for data.' Zinc error

[Sven Van Caekenberghe]

> On 25 Dec 2017, at 18:03, Yuriy Tymchuk  wrote:
> 
> Hi,
> 
> setting the reuse timeout to 0 or making a one shot client does not help. But 
> while googling I found the exact issue described on the Pharo issue tracker: 
> https://pharo.fogbugz.com/f/cases/18588/
> 
> The proposed workaround also worked for me:
> ZnNetworkingUtils default socketStreamClass: SocketStream.

You are on Windows I guess ?

> Cheers,
> Uko
> 
>> On 25 Dec 2017, at 05:42, Andrew Glynn  wrote:
>> 
>> The only time I've seen that behaviour is with the combination of a slow 
>> server and a proxy such as CloudFlare where the sysadmin has set tcp_wait to 
>> some ridiculously small number.  Have you tried setting the connection reuse 
>> timeout to 0, or setting 'beOneShot'?
>> 
>> Zinc doesn't support the additions in HTTP/2, but I can't offhand think of 
>> any reason that should cause that specific behaviour. I've had sufficient 
>> problems with HTTP/2 over slow connections (I live where there are no land 
>> lines of any kind) that I replaced the HTTP/2 code in Nginx with code from 
>> pureftpd in order to access my server at home when I'm out.
>> 
>> Andrew
>> 
>> On 2017-12-24, 3:30 PM, "Pharo-users on behalf of Yuriy Tymchuk" 
>>  
>> wrote:
>> 
>>   Hi,
>> 
>>   I’m trying to hack something with Pharo 6.1 and Phillips Hue[1] (they have 
>> a simple REST API). When I try to do a GET request with Zinc like this:
>> 
>>   ZnClient new
>>  url: 
>> 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/';
>>  get
>> 
>>   I get a “ConnectionClosed: Connection closed while waiting for data” 
>> exception. The service provides a JSON response that I can get without a 
>> problem by using a web browser or curl. Also if I try to access fewer data 
>> (e.g. adding /1 to the url, so it gets only one resource) I don’t get the 
>> exception.
>> 
>>   What is even more strange, when I resume the exception I get the desired 
>> response i.e. this works:
>> 
>>   [ ZnClient new
>>  url: 
>> 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/';
>>  get ]
>> 
>>  on: ConnectionClosed
>>  do: [ :ex |
>>  ex resumeUnchecked: ex defaultResumeValue ]
>> 
>>   Of course I cannot share the server that is on my local network for 
>> resting, but maybe anyone knows it there are any known issues with Zinc, or 
>> if there are ways for me to debug the issue further.
>> 
>>   Cheers.
>>   Uko
>> 
>>   [1]: https://www.developers.meethue.com
>> 
>> 
>> 
>> 
> 
> 

Re: [Pharo-users] Strange 'Connection closed while waiting for data.' Zinc error

[Yuriy Tymchuk]

Hi,

setting the reuse timeout to 0 or making a one shot client does not help. But 
while googling I found the exact issue described on the Pharo issue tracker: 
https://pharo.fogbugz.com/f/cases/18588/

The proposed workaround also worked for me:
ZnNetworkingUtils default socketStreamClass: SocketStream.

Cheers,
Uko

> On 25 Dec 2017, at 05:42, Andrew Glynn  wrote:
> 
> The only time I've seen that behaviour is with the combination of a slow 
> server and a proxy such as CloudFlare where the sysadmin has set tcp_wait to 
> some ridiculously small number.  Have you tried setting the connection reuse 
> timeout to 0, or setting 'beOneShot'?
> 
> Zinc doesn't support the additions in HTTP/2, but I can't offhand think of 
> any reason that should cause that specific behaviour. I've had sufficient 
> problems with HTTP/2 over slow connections (I live where there are no land 
> lines of any kind) that I replaced the HTTP/2 code in Nginx with code from 
> pureftpd in order to access my server at home when I'm out.
> 
> Andrew
> 
> On 2017-12-24, 3:30 PM, "Pharo-users on behalf of Yuriy Tymchuk" 
>  wrote:
> 
>Hi,
> 
>I’m trying to hack something with Pharo 6.1 and Phillips Hue[1] (they have 
> a simple REST API). When I try to do a GET request with Zinc like this:
> 
>ZnClient new
>   url: 
> 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/';
>   get
> 
>I get a “ConnectionClosed: Connection closed while waiting for data” 
> exception. The service provides a JSON response that I can get without a 
> problem by using a web browser or curl. Also if I try to access fewer data 
> (e.g. adding /1 to the url, so it gets only one resource) I don’t get the 
> exception.
> 
>What is even more strange, when I resume the exception I get the desired 
> response i.e. this works:
> 
>[ ZnClient new
>   url: 
> 'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/';
>   get ]
> 
>   on: ConnectionClosed
>   do: [ :ex |
>   ex resumeUnchecked: ex defaultResumeValue ]
> 
>Of course I cannot share the server that is on my local network for 
> resting, but maybe anyone knows it there are any known issues with Zinc, or 
> if there are ways for me to debug the issue further.
> 
>Cheers.
>Uko
> 
>[1]: https://www.developers.meethue.com
> 
> 
> 
> 

Re: [Pharo-users] Strange 'Connection closed while waiting for data.' Zinc error

[Andrew Glynn]

The only time I've seen that behaviour is with the combination of a slow server 
and a proxy such as CloudFlare where the sysadmin has set tcp_wait to some 
ridiculously small number.  Have you tried setting the connection reuse timeout 
to 0, or setting 'beOneShot'?

Zinc doesn't support the additions in HTTP/2, but I can't offhand think of any 
reason that should cause that specific behaviour. I've had sufficient problems 
with HTTP/2 over slow connections (I live where there are no land lines of any 
kind) that I replaced the HTTP/2 code in Nginx with code from pureftpd in order 
to access my server at home when I'm out.

Andrew

On 2017-12-24, 3:30 PM, "Pharo-users on behalf of Yuriy Tymchuk" 
 wrote:

Hi,

I’m trying to hack something with Pharo 6.1 and Phillips Hue[1] (they have 
a simple REST API). When I try to do a GET request with Zinc like this:

ZnClient new
url: 
'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/';
get

I get a “ConnectionClosed: Connection closed while waiting for data” 
exception. The service provides a JSON response that I can get without a 
problem by using a web browser or curl. Also if I try to access fewer data 
(e.g. adding /1 to the url, so it gets only one resource) I don’t get the 
exception.

What is even more strange, when I resume the exception I get the desired 
response i.e. this works:

[ ZnClient new
url: 
'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/';
get ]

on: ConnectionClosed
do: [ :ex |
ex resumeUnchecked: ex defaultResumeValue ]

Of course I cannot share the server that is on my local network for 
resting, but maybe anyone knows it there are any known issues with Zinc, or if 
there are ways for me to debug the issue further.

Cheers.
Uko

[1]: https://www.developers.meethue.com

[Pharo-users] Strange 'Connection closed while waiting for data.' Zinc error

[Yuriy Tymchuk]

Hi,

I’m trying to hack something with Pharo 6.1 and Phillips Hue[1] (they have a 
simple REST API). When I try to do a GET request with Zinc like this:

ZnClient new
url: 
'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/';
get

I get a “ConnectionClosed: Connection closed while waiting for data” exception. 
The service provides a JSON response that I can get without a problem by using 
a web browser or curl. Also if I try to access fewer data (e.g. adding /1 to 
the url, so it gets only one resource) I don’t get the exception.

What is even more strange, when I resume the exception I get the desired 
response i.e. this works:

[ ZnClient new
url: 
'http://192.168.0.115:80/api/1028d66426293e821ecfd9ef1a0731df/lights/';
get ]

on: ConnectionClosed
do: [ :ex |
ex resumeUnchecked: ex defaultResumeValue ]

Of course I cannot share the server that is on my local network for resting, 
but maybe anyone knows it there are any known issues with Zinc, or if there are 
ways for me to debug the issue further.

Cheers.
Uko

[1]: https://www.developers.meethue.com