0

Jetty を手動で "java -jar start.jar" を起動してコンソールでアプリを実行すると、Jetty 上の Scala アプリから DB2 に接続すると正常に動作します (1 ～ 2 秒)。ただし、Jetty をサービスとして開始すると、接続の確立に 30 ～ 60 秒かかります。

これは、解決しようとして数日を費やしたものです。

最初に、使用されている iSeries Access ODBC ドライバーと関係があると思いました。私は Javascript で書かれた別のアプリを Node.js 上で実行していますが、これはこの接続で問題なく動作するようです。また、このドライバーが提供するほとんどのオプションを試してみましたが、役に立たなかったようです。次に、問題は JDBC にあると考え、com.ibm.db2.jcc.DB2Jcc を使用しようとしましたが、これで問題が解決されたようには見えませんでした。

接続で何が起こるかを調べるためにロガーを配置しましたが、これは特別な助けにはなりませんでした。どちらの接続も似ているように見えますが、サービスとして実行されている場合は、接続の確立に少なくとも 10 倍の時間がかかります。

DB2 ドライバーが使用中の Activer ディレクトリに対して認証を試みる場合に問題が発生する可能性があると考えたため、ローカル ユーザー「foobar」を作成しました。このユーザー ID をデフォルトとして使用するように iSeries を設定しました。これも役に立ちませんでした。また、自分のユーザー名でサービスを実行しようとしましたが、役に立ちませんでした。

私は現在アイデアがありません。コンソールで Jetty を手動で起動すると、サービス (net start アプリ) として起動する場合とは異なる設定が読み込まれる可能性はありますか?

どんな助けでも大歓迎です！

スタック：

  • 外部サーバー上の DB2。構成するためのアクセス権がありません。
  • iSeries Access ODBC ドライバー、バージョン 9.00.00.00
  • Scala アプリ、Scalatra フレームワーク
  • Jetty 8.1.3 コンテナ
  • Jetty をサービスとしてラップするための NSSM。java.exe (app-directory にコピー) を使用し、オプションは「-jar start.jar」です。
  • Windows 2003 サーバー

接続は DriverManager で簡単に設定できます:

private def foobarDbConnection: Connection = {
  Class.forName(Settings.foobarDbDriver)
  DriverManager.getConnection(Settings.foobarDatabase, 
                              Settings.foobarUsername, 
                              Settings.foobarPassword)
}

設定：

def foobarDbDriver = "com.ibm.db2.jcc.DB2Jcc"
def foobarDatabase = "jdbc:odbc:FOOBAR"
def foobarUsername = "foo"
def foobarPassword = "bar"

接続からのログは次のとおりです。

13.2.2013 13:45:54 com.foo.lib.DbConnectionFactory$JDBCLogWriter write
INFO: DriverManager.getConnection("jdbc:odbc:FOOBAR")

13.2.2013 13:45:54 com.foo.lib.DbConnectionFactory$JDBCLogWriter write
INFO:     trying driver[className=com.ibm.db2.jcc.DB2Driver,com.ibm.db2.jcc.DB2Driver@f6e15e]

13.2.2013 13:45:54 com.foo.lib.DbConnectionFactory$JDBCLogWriter write
INFO:     trying driver[className=sun.jdbc.odbc.JdbcOdbcDriver,sun.jdbc.odbc.JdbcOdbcDriver@e8fdc9]

13.2.2013 13:45:54 com.foo.lib.DbConnectionFactory$JDBCLogWriter write
INFO: *Driver.connect (jdbc:odbc:FOOBAR)

13.2.2013 13:45:54 com.foo.lib.DbConnectionFactory$JDBCLogWriter write
INFO: JDBC to ODBC Bridge: Checking security

13.2.2013 13:45:54 com.foo.lib.DbConnectionFactory$JDBCLogWriter write
INFO: No SecurityManager present, assuming trusted application/applet

13.2.2013 13:45:54 com.foo.lib.DbConnectionFactory$JDBCLogWriter write
INFO: Allocating Environment handle (SQLAllocEnv)

13.2.2013 13:45:54 com.foo.lib.DbConnectionFactory$JDBCLogWriter write
INFO: hEnv=92738208

13.2.2013 13:45:54 com.foo.lib.DbConnectionFactory$JDBCLogWriter write
INFO: Allocating Connection handle (SQLAllocConnect)

13.2.2013 13:45:54 com.foo.lib.DbConnectionFactory$JDBCLogWriter write
INFO: hDbc=92739360

13.2.2013 13:45:54 com.foo.lib.DbConnectionFactory$JDBCLogWriter write
INFO: Connecting (SQLDriverConnect), hDbc=92739360, szConnStrIn=DSN=FOOBAR;UID=foo;PWD=bar
4

1 に答える 1

0

Wireshark を数日間トレースして使用した後、Windows サーバーにローカル ユーザーを追加することで、この問題を解決することができました。この場合、ローカル ユーザーの名前は問題ではありませんでした (DB2 接続で使用されるユーザー名と同じである必要はありませんでした)。ローカル ユーザーが管理者グループに属している場合、問題が解決しないため、このグループなしでローカル ユーザーを作成しました。ドメインまたは管理者グループのユーザーのみが Active Directory によってチェックされているようです。

于 2013-02-25T09:29:41.313 に答える