#13 closed defect (worksforme)
chicken-install fails with TCP connect timeout
Reported by: | Ivan Raikov | Owned by: | felix winkelmann |
---|---|---|---|
Priority: | critical | Milestone: | 4.9.0 |
Component: | core tools | Version: | 4.6.x |
Keywords: | tcp timeout | Cc: | |
Estimated difficulty: |
Description (last modified by )
The TCP connect timeout error is back! I cannot install nemo under either Linux or Mac OS X. Any help is appreciated.
/bin/chicken/bin/chicken-install nemo resolving alias `kitten-technologies' to: http://chicken.kitten-technologies.co.uk/henrietta.cgi retrieving ... connecting to host "chicken.kitten-technologies.co.uk", port 80 ... requesting "/henrietta.cgi?name=nemo&mode=default" ... reading response ... TCP connect timeout resolving alias `call-cc.org' to: http://code.call-cc.org/cgi-bin/henrietta.cgi connecting to host "code.call-cc.org", port 80 ... requesting "/cgi-bin/henrietta.cgi?name=nemo&mode=default" ... reading response ... TCP connect timeout
Change History (14)
comment:1 follow-up: 2 Changed 16 years ago by
comment:2 follow-up: 3 Changed 16 years ago by
The problem occurs on several identically configured Debian Linux systems with slightly different kernel versions, ranging from 2.6.24 to 2.6.26. Patch r14101 seems to have no influence. I have tried both Chicken 4.0.0, which does not include the patch, and 4.0.1, which does, but I get this error in both cases.
Replying to felix:
Is this system-specific, or does it happen always?
Please try to unapply the commit r14101 and check wether it has any influence.
comment:3 follow-up: 5 Changed 16 years ago by
Replying to iraikov:
The problem occurs on several identically configured Debian Linux systems with slightly different kernel versions, ranging from 2.6.24 to 2.6.26. Patch r14101 seems to have no influence. I have tried both Chicken 4.0.0, which does not include the patch, and 4.0.1, which does, but I get this error in both cases.
Replying to felix:
Is this system-specific, or does it happen always?
Please try to unapply the commit r14101 and check wether it has any influence.
If you comment the call to (close-output-port out)
out does increasing the TCP timeout help? Is this a particularly slow connection?
comment:4 Changed 16 years ago by
Version: | 4.0.0 → 4.0.1 |
---|
comment:5 Changed 16 years ago by
Increasing the tcp-read-timeout to 20000 (20 seconds) allows the installation of sxml-transforms to proceed without problems. The connection is indeed somewhat slow.
Replying to felix:
If you comment the call to
(close-output-port out)
out does increasing the TCP
timeout help? Is this a particularly slow connection?
comment:6 Changed 16 years ago by
Please try r14397. I increased the read/write timeout to 20 secs and close both in- and output ports together at the end.
If this works you can close the ticket.
comment:7 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
It seems to be working now.
comment:8 Changed 14 years ago by
Description: | modified (diff) |
---|---|
Milestone: | → 4.7.0 |
Resolution: | fixed |
Status: | closed → reopened |
Version: | 4.0.1 → 4.6.x |
comment:9 follow-up: 10 Changed 14 years ago by
Does increasing the timeout help, or is this caused by something different?
comment:10 follow-up: 11 Changed 14 years ago by
Yes, increasing the timeout to from 20 to 30 seconds helps with this particular egg. However, shouldn't there be a more robust download procedure that first determines if the egg exists on the particular server, then
tries to fetch it using increasing timeout values?
Replying to felix:
Does increasing the timeout help, or is this caused by something different?
comment:11 Changed 14 years ago by
Replying to iraikov:
Yes, increasing the timeout to from 20 to 30 seconds helps with this particular egg. However, shouldn't there be a more robust download procedure that first determines if the egg exists on the particular server, then
tries to fetch it using increasing timeout values?
To test for the egg being existant, we have to connect, which may timeout. I think there is not much we can do but increase the timeout values or fix your network connection.
I'll increase the timeout to 30 secs, then.
comment:12 Changed 14 years ago by
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
I increased the connection and read/write timeouts to 30 secs (merge into "master","experimental" and "prerelease").
Is this system-specific, or does it happen always?
Please try to unapply the commit r14101 and check wether it has any influence.