[unixODBC-support] SQLDriverConnect got stuck

Tamanna Madaan er_tamanna at yahoo.com
Sun Nov 6 06:41:07 GMT 2011


Hello Nick
 
Thanks for your reply. Please clarify the following :
 
1.  From "driver writers" do you mean that I should check on psqlODBC forum ??
 
2. >> It is possible that setting a timeout would allow the app to recover from that point, but it all depends on if the driver supports them.
 
 You mean that setting timeout through SQLSetConnectAttr, SQL_ATTR_CONNECTION_TIMEOUT would work   if psqlODBC support that ??
 
Thanks..
Tamanna 


________________________________
From: Nick Gorham <nick at lurcher.org>
To: Tamanna Madaan <er_tamanna at yahoo.com>; Support for the unixODBC project <unixodbc-support at mailman.unixodbc.org>
Sent: Saturday, November 5, 2011 9:44 PM
Subject: Re: [unixODBC-support] SQLDriverConnect got stuck


On 05/11/2011 15:23, Tamanna Madaan wrote: 
Hi All
> 
>I am using postgres 8.1.2 with unixODBC-2.2.11-2 and psqlodbc-08.03.0200 . I am having a cluster setup. Once it happened that, 
>my application was trying to connect to postgres, which was lying on another system in cluster , and it got stuck after calling 
>SQLDriverConnect function . I took a core of the hung process and the backtrace is as below :
> 
>(gdb) bt
>#0 0xb7f1b410 in ?? ()
>#1 0xb05c4a48 in ?? ()
>#2 0xffffffff in ?? ()
>#3 0x00000001 in ?? ()
>#4 0xb7bd8dc4 in poll () from /lib/tls/libc.so.6
>#5 0xb725c7b4 in SOCK_wait_for_ready (sock=0x8b956b30, output=0, retry_count=1) at socket.c:529
>#6 0xb725ce9a in SOCK_get_next_byte (self=0x8b956b30, peek=0) at socket.c:929
>#7 0xb725d05c in SOCK_get_id (self=0x8b956b30) at socket.c:692
>#8 0xb723844d in CC_connect (self=0x8b961670, password_req=0 '\0', salt_para=0xb05c6130 "") at connection.c:1600
>#9 0xb72459f8 in PGAPI_DriverConnect (hdbc=0x8b961670, hwnd=0x0, szConnStrIn=0xfffffffc <Address 0xfffffffc out of bounds>, cbConnStrIn=50,
>szConnStrOut=0xb05ca790 "", cbConnStrOutMax=4096, pcbConnStrOut=0xb05ca38e, fDriverCompletion=0) at drvconn.c:225
>#10 0xb7270d1f in SQLDriverConnect (hdbc=0x8b961670, hwnd=0xfffffffc, szConnStrIn=0xfffffffc <Address 0xfffffffc out of bounds>, cbConnStrIn=50,
>szConnStrOut=0xfffffffc <Address 0xfffffffc out of bounds>, cbConnStrOutMax=4096, pcbConnStrOut=0xfffffffc, fDriverCompletion=0) at odbcapi.c:225
>#11 0xb7d2aa88 in SQLDriverConnect (hdbc=0x87b67130, hwnd=0x0, conn_str_in=0x892520c "SERVERNAME=172.16.1.1;DSN=abc;DATABASE=abc;UID=abc", len_conn_str_in=50,
>conn_str_out=0xb05ca790 "", conn_str_out_max=4096, ptr_conn_str_out=0xb05ca38e, driver_completion=0) at SQLDriverConnect.c:1155
> 
>After analysing the issue, I found that the system, on which postgres was running, was overloaded. Its CPU usage was almost 100 % and may be thats why it wasn't responding to 
>the  SQLDriverConnect request . Later  on the system (on which postgres was running) was rebooted . Now my questions are  :
> 
>1, why SQLDriverConnect  function call got hung.
>2. Why didn't it simply return with some error code when it wasn't able to connect to postgres ( as it wasnt responding because of system load.)
>3. Why it still didnt return when the system was rebooted ??
>4. What can be done to make SQLDriverConnect function return with error  in case it is not able to connect to postgres for whatsoever reason.
>5. Can connection timeout be set through  SQLSetConnectAttr, SQL_ATTR_CONNECTION_TIMEOUT to make SQLDriverConnect  return after certain amount of time in case there
>is no response from postgres ?? how can this be done ??
>6. Is there any other better way to overcome this issue ??
> 
>Hi,

Its not very helpfull, but in this case I think all the questions are best asked of the driver writers. From the trace, it looks like its waiting on the socket to return some data. It is possible that setting a timeout would allow the app to recover from that point, but it all depends on if the driver supports them.

-- 
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.unixodbc.org/pipermail/unixodbc-support/attachments/20111105/02ab2820/attachment-0001.html>


More information about the unixODBC-support mailing list