multiprocesadores con ExecutorService
Que onda chavos, como estan? espero que bien...
Haciendo el analisis de una aplicacion me encontre con una duda un poco rara y puede que este divagando demasiado, pero se me hizo interesante.
Voy a tener N colas con activeMQ. Esto implica que tengo los listeners para atender cada mensaje que me llegue. Cada listener tiene que abrir un thread(los cuales tengo pensado manejarlos con el ExecutorService) y este realizar debe realizar su chamba.
El problema es este...
Se tendran N servidores con M procesadores cada uno.
Es Logico que debo tener un Listener en cada servidor( se me ocurre dejar que cada uno escuche una cola diferente)
Ahora... Cada listener debe estar escuchando y cada que llegue un mensaje lanzar un hilo que sera despachado por el ExecutorService
Pregunta 1)
Si el ExecutorService se lanza en un procesador... este puede decir que se utilicen los N procesadores restantes del server para asi balancear la carga de chamba??
Pregunta 2)
Si no lo hace... acaso debo manejar el manejo de concurrencia como se indica aquí
Cualquier comentario/regaño/sugerencia/Zape es bueno en este momento je.
Gracias
- jali's blog
- Inicie sesión o regístrese para enviar comentarios
No lanzas hilos...
Creo que hay un error de concepto aquí. El ExecutorService que deberías usar es un ThreadPoolExecutorService. Hay dos maneras principales de configurarlos pero el punto es que tú no lanzas hilos; simplemente le pasas una tarea al ExecutorService y éste la va a encolar para que se realice dentro de un hilo que administra. Si ocurre una excepción, se desecha ese hilo y se crea uno nuevo para ejecutar más tareas de la cola. Las tareas las pasas simplemente en forma de un Runnable (o de un FutureTask con un Callable si es que necesitas obtener un resultado).
El ExecutorService puede lanzar sus hilos en distintos procesadores, depende de la configuración de la JVM. Por default va a usar todos los CPUs disponibles. El ExecutorService efectivamente utiliza un procesador para manejar la cola de tareas y coordinar y monitorear sus hilos, pero es mínimo el trabajo que va a realizar.
Para una referencia en caso que necesites, revisa mi blog.
Muchas gracias!
Mil gracias por la informacion. Ahora mismo leo tu blog.
De hecho...
No sólo existe el problema al entender cómo funciona un Thread Pool sino el hecho de que menciones que quieres controlar la carga de los procesadores. Es una idea érronea al querer resolver problemas concurrentes y no de multiprocesamiento y paralelismo. Las APIs de concurrencia de java resuelven eso, problemas concurrentes (sin meternos a temas de sincronización o algoritmos no-bloqueantes) al utilizar diferentes contextos de ejecución sobre tareas proporcionadas por tí, ya sean dependientes o independientes. Obviamente con la posibilidad de controlar algunas características del recurso central tales como políticas de despacho de tareas, el tipo de contenedor (ArrayBlockingQueue, etc), entre otras.
De tal manera que la maquinaria debajo de la implementación del resource pool (tómando el verdadero concepto abstracto que es aplicable a concurrencia, conexiones y otros recursos) maneje ya sea a alto o bajo nivel todas las primitivas necesarias para el funcionamiento adecuado del componente. Por ejemplo la prioridad de los threads, circunstancias en la que se necesite invocar a un nuevo thread, y posiblemente a bajo nivel la VM junto con el scheduler controle la distribución de tareas a procesadores, pero lo dudo, generalmente es trabajo del SO. La VM es un proceso más, con condiciones especiales, dentro del sistema operativo.
Si bien, habrán tareas (en el sentido de Runnables y afines, como lo menciona ezamudio) que podrán ser ejecutadas concurrentemente por tus CPUs, no podrás controlar cuál, por cuánto, y por cuál de ellos
Multiprocesamiento y paralelización requiren de otros conceptos (y bibliotecas) ajenas (no totalmente, pero en cuanto a uso y finalidad) a las APIs de java para concurrencia.