Subprocesos no administrados Spring Quartz Websphere Hibernate

Question

Parece que nuestra implementación del uso de Quartz - JDBCJobStore junto con Spring, Hibernate y Websphere está arrojando hilos no administrados.

He leído un poco y encontré un artículo técnico de IBM que indica que el uso de Quartz con Spring lo causará. Sugieren usar CommnonJ para abordar este problema.

He hecho algunas investigaciones adicionales y los únicos ejemplos que he visto hasta ahora se refieren al plan viejo JobStore que no está en una base de datos.

Entonces, me preguntaba si alguien tiene un ejemplo de la solución para este problema.

Gracias

Answer 1

tenemos una solución para este trabajo (dos en realidad).

1) Modifique el código fuente de cuarzo para usar un hilo daemon de WorkManager para la secuencia principal del programador. Funciona, pero requiere cambiar cuartos de galón. No usamos esto, ya que no queríamos mantener una versión pirateada de cuarzo. (Eso me recuerda que iba a enviar esto al proyecto, pero lo olvidé por completo)

2) Cree un WorkManagerThreadPool para ser utilizado como el hilo de cuarzo. Implemente la interfaz para el ThreadPool de cuarzo, para que cada tarea que se desencadena dentro del cuarzo esté envuelta en un objeto común de trabajo que luego se programará en el WorkManager. La clave es que WorkManager en WorkManagerThreadPool se debe inicializar antes de que se inicie el planificador, a partir de una cadena Java EE (como la inicialización de servlet). WorkManagerThreadPool debe crear un hilo de daemon que manejará todas las tareas programadas creando y programando los nuevos objetos Work. De esta forma, el programador (en su propio hilo) pasa las tareas a un hilo gestionado (el daemon Work).

No es simple, y lamentablemente no tengo código disponible para incluir.

Answer 2

Comprobar este artículo: http://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_alcott.html

básicamente, establece la propiedad TaskExecutor en SchedulerFactoryBean utilizar un org.springframework.scheduling.commonj.WorkManager TaskExecutor que utilizar hebras de contenedor administrado.

Answer 3

Puede consultar el siguiente enlace JIRA alzado en cuarzo con respecto a esto.

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

Esto tiene la aplicación WebSphereThreadPool requerido que se puede utilizar con los cambios en quartz.properties como se ha mencionado para satisfacer sus necesidades. Espero que esto ayude.

Saludos, Siva

Answer 4

que tendrá que utilizar grupos de subprocesos administrados de WebSphere. Puedes hacer esto a través de spring y commonj. CommonJ puede tiene un ejecutor de tareas que creará hilos gestionados. Incluso puede usar una referencia a un recurso de hilo gestionado por jndi. A continuación, puede inyectar el ejecutor de tareas commonj en Quartz SchedulerFactoryBean basado en Spring.

Consulte http://open.bekk.no/boss/spring-scheduling-in-websphere/ y vaya a la sección "Cuarzo con CommonJ" para obtener más información.

Answer 5

Solo una nota: el enlace anterior del QUARTZ-708 ya no es válido. Este nuevo número (en una nueva Jira) parece que esté abordando el problema: http://jira.terracotta.org/jira/browse/QTZ-113 (fixVersion = 1.8.6, 2.0.2)

Answer 6

Adición de otra respuesta a la rosca, ya que he encontrado una solución para esto, finalmente.

Mi entorno: WAS 8.5.5, Quartz 1.8.5, no Spring.

El problema que tuve fue el (anteriormente indicado) hilo no administrado causando una NamingException de ctx.lookup(myJndiUrl), que fue en lugar trabajando correctamente en otros servidores de aplicaciones (JBoss, Weblogic); En realidad, Webpshere estaba disparando un "incidente" con el siguiente mensaje:

javax.naming.ConfigurationException: Una operación JNDI en un "java:" nombre no se puede completar porque el tiempo de ejecución del servidor no es capaz de asociar la hilo de operación con cualquier componente de aplicación J2EE. Esta condición puede ocurrir cuando el cliente JNDI que utiliza el nombre "java:" no se ejecuta en el hilo de una solicitud de aplicación de servidor. Asegúrese de que una aplicación J2EE no ejecute operaciones JNDI en nombres "java:" dentro de bloques de código estáticos o en subprocesos creados por esa aplicación J2EE. Dicho código no se ejecuta necesariamente en el hilo de una solicitud de aplicación de servidor y, por lo tanto, no es compatible con operaciones JNDI en nombres "java:".

Los siguientes pasos resolvieron el problema:

1) actualizado a 1.8.6 cuarzo (no hay cambios en el código), justo pom experto

2) añade lo siguiente a dep classpath (en mi caso, la carpeta EAR/lib), para que el nuevo WorkManagerThreadExecutor esté disponible

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

Nota: en QTZ-113 o en la Documentación oficial de Quartz 1.x2.x, no se menciona cómo activar esta solución.

3) se añade lo siguiente a quartz.properties ("WM/predeterminado" JNDI de la DefaultWorkManager ya configurada en mi WS 8.5.5, véase Recursos -> -> AsynchronousBeans WorkManagers en la consola WAS) :

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

Nota: la clase derecha es org.quartz. personalizado .WorkManagerThreadExecutor para quartz-scheduler-1.8.6 (probado) o org.quartz. commonj .WorkManagerThreadExecutor de 2.1.1 en (no probado, pero comprobada dentro real quartz-commonj's jars en repositorios de Maven)

4) trasladaron las operaciones de búsqueda JNDI en el constructor vacío del trabajo de cuarzo (gracias a m_klovre's "Thread outside of the J2EE container"); es decir, el constructor se invocaba por reflexión (método newInstance()) desde el mismo contexto J2EE de mi aplicación, y tenía acceso al espacio de nombres java:global, mientras que el método execute(JobExecutionContext) aún se ejecutaba en un contexto más pobre, al que faltaba toda mi aplicación EJBs

Espero que esto ayude.

Ps. como referencia, puede encontrar here un ejemplo del archivo quartz.properties que estaba usando anteriormente

Answer 7

La propuesta de PaoloC para WAS85 y Quartz 1.8.6 también funciona en WAS80 (y Quartz 1.8.6) y no necesita Primavera. (En mi configuración Spring 2.5.5 está presente, pero no se usa en ese contexto.)

De esa manera pude anular SimpleJobFactory por mi propia variante, usando un InjectionHelper para aplicar CDI en cada trabajo recién creado. La inyección funciona tanto para @EJB (con la búsqueda JNDI de la interfaz empresarial EJB anotada) como @Inject (con la búsqueda JNDI del CDI BeanManager usando primero un nuevo InitialContext, y luego usando este BM recién obtenido para buscar el bean CDI).

Gracias PaoloC por esa respuesta! (Espero que este texto aparezca como una "respuesta a PaoloC" y no como una respuesta al tema principal. No se encontró ninguna manera de diferenciar entre estos.)

Answer 8

Recientemente he encontrado este problema. Prácticamente necesita:

1. Implemente el grupo de subprocesos delegando trabajo en Websphere Work Manager. (Quartz proporciona solo SimpleThreadPool que ejecuta trabajos en subprocesos no administrados). Dile a cuarzo para utilizar este grupo de subprocesos org.quartz.threadPool.class propiedad
cuarzo
2. Tell utilizar WorkManagerThreadExecutor (o implementar uno personalizado) por org.quartz.threadExecutor.class propiedad
3. Un poco de paciencia con el legado engorroso contenedores web :)

Aquí es github demo de usando Quartz con Websphere (y también Tomcat).

espero que ayude a alguien ..