Unmanaged Themen Frühling Quartz Websphere Hibernate

Question

Es scheint, dass unsere Implementierung der Verwendung von Quarz - JDBCJobStore zusammen mit Spring, Hibernate und Websphere nicht verwalteten Threads wirft.

Ich habe einige Lesung getan und einen Tech-Artikel von IBM gefunden besagt, dass die Verwendung von Quarz mit Frühling wird, dass verursachen. Sie machen den Vorschlag CommnonJ die Verwendung dieses Problem zu beheben.

Ich habe einige weitere Forschung und die einzigen Beispiele getan, was ich bisher alle befassen sich mit dem Plan alten JobStore gesehen haben, die nicht in einer Datenbank ist.

Also, ich habe mich gefragt, ob jemand ein Beispiel für die Lösung für dieses Problem hat.

Danke

Answer 1

Wir haben eine funktionierende Lösung für diese (zwei tatsächlich).

1) Änderung des Quarz Quellcode einen Work Dämon-Thread für den Haupt-Scheduler-Thread zu bedienen. Es funktioniert, aber erfordert Veränderung Quart. Wir haben Sie mit diesem aber nicht, da wir nicht eine gehackte Version von Quarz halten wollte. (Das erinnert mich, ich würde dies das Projekt einzureichen, aber ganz vergessen)

2) eine WorkManagerThreadPool erstellen als Quarz Threadpool verwendet werden. Implementieren Sie die Schnittstelle für den Quarzthreadpool, so dass jede Aufgabe, die in Quarz ausgelöst wird in einem commonj Arbeits Gegenstand gewickelt wird, die dann in der Work geplant werden. Der Schlüssel ist, dass die Workmanager im WorkManagerThreadPool initialisiert werden muss, bevor der Scheduler gestartet wird, von einem Java EE-Thread (wie Servlet-Initialisierung). Der WorkManagerThreadPool muss dann einen Dämon-Thread erstellen, die alle geplanten Aufgaben behandelt durch die Schaffung und die neuen Arbeits Objekte planen. Auf diese Weise, der Scheduler (auf einem eigenen Thread) ist, um die Aufgaben zu einem verwalteten Thread vorbei (der Arbeits Daemon).

Nicht einfach, und ich habe leider keinen Code leicht verfügbar sind.

Answer 2

Hinzufügen eine weitere Antwort auf den Thread, da ich eine Lösung gefunden, endlich.

Meine Umwelt :. WS 8.5.5, 1.8.5 Quarz, kein Frühling

Das Problem ich hatte, war der (oben) nicht verwalteten Thread eine NamingException von ctx.lookup(myJndiUrl) verursacht, dass anstelle richtig in anderen Anwendungsserver (JBoss, Weblogic) arbeiten; eigentlich einen „Vorfall“ mit der folgenden Meldung Webpshere feuert:

  

javax.naming.ConfigurationException: Ein JNDI Betrieb auf einem „java:“ Name kann nicht abgeschlossen werden, da der Server-Laufzeit nicht in der Lage ist, den Betrieb des Threads mit jedem J2EE-Anwendungskomponente zu verknüpfen. Diese Bedingung kann auftreten, wenn das JNDI-Client der Verwendung von „java:“ Name auf dem Gewinde einer Server-Anwendung Anforderung nicht ausgeführt wird. Stellen Sie sicher, dass eine J2EE-Anwendung keine JNDI-Operationen auf „java:“ execute Namen in statischen Code-Blöcke oder in Threads erstellt von dieser J2EE-Anwendung. Ein solcher Code ist auf dem Gewinde einer Server-Anwendung Anforderung nicht unbedingt ausgeführt werden und daher von JNDI Operationen an wird nicht unterstützt „java:“. Namen

Die folgenden Schritte das Problem gelöst:

1) ein Upgrade auf Quarz 1.8.6 (keine Code-Änderungen), nur Maven pom

2) addierte folgende dep zu Classpath (in meinem Fall, EAR / lib-Ordner), den neuen WorkManagerThreadExecutor verfügbar

zu machen

<dependency>
  <groupId>org.quartz-scheduler</groupId>
  <artifactId>quartz-commonj</artifactId>
  <version>1.8.6</version>
</dependency>

Hinweis: in QTZ-113 oder der offiziellen Quarz-Dokumentation 1.x 2.x gibt es keinen Hinweis, wie Sie dieses Update aktivieren.

3) hinzugefügt folgendes quartz.properties ( "wm / default" wurde der JNDI der bereits konfigurierten DefaultWorkManager in meinem WAS 8.5.5 finden Sie unter Ressourcen -> AsynchronousBeans -> WorkManagers in WS-Konsole):

org.quartz.threadExecutor.class=org.quartz.custom.WorkManagerThreadExecutor
org.quartz.threadExecutor.workManagerName=wm/default

Hinweis: Recht Klasse ist org.quartz benutzerdefinierte .WorkManagerThreadExecutor für Quarz-Scheduler-1.8.6 (getestet), oder org.quartz <.. strong> commonj .WorkManagerThreadExecutor 2.1.1 auf (nicht getestet, aber innerhalb tatsächlichen Quarz-commonj der Gläser auf maven repos )

4) bewegt, um die JNDI-Suche in den leeren Konstruktor des Quarz Job (dank m_klovre der "Thread außerhalb des J2EE-Container" ?); das heißt, wurde der Konstruktor durch Reflexion (newInstance() Methode) aufgerufen aus dem gleichen J2EE Rahmen meiner Anwendung ist, und hatte Zugang zu java:global Namensraum, während die execute(JobExecutionContext) Verfahren noch in einem schlechteren Kontext ausgeführt wird, die alle meiner Anwendung fehlte EJBs

Hope, das hilft.

Ps. als Referenz, können Sie hier ein Beispiel für die quartz.properties Datei war ich mit oben finden

Answer 3

Überprüfen Sie diesen Artikel: http://www.ibm.com/developerworks/websphere/techjournal/ 0609_alcott / 0609_alcott.html

im Grunde, stellen Sie die taskExecutor Eigenschaft auf SchedulerFactoryBean einen org.springframework.scheduling.commonj.WorkManager TaskExecutor zu verwenden, die Container verwaltete Threads verwenden.

Answer 4

Nur eine Anmerkung: die oben QUARTZ-708 der Link ist nicht mehr gültig. Diese neue Ausgabe (in einem neuen Jira) scheint , um das Problem zu sein Adressierung:

Sie können prüfen, die unter JIRA Link auf Quarz bezüglich dieser angehoben.

http://jira.opensymphony.com/browse/QUARTZ-708

Dies hat die erforderliche WebSphereThreadPool Implementierung, die mit den Veränderungen in quartz.properties verwendet werden kann, wie Ihre Anforderungen gerecht zu werden erwähnt. Hoffe, das hilft.

Viele Grüße, Siva

Sie müssen websphere des verwalteten Thread-Pools verwenden. Sie können über Frühling und commonj tun. CommonJ kann, hat eine Aufgabe Testamentsvollstrecker, die verwalteten Threads erstellen wird. Sie können sogar einen Verweis auf eine jndi verwalteten Thread-Ressource verwenden. Sie können dann die commonj Aufgabe Testamentsvollstrecker in den Quarz-SchedulerFactoryBean basierend Frühling injizieren.

Bitte finden Sie unter http://open.bekk.no/boss/spring -scheduling-in-websphere / und navigieren Sie zu "Quartz mit CommonJ" Abschnitt für weitere Details.

Der Vorschlag von PaoloC für WAS85 ans Quarz 1.8.6 funktioniert auch auf WAS80 (und Quartz 1.8.6) und die Feder nicht braucht. (In meinem Setup Frühling 2.5.5 vorhanden ist, aber nicht in Gebrauch ist in diesem Zusammenhang.)

Auf diese Weise konnte ich SimpleJobFactory durch meine eigene Variante außer Kraft zu setzen, eine InjectionHelper mit CDI auf jeden neu erstellten Job bewerben. Injection funktioniert sowohl für @EJB (mit JNDI-Lookup der kommentierten EJB Remote-Business Interface) und @Inject (mit JNDI-Lookup des CDI BeanManager zunächst einen neuen Initial verwendet und dann mit diesem neu geholten BM die CDI Bean selbst nachzuschlagen).

Danke PaoloC für die Antwort! (Ich hoffe, dass dieser Text als „Antwort auf PaoloC“ erscheint und nicht als Antwort auf das Hauptthema. Gefunden keine Möglichkeit, zwischen diesen zu unterscheiden.)

Ich habe vor kurzem auf dieses Problem gestoßen. Praktisch brauchen Sie:

1. Thread-Pool Implementieren von Arbeit zu Websphere Work Manager delegieren. (Quartz bietet nur SimpleThreadPool, die Arbeitsplätze auf nicht verwalteten Threads laufen). Sagen Sie Quarz verwendet, um diesen Thread-Pool von org.quartz.threadPool.class Eigenschaft
2. Tell Quarz WorkManagerThreadExecutor zu verwenden (oder implementieren benutzerdefinierte one) von org.quartz.threadExecutor.class Eigenschaft
3. Ein bisschen Geduld mit umständlichen Vermächtnis Webcontainern:)

Hier ist Github Demo die Verwendung von Quarz mit Websphere (und auch Tomcat).

Hoffe, es hilft jemand ..

Answer 5

Answer 6

Answer 7

Answer 8

Sie können prüfen, die unter JIRA Link auf Quarz bezüglich dieser angehoben.

Answer 9

Answer 10

Sie müssen websphere des verwalteten Thread-Pools verwenden. Sie können über Frühling und commonj tun. CommonJ kann, hat eine Aufgabe Testamentsvollstrecker, die verwalteten Threads erstellen wird. Sie können sogar einen Verweis auf eine jndi verwalteten Thread-Ressource verwenden. Sie können dann die commonj Aufgabe Testamentsvollstrecker in den Quarz-SchedulerFactoryBean basierend Frühling injizieren.

Bitte finden Sie unter http://open.bekk.no/boss/spring -scheduling-in-websphere / und navigieren Sie zu "Quartz mit CommonJ" Abschnitt für weitere Details.

Answer 11

Der Vorschlag von PaoloC für WAS85 ans Quarz 1.8.6 funktioniert auch auf WAS80 (und Quartz 1.8.6) und die Feder nicht braucht. (In meinem Setup Frühling 2.5.5 vorhanden ist, aber nicht in Gebrauch ist in diesem Zusammenhang.)

Auf diese Weise konnte ich SimpleJobFactory durch meine eigene Variante außer Kraft zu setzen, eine InjectionHelper mit CDI auf jeden neu erstellten Job bewerben. Injection funktioniert sowohl für @EJB (mit JNDI-Lookup der kommentierten EJB Remote-Business Interface) und @Inject (mit JNDI-Lookup des CDI BeanManager zunächst einen neuen Initial verwendet und dann mit diesem neu geholten BM die CDI Bean selbst nachzuschlagen).

Danke PaoloC für die Antwort! (Ich hoffe, dass dieser Text als „Antwort auf PaoloC“ erscheint und nicht als Antwort auf das Hauptthema. Gefunden keine Möglichkeit, zwischen diesen zu unterscheiden.)

Answer 12

Ich habe vor kurzem auf dieses Problem gestoßen. Praktisch brauchen Sie:

1. Thread-Pool Implementieren von Arbeit zu Websphere Work Manager delegieren. (Quartz bietet nur SimpleThreadPool, die Arbeitsplätze auf nicht verwalteten Threads laufen). Sagen Sie Quarz verwendet, um diesen Thread-Pool von org.quartz.threadPool.class Eigenschaft
2. Tell Quarz WorkManagerThreadExecutor zu verwenden (oder implementieren benutzerdefinierte one) von org.quartz.threadExecutor.class Eigenschaft
3. Ein bisschen Geduld mit umständlichen Vermächtnis Webcontainern:)

Hier ist Github Demo die Verwendung von Quarz mit Websphere (und auch Tomcat).

Hoffe, es hilft jemand ..