Búsqueda de Java Asíncrono genérico Job Execution Framework/Library

Question

Estoy buscando un marco de ejecución de trabajo Java genérico asíncrono que podría manejar Callable s o Runnable s. Sería similar a java.util.concurrent.ExecutorService, (y posiblemente envuelva ExecutorService), sino que también tendría las siguientes características:

1. La capacidad de persistir puestos de trabajo a una base de datos en caso de que la aplicación se cae mientras el trabajo se está dando servicio y poder reiniciar los trabajos sin terminar. (Entiendo que mi trabajo puede tener que implementar Serializable, que está bien.)

2. Trabajar con UUID para permitir que el cliente obtenga tokens de trabajo y consultar sobre el estado del trabajo. (Bajo el capó esta información se mantuvo a una base de datos, también.)

que han comenzado a trabajar en esto mismo mediante la construcción de alrededor de ExecutorService, pero yo preferiría un fuera de la caja, solución de código abierto, si uno existe

Algo que podría funcionar dentro de Spring Framework sería ideal.

Answer 1

Puede utilizar Quartz, y crear un adaptador concreto Job que los delegados a una Runnable o Callable. La interfaz de Quartz 'Job agrega la capacidad de mantener algún estado entre las invocaciones de una tarea. Si lo desea, Quartz puede almacenar trabajos y su estado de forma duradera en una base de datos relacional, y ejecutarlos en un clúster escalable de hosts.

Answer 2

Es posible que desee mirar Quartz.

cuarzo es un sistema completo, abierta trabajo de origen programación que se puede integrar con, o se usa junto a prácticamente cualquier aplicación J2EE o J2SE - desde la aplicación más pequeño autónomo para el mayor sistema de comercio electrónico. Quartz se puede usar para crear cronogramas simples o complejos para ejecutar decenas, cientos o incluso decenas de miles de trabajos; trabajos cuyas tareas se definen como componentes Java estándar o EJB. Quartz Scheduler incluye muchas características de clase empresarial, como transacciones JTA y clustering.

Answer 3

Eche un vistazo a http://www.opensymphony.com/quartz/wikidocs/Features.html y vea si ya tiene algo para usted.

Desde esa página:

Con el uso de la JDBCJobStore incluido, todos los trabajos y disparadores configurado como "no volátil" se almacenan en una base de datos relacional a través de JDBC

Answer 4

Otro dirección podría ser algo así como usar Terracotta, que tiene la capacidad de agrupar el montón en su JVM y persistir en la disponibilidad. Terracotta admite la integración con Quartz si es útil desde un punto de vista de programación. Además, hay un maestro trabajador y un mensaje de integration module que también puede ser útil. Terracota es de código abierto.

Answer 5

Para seguir con el punto de vista de Alex, una solución de terracota no persistiría en sus trabajos en la base de datos, sino que persistirían en el almacén de memoria distribuida de Terracota.

Dado que Terracotta conserva el almacenamiento de memoria en el disco, esta es una versión más eficiente de poner esos trabajos en la base de datos.

Al mismo tiempo, le da un modelo de programación POJO puro, por lo que ni siquiera tiene que lidiar con DB txns, ORM y similares, a menos que su carga de trabajo particular se dirija al DB (en cuyo caso Terracota no te ayuda ni te hace daño aquí, solo ayuda a distribuir el trabajo).

El patrón MasterWorker le ayudará a distribuir el trabajo fuera de la parrilla, y se puede llegar muy fácilmente comenzado a usar un DistributedExecutorService, la presentación de trabajos es el siguiente:

CompletionService executor = new DistributedCompletionService(new DistributedExecutorService("myTopologyName")); 
executor.submit(new MyRunnable(), null); 
... 
Future f = executor.take(); 

Aquí está el enlace a Quickstart guide in the master-worker implementation on the Terracotta Forge.

Lo que es más - terracota no requiere que se implementa Serializable - aunque se puede si usted quiere :)