thda
DB Connection Stuck during Login
We have an application that occasionally stuck and the stack trace shows that it goes into this branch and eventually at stuck at a network read in go runtime code. https://github.com/thda/tds/blob/master/buffer.go#L202
May I know the intention of this readPkt call after EOF encountered?
We don't have any timeout params set as part of the conn string, so from the code, it looks like it is going to take defaultLoginTimeout = 20, which is in seconds. but it doesn't look like this timeout is kicking in for us either. The process is stuck for at least 2 hours - very likely at the exact same place.
From our investigation, we can see from the host netstat output that the connection is in ESTABLISHED state and from the Sybase Text Report that the DB server agrees with that.
I will try to post the stack trace, but it is a bit challenging to get it out from firm network. It is essentially coming from newSession(...) in session.go, then login(...), then initState(...)
Hi,
thanks for reporting. May I know the server version and the version of this driver you are using ? I've fixed an issue like that recently, could you make sure you are using master ? If it's not fixed on master I'll work on adding debug information.
Sure, I will try master. Can you point me to the commit fix SHA if it is easy to locate?
The problem is I have no way to reliably reproduce it, so I will probably just have to roll it out and wait for it to happen (or wait forever :)).
Thanks!
On 30 Oct 2020, at 18:31, Thomas [email protected] wrote:
Hi,
thanks for reporting. May I know the server version and the version of this driver you are using ? I've fixed an issue like that recently, could you make sure you are using master ? If it's not fixed on master I'll work on adding debug information.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/thda/tds/issues/22#issuecomment-719473712, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAY5MXHU6R32TM6H5YSJBPLSNKIXFANCNFSM4SZXKEUA.
commit f49ccc10e14d45d1a58d2767d24258ff467b9c89 was the last change of the login procedure to handle ASE 16 password. I think I still should find a better way to respect login timeout. I'll try to handle it more gracefully.
Thanks for your help! btw the server is ASE 15.7. Anything more specific you want to know?