I/O timeout when connecting to server that is not up

[smarterclayton]

Should probably not try to connect for as long as it does (30s?). TCP connection establishment should be shorter in most cases.

[sosiouxme]

Agreed, but there's no central place to configure that timeout...

[smarterclayton]

Actually the default transport can do this for us. Just not sure it's the right place.

[smarterclayton]

@juanvallejo can you close this against something you've done recently?

[juanvallejo]

@sosiouxme

Agreed, but there's no central place to configure that timeout...

Would --request-timeout work in this case?

@smarterclayton A related PR for this would be #12571, however it only ensures that oc project <context_for_server_that_is_down> does not hang / fail, provided that the context name is valid.

Also, I am not able to replicate an I/O timeout that lasts for 30s, using latest master, all of my requests fail almost immediately if the current server is down:

$ kill <server_pid>
$ time oc login ...
error: dial tcp 10.13.137.149:8443: getsockopt: connection refused
oc login --server=https://10.13.137.149:8443 -u system:admin  0.14s user 0.01s system 115% cpu 0.136 total

$ time oc whoami
The connection to the server 10.13.137.149:8443 was refused - did you specify the right host or port?
oc whoami  0.14s user 0.02s system 115% cpu 0.133 total

EDIT: added time

[smarterclayton]

Usually it's from a blackhole'd IP (where a firewall is dropping connection requests to unexposed ports on old IPs). I believe there are good examples out there of replicating this

…

On Mon, Jan 23, 2017 at 10:16 AM, Juan Vallejo ***@***.***> wrote: @sosiouxme <https://github.com/sosiouxme> Agreed, but there's no central place to configure that timeout... Would --request-timeout work in this case? @smarterclayton <https://github.com/smarterclayton> A related PR for this would be #12571 <#12571>, however it only ensures that oc project <context_for_server_that_is_down> does not hang / fail, provided that the context name is valid. Also, I am not able to replicate an I/O timeout that lasts for 30s, using latest master, all of my requests fail almost immediately if the current server is down: $ kill <server_pid> $ oc login ... error: dial tcp 10.13.137.149:8443: getsockopt: connection refused $ oc whoami The connection to the server 10.13.137.149:8443 was refused - did you specify the right host or port? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1766 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABG_p1GWsMX22vsd0tmcvF_0HhapRpI_ks5rVMRWgaJpZM4EB5av> .

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close