Quartz-JDBCJobStoreをSpring、Hibernate、およびWebsphereと一緒に使用する実装では、アンマネージスレッドがスローされているようです。
私はいくつかの読書をしました、そして、SpringでQuartzの使用がそれを引き起こすであろうと述べているIBMからの技術記事を見つけました。彼らは、この問題に対処するためにCommnonJを使用することを提案しています。
私はさらに調査を行いましたが、これまでに見た唯一の例は、データベースにない古いJobStoreを扱っています。
だから、誰かがこの問題の解決策の例を持っているかどうか疑問に思いました。
ありがとう
これには有効な解決策があります (実際には 2 つ)。
1) メイン スケジューラ スレッドに WorkManager デーモン スレッドを使用するように Quartz ソース コードを変更します。動作しますが、クォートを交換する必要があります。ただし、Quartz のハッキングされたバージョンを維持したくなかったので、これは使用しませんでした。（そういえば、これをプロジェクトに提出するつもりだったのですが、完全に忘れていました）
2) Quartz スレッドプールとして使用する WorkManagerThreadPool を作成します。Quartz ThreadPool のインターフェースを実装して、Quartz 内でトリガーされる各タスクが commonj Work オブジェクトにラップされ、WorkManager でスケジュールされるようにします。重要なのは、Java EE スレッド (サーブレットの初期化など) からスケジューラを開始する前に、WorkManagerThreadPool 内の WorkManager を初期化する必要があることです。次に、WorkManagerThreadPool は、新しい Work オブジェクトを作成およびスケジュールすることによって、スケジュールされたすべてのタスクを処理するデーモン スレッドを作成する必要があります。このようにして、スケジューラ (独自のスレッド上) は、タスクをマネージド スレッド (Work デーモン) に渡します。
単純ではありません。残念ながら、すぐにインクルードできるコードがありません。
最後に、これに対する解決策を見つけたので、スレッドに別の回答を追加します。
私の環境：WAS 8.5.5、Quartz 1.8.5、Springなし。
私が抱えていた問題は、（上記の）管理されていないスレッドが から NamingException を引き起こし、ctx.lookup(myJndiUrl)代わりに他のアプリケーションサーバー（JBoss、Weblogic）で正しく動作していたことでした。実際、Webphere は次のメッセージで「インシデント」を発生させていました。
javax.naming.ConfigurationException: サーバー ランタイムが操作のスレッドを J2EE アプリケーション コンポーネントに関連付けることができないため、"java:" 名に対する JNDI 操作を完了できません。この状態は、「java:」名を使用する JNDI クライアントがサーバー アプリケーション要求のスレッドで実行されない場合に発生する可能性があります。J2EE アプリケーションが、静的コード ブロック内またはその J2EE アプリケーションによって作成されたスレッド内の「java:」名に対して JNDI 操作を実行しないようにしてください。このようなコードは、必ずしもサーバー アプリケーション要求のスレッドで実行されるとは限らないため、"java:" 名に対する JNDI 操作ではサポートされません。
次の手順で問題を解決しました。
1) Quartz 1.8.6 にアップグレード (コード変更なし)、maven pom のみ
2) 新しい WorkManagerThreadExecutor を利用可能にするために、次の dep をクラスパス (私の場合は EAR の /lib フォルダー) に追加しました
<dependency>
<groupId>org.quartz-scheduler</groupId>
<artifactId>quartz-commonj</artifactId>
<version>1.8.6</version>
</dependency>
注: QTZ-113または公式の Quartz ドキュメント1.x 2.x では、この修正を有効にする方法については言及されていません。
3) Quartz.properties に以下を追加しました (「wm/default」は、私の WAS 8.5.5 で既に構成されている DefaultWorkManager の JNDI でした。WAS コンソールの [Resources] -> [AsynchronousBeans] -> [WorkManagers]を参照してください):
org.quartz.threadExecutor.class=org.quartz.custom.WorkManagerThreadExecutor
org.quartz.threadExecutor.workManagerName=wm/default
注: 右のクラスはorg.quartz です。Quartz -scheduler-1.8.6 (テスト済み)、またはorg.quartz のカスタム.WorkManagerThreadExecutor 。commonj .WorkManagerThreadExecutor 2.1.1以降(テストされていませんが、 maven のリポジトリにある実際の Quartz-commonj の jar内で検証されています)
4) Quartzジョブの空のコンストラクターに JNDI ルックアップを 移動しました( m_klovre の「J2EE コンテナーの外側のスレッド」のおかげです)。つまり、コンストラクターは、アプリケーションのまったく同じ J2EE コンテキストからリフレクション (メソッド) によって呼び出され、名前空間にnewInstance()アクセスできましたが、メソッドは、アプリケーションの EJB がすべて欠落している、より貧弱なコンテキストで実行されていました。java:globalexecute(JobExecutionContext)
お役に立てれば。
Ps。参考までに、上記で使用した Quartz.properties ファイルの例をここで見つけることができます
この記事をチェックしてください: http://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_alcott.html
基本的には、SchedulerFactoryBean の taskExecutor プロパティを設定して、コンテナー管理スレッドを使用する org.springframework.scheduling.commonj.WorkManager TaskExecutor を使用します。
注意: 上記の QUARTZ-708 のリンクは無効になりました。この新しい問題 (新しいJira 内)は問題に対処しているようです: http://jira.terracotta.org/jira/browse/QTZ-113 (fixVersion = 1.8.6, 2.0.2)
これに関しては、以下の JIRA リンクが Quartz で提起されていることを確認できます。
http://jira.opensymphony.com/browse/QUARTZ-708
これには、必要な WebSphereThreadPool 実装が含まれており、前述のように、要件を満たすために Quartz.properties の変更とともに使用できます。お役に立てれば。
よろしく、シヴァ
Websphere のマネージド スレッド プールを使用する必要があります。これは、spring と commonj を介して行うことができます。CommonJ には、マネージド スレッドを作成するタスク エグゼキューターを含めることができます。jndi マネージド スレッド リソースへの参照を使用することもできます。その後、commonj タスク エグゼキュータを Spring ベースの Quartz SchedulerFactoryBean に挿入できます。
詳細については、 http: //open.bekk.no/boss/spring-scheduling-in-websphere/ を参照し、「Quartz with CommonJ」セクションまでスクロールしてください。
WAS85 ans Quartz 1.8.6 に対する PaoloC からの提案は、WAS80 (および Quartz 1.8.6) でも動作し、Spring は必要ありません。(私のセットアップでは Spring 2.5.5 が存在しますが、そのコンテキストでは使用されていません。)
こうすることで、独自のバリアントで SimpleJobFactory をオーバーライドし、InjectionHelper を使用して新しく作成されたすべてのジョブに CDI を適用することができました。インジェクションは、@EJB (アノテーション付き EJB リモート ビジネス インターフェースの JNDI ルックアップを使用) と @Inject (最初に新しい InitialContext を使用して CDI BeanManager の JNDI ルックアップを使用し、次にこの新しくフェッチされた BM を使用して CDI Bean 自体をルックアップする) の両方で機能します。
その答えをありがとうPaoloC！(このテキストがメイントピックへの回答としてではなく、「PaoloC への回答」として表示されることを願っています。これらを区別する方法は見つかりませんでした。)