2017-05-11 9 views
0

RHEL7ホストで実行されているluaスクリプトがあります。これは、FreeBSD/unixODBC)、値を取得します。ただし、ターゲットサーバーがオフライン/使用できない場合、最終的に何かがタイムアウトしてエラーが返されるまで(約6分20秒間)ハングします。このタイムアウトを数秒にまで短縮したいのですが...FreeTDSとunixODBCを使用してluaスクリプトからMS SQL Serverデータベースに接続するときに接続タイムアウトを設定する

これは簡単なことですが、 SQLサーバー。

/etc/freetds.conf(下記参照)にタイムアウト設定がありますが、これは効果がないようです。

通常、このスクリプトはnginx(openresty)から呼び出されますが、これはタイムアウトを低く抑えたい主な理由ですが、スクリプトの実行と同じハング/タイムアウト動作が観察されます。

誰も私がこれを解決するのを手助けできますか?私は以下の関連する設定ファイルの内容とスクリプトを含んでいます。

UPDATE: 私は、テストスクリプトを同じサブネットの外にある未使用のIPアドレスで指し示すと、SQL Server接続を試行したときのタイムアウトは約6分21秒です前述したように)。私は同じサブネット内の未使用のIPアドレスを指しても、私のタイムアウトは一貫して約9秒です。私はネットワーキングのエキスパートではありませんが、ここで実際に見ている2つのタイムアウトはネットワーク/トランスポート層の影響を受けていることを示唆しています - おそらく私のローカルネットワークスイッチはパケットを未知のサブネットにドロップしていますか?

これは...私の元の問題を解決するが、それはアップデートとして言及する価値があったと思っていません

getvalue.lua:

local odbc = require "odbc" 
local keyvalue = "some_value" 
local retval = "" 

CNN_DRV = { 
     {Driver='{FreeTDS}'}; 
     {Server='10.10.60.100,1433'}; 
     {Database='databasename'}; 
     {Uid='sqlusername'}; 
     {Pwd='sqlpassword'}; 
}; 

dbassert = odbc.assert 
env,err = odbc.environment() 
local cnn, err = env:driverconnect(CNN_DRV) 
stmt,err = cnn:prepare("{?= call dbo.GetRetValForKeyValue(?)}") 
ret = stmt:vbind_param_ulong(1, ret, odbc.PARAM_OUTPUT) 
val = stmt:vbind_param_char(2, keyvalue) 
dbassert(stmt:execute()) 

stmt:foreach(function(f1) 
     if tonumber(f1) 
       then 
       retval = string.format("%d", f1) 
       else 
       retval = '' 
     end 
end 
) 

print(retval) 

/etc/odbcinst.ini:

[FreeTDS] 
Description = FreeTDS TDS driver (for Sybase/MS SQL) 
Driver = /usr/lib64/libtdsodbc.so.0 
Setup = /usr/lib64/libtdsS.so.2 

/etc/freetds.conf:

# Global settings are overridden by those in a database 
# server specific section 
[global] 
     # TDS protocol version 
;  tds version = 4.2 

     # Whether to write a TDSDUMP file for diagnostic purposes 
     # (setting this to /tmp is insecure on a multi-user system) 
;  dump file = /tmp/freetds.log 
;  debug flags = 0xffff 

     # Command and connection timeouts 
;  timeout = 10 
;  connect timeout = 10 

     # If you get out-of-memory errors, it may mean that your client 
     # is trying to allocate a huge buffer for a TEXT field. 
     # Try setting 'text size' to a more reasonable limit 
     text size = 64512 

答えて

0

接続する前に接続オブジェクトにSQL_ATTR_LOGIN_TIMEOUTを設定してみることができます。

のログイン要求がアプリケーションに返されるまでに待機する秒数に対応するSQLUINTEGER値。 デフォルトはドライバに依存します。 ValuePtrが0の場合、タイムアウトは であり、接続試行は無期限に待機します。

local env, err = odbc.environment() 
local cnn = env:connection() 
cnn:setlogintimeout(10) 
local ok, err = cnn:driverconnect(CNN_DRV) 

更新

もありSQL_ATTR_CONNECTION_TIMEOUT存在する属性(ただし、ODBC 3.0の場合)

上の任意の要求を を待機する秒数に対応するSQLUINTEGER値接続を完了してから アプリケーションに戻ります。クエリの実行またはログインに関連する に関連付けられていない状況でタイムアウトする可能性がある場合、ドライバはSQLSTATE HYT00(タイムアウト期限切れ) を返す必要があります。

ValuePtrが0(デフォルト)の場合、タイムアウトはありません。

私はそれを公開しませんが、これを試すことができます。 (ヘッダーファイルのSQL_ATTR_CONNECTION_TIMEOUTのチェックアウト値も可能です)。

local SQL_ATTR_CONNECTION_TIMEOUT = 113 
cnn:setuintattr(SQL_ATTR_CONNECTION_TIMEOUT, 10) 
+0

私はこれを試してみましたが、残念ながらこれは違いはありません。しかし、さらにテストする中で、ターゲットIPアドレスによってタイムアウトが異なることがわかりました。元の投稿に詳細を追加します。 – verticallyg

+0

SQL_ATTR_CONNECTION_TIMEOUT属性の応答を更新します。 – moteus

+0

フォローアップの提案私のODBCバージョン(unixODBC)はわずか2.3.1ですが、これは幸運なこともなくこの試みも試みました。使用可能な最新バージョンは2.3.4と表示されます。私はアップグレードするべきですか? – verticallyg

関連する問題