You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Kubernetes egress gateways may alter the tcp connect behaviour when the destination port is not open. Instead of a "connection refused" error you can get a normal "connection established" followed by a "connection reset". The reset may be delayed by a few ms or until you try to use that connection.
Similar behaviour is seen with other network infrastructure like VPN software that relays tcp connections.
In the go-ora driver's Session.Connect() function this leads to broken failover. The dialer.DialContext always work (err = nil). But the errors occur later (outside the loop) when the connection is being used. Those later errors then do not retry on other servers.
Could the loop be changed include also the handshake? I imagine the next server should also be tried when the handshake fails or when we get a refuse packet.
Example URL: oracle://user:secret@:0/ORA?server=orahost:1599&server=orahost:1521
where 1599 is not open, but 1521 is open
The sqlx.ConnectContext call returns:
read tcp 100.100.100.100:63910->10.1.2.3:1599: read: connection reset by peer
The text was updated successfully, but these errors were encountered:
Kubernetes egress gateways may alter the tcp connect behaviour when the destination port is not open. Instead of a "connection refused" error you can get a normal "connection established" followed by a "connection reset". The reset may be delayed by a few ms or until you try to use that connection.
Similar behaviour is seen with other network infrastructure like VPN software that relays tcp connections.
In the go-ora driver's Session.Connect() function this leads to broken failover. The dialer.DialContext always work (err = nil). But the errors occur later (outside the loop) when the connection is being used. Those later errors then do not retry on other servers.
Could the loop be changed include also the handshake? I imagine the next server should also be tried when the handshake fails or when we get a refuse packet.
Example URL: oracle://user:secret@:0/ORA?server=orahost:1599&server=orahost:1521
where 1599 is not open, but 1521 is open
The sqlx.ConnectContext call returns:
read tcp 100.100.100.100:63910->10.1.2.3:1599: read: connection reset by peer
The text was updated successfully, but these errors were encountered: