Strange 'Connection closed while waiting for data.' Zinc error
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
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" <pharo-users-bounces@lists.pharo.org on behalf of yuriy.tymchuk@me.com> 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
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 <aglynn42@gmail.com> 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" <pharo-users-bounces@lists.pharo.org on behalf of yuriy.tymchuk@me.com> 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
On 25 Dec 2017, at 18:03, Yuriy Tymchuk <yuriy.tymchuk@me.com> 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 <aglynn42@gmail.com> 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" <pharo-users-bounces@lists.pharo.org on behalf of yuriy.tymchuk@me.com> 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
Hi Sven, No, Iâm on Mac (OS 10.13). Cheers. Uko
On 25 Dec 2017, at 20:03, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 25 Dec 2017, at 18:03, Yuriy Tymchuk <yuriy.tymchuk@me.com> 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 <aglynn42@gmail.com> 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" <pharo-users-bounces@lists.pharo.org on behalf of yuriy.tymchuk@me.com> 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
On 26 Dec 2017, at 08:21, Yuriy Tymchuk <yuriy.tymchuk@me.com> 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 <sven@stfx.eu> wrote:
On 25 Dec 2017, at 18:03, Yuriy Tymchuk <yuriy.tymchuk@me.com> 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 <aglynn42@gmail.com> 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" <pharo-users-bounces@lists.pharo.org on behalf of yuriy.tymchuk@me.com> 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
participants (3)
-
Andrew Glynn -
Sven Van Caekenberghe -
Yuriy Tymchuk