2011-01-21 4 views
5

Estoy usando ScheduledThreadPoolExecutor.schedule (Runnable, int, TimeUnit) para programar algunos objetos de una clase que implementa Runnable.Obtener objetos Runnable que programé utilizando ScheduledThreadPoolExecutor al usar el método shutdownNow()

En algún momento, mi aplicación se está cerrando y uso ScheduledThreadPoolExecutor.shutdownNow(). De acuerdo con la documentación, devuelve una lista de ScheduledFuture.

Lo que realmente quiero hacer es obtener un control del objeto que programé originalmente, y obtener un poco de datos del mismo que luego mostraré diciendo que no se pudo ejecutar. Luego, la aplicación lo utilizará para intentar ejecutarlo cuando la aplicación vuelva a iniciarse.

+0

En realidad, el javadoc al que apunta dice que devuelve una lista de Runnables. ¿Es eso lo que querías decir? – kvista

+0

La especificación del método es List , pero el texto actual del método shutdownNow() dice que es de ScheduledFuture. Supongo que realmente significa RunnableScheduledFuture ya que el tipo de devolución debe ser Runnable, pero incluso con esa interfaz, no parece haber una forma de obtener el objeto original que programé :( – Drizzt321

Respuesta

2

La forma habitual de obtener información acerca de los objetos enviados a un ejecutor es mantener un puntero a los objetos originales (ya sean extensiones a Callable, Runnable, etc.). Después de llamar shutdownNow(), y tener en cuenta del Ejecutable devuelto por la que estaban en espera de ejecución, se puede usar eso para podar su lista original de los objetos y simplemente interrogar a los que realmente se ejecutaron.

+0

Hmm ... así que si Debía agregar un Mapa que contiene una referencia al calendario I de Runnable con el objeto Futuro, y al final del método run() eliminarlo de ese Mapa, eso debería funcionar correctamente. Y cuando llamo a shutdownNow(), entonces iterar sobre el mapa y consultar el futuro para ver si se ha completado o no. ¿le suena viable? ¿o voy demasiado complicado? – Drizzt321

+0

¿no deberían ser los punteros 'WeakReference's sin embargo? – biziclop

+0

usted debe tener cuidado con la memoria con este enfoque, sugiero que se elimine de la colección lo antes posible Depende de la cantidad de tareas que envíe antes del cierre. – Waldheinz

1

Si solo desea presentar la información al usuario, el enfoque más simple podría ser implementar un método significativo toString() para el Runnable s que está programando. Luego, simplemente puede repetir la lista que le da el Executor y registrar lo que obtiene.

Pero la triste verdad es que sus objetos originales quedan envueltos por el Executor, sin embargo. Luego, deberá mantener una lista de lo que pasa al Executor manualmente y dejar que Runnable se eliminen de esta lista cuando se ejecutan. Obviamente, necesitaría usar una lista segura para subprocesos para este propósito.

+0

El problema es que no aparezco (aunque en realidad no he ejecutado el código) para obtener el Runnable original que programo, así que no puedo hacer eso. Tendré que mantener una lista, como recomiendan usted y Kelly Vista. – Drizzt321

+0

Se envuelven en un FutureTask, que los envuelve en un sincronizador abstracto sin procesar, que los envuelve en un invocable. Son bastante difíciles de conseguir :) – Affe

+0

Sí, muy molesto por hacer algo como esto. Lo cual me confunde un poco. ¿No sería una cosa común querer obtener el objeto original que programó cuando le entregaron una lista desde shutdownNow()? Eso es lo que esperaría, que es como parece que ThreadPoolExecutor lo hace. – Drizzt321

Cuestiones relacionadas