ThreadPoolTaskExecutor

me recomendaron usar ThreadPoolTaskExecutor para manejar mi pool en mi socket java (me recomendaron que usara spring y lo inyectara)
ahora tengo una duda acabo de configurar bonecp con spring y el es mi pool de conexiones a oracle y si tengo un pool de hilos para mi socket java debo tener una relacion entre estos dos pool??? por ejemplo si mi socket java llegan 2500 conexiones simltaneas y configure un socket
50 hilos para atender esas 2500
 

mi pool con bone cp debe tener el mismo numero de hilos??? o mayor???? o como lo debo cofigurar

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

mmmm

Pues son dos cosas completamente distintas, pero si los trabajos que van a realizar los Runnables que metes al thread pool van a trabajar primariamente con base de datos, entonces sí es recomendable que coincida el número de hilos de tu thread pool con el número de conexiones del connection pool.

Lo que veo en tu config es que le estás poniendo capacidad máxima de 75 a la cola, eso significa que solamente podrás recibir hasta 135 conexiones a la vez (60 procesándose y 75 encoladas), si intentas encolar más te va a arrojar una RejectedExecutionException. Revisa los docs, creo que puedes ponerle 0 para que no tenga fin, o ponle una capacidad mayor al menos. Y si le pones cualquier capacidad que no sea ilimitada, te recomiendo encolar los runnables al pool dentro del try-catch para que en el bloque de catch RejectedExecutionException puedas al menos devolver un error a ese socket de que el server está saturado, y cerrar esa conexión.

Por último, una recomendación primariamente estilística: agrega el namespace p a ese XML para poder definir tus beans de manera más breve:

 

vale ezamudio

voy a tener en cuenta tu opcion estilística.

los otro que me dices es que si voy a trabajar primariamente con la base de datos, la verdad si ya que el socket java recibe la trama y de ahí la paso aun procedimiento almacenado que se encarga de des-copilar la trama y hace el llamado al paquete correspondiente (pl-sql logic) al final devuelve esa trama de respuesta que envio de vuelta a los clientes (HOST).

te hable de tener 2500 peticiones simultaneas y en el cofig que me das veo p:queueCapacity="2000" p:maxPoolSize="60" la suma me da 2600
si en futuro tengo un crecimiento del doble 5000 peticiones simultanea los valores anteriores podria ser p:queueCapacity="4040" p:maxPoolSize="60" o seria mejor opción que nuestro p:maxPoolSize="60" inciara mayor????

con referente a dejar esto del pool TaskExecutor con los valores que tu pusiste
 
mi configuracion para bonecp para esas 2500 conexiones como deria quedar??
actualmente esta asi:
 

haciendo test con un solo un usuario

1. haciendo el test ya con bonecp y ejecutando un paquete oracle no se porque me demora 2sg en devolver respueta???
2. porque cuando uso srping para cofigurar bocecp me trae simpre en la consola.
 

3.no se si esto lo hago bien

 

Imagen de ezamudio

no

yo no hice cuentas por ti. Pero 2000+60 es 2060, no 2600. Y no me voy a poner a darle fine tuning a tu aplicación que ni siquiera sé realmente cómo funciona (ya sé que lo explicaste a grandes rasgos pero para fine tuning se necesita conocer los detalles de implementación y hacer un buen análisis de los cuellos de botella para saber qué valores tener en todos los parámetros).

Si haces una prueba con un solo usuario, en frío, no puedes esperar buenos tiempos. Cuánto tiempo de esos 2s se fueron en el JIT? en cargar las clases que no estaban cargadas? Primero debes hacer una prueba, ignorar los tiempos, esperar unos segundos, y hacer una segunda prueba para ver un tiempo más realista.

No entiendo bien lo del punto 3 pero si ese run es el de los runnables que metes al pool, estás creando un application context PARA CADA TAREA que se ejecuta, eso es el peor overhead que puedes tener. Sólo necesitas crear un application context cuando inicia el servicio y todos los runnables usarán los beans que están en ese application context (si necesitas inyectar varias cosas a los runnables, considera definir un bean con scope prototype en el application context para obtener nuevos runnables de ahí en vez de crearlos por código).

Y no entiendo eso de que descompilas una trama pero no suena nada bien. Si es XML pues mejor usa SOAP y haz un web service normalito en vez de meterte en broncas de manejar el pool de sockets y todo eso. Si es un protocolo propietario pues sí, tienes que parsear lo que te mandan, etc.

Incluso considera que podrías necesitar más de un pool de hilos, dependiendo de lo que haga tu aplicación. No entiendo por qué tu parser es un stored procedure (si es que entendí bien) pero pues eso es tu bronca. Pero podrías tener varios pools:

- Uno donde encolas las conexiones entrantes, sólo para parsear las tramas
- Otro donde encolas las tramas ya parseadas, para procesarlas
- Otro donde encolas las tramas procesadas, para generar y enviar las respuestas

Por qué tres en vez de uno solo? Porque parsear la trama, procesarla y generar la respuesta son tres cosas muy distintas y cada una necesita recursos distintos y tarda un tiempo muy distinto. El primer pool podría tener muy pocos hilos porque las tareas se despachan muy rápido; el segundo tener más hilos y es el que debe estar sincronizado con las conexiones a base de datos, y el tercero también ser muy chico porque generar la respuesta es muy rápido.

respuesta del punto 3

 

Lo que te entendi fue hacaer esto:

 
en el socket java en la funcion principal:
 

lo que no entiendo es:
si necesitas inyectar varias cosas a los runnables, considera definir un bean con scope prototype en el application context para obtener nuevos runnables de ahí en vez de crearlos por código

haciendo algunas pruebas...

segun lo que comentas del context debe ser cargado una única vez
asi que lo maneje de la siguinete manera publico la clase completa para que veas como manejo una clase anidada que es la que extiende del runnable.

 

la clase anterior hago uso de la siguiente clase que me maneja las opciones
segun la trama que me llega en este ejemplo si el cliente manda "PING" server responde "PONG"
 

algo que me gustaria saber si el manejo de la clase JASAK_TramaService es el correcto si al manejarlo asi no voy a tener problemas
de tramas o sea que va ser (THREAD SAFE).????

si manejo una clase de utilidades donde todos sus métodos son estáticos debo trabajar cada método como sincronizado o no es necesario???

Imagen de ezamudio

sorry

no voy a leer todo ese código.

Una manera muy sencilla de usar el application context de Spring es que ahí "alambras" toda tu aplicación; defines todos tus componentes y los conectas entre sí, y luego solamente necesitas desde un   cargar ese application context, y en ocasiones obtener un bean del contexto para invocar un método y echar a andar toda la cosa.

Por tanto en tu código sólo necesitas tener algún Runnable que es el que inicia toda la aplicación. Dado que tienes una aplicación que escucha en un puerto TCP para recibir conexiones, ahí podría ser el punto de partida. Digamos que tienes algo así:

 

Y luego tienes un application context donde defines cosas más o menos así:

 

Entonces en la misma clase Servidor o en alguna otra puedes tener tu main:

 

y corres la aplicación invocando ese main y ya. Lo que ocurrirá es que se carga el application context, se crean los componentes necesarios (datasource, threadpool, server, etc EXCEPTO ese bean de worker porque tiene scope prototype) y luego obtienes el bean   y lo ejecutas (invocas su método  ) con lo que empieza a escuchar en el puerto configurado.

Cuando reciba una conexión, va a crear una instancia de  , pero no usando   sino a través del application context de Spring; el bean   está definido como prototipo por lo que cada vez que le pidas uno al application context, va a crear uno nuevo y le va a inyectar lo que necesita y te lo devuelve ya configurado. Nada más necesitas pasarle el socket y ya, está listo para realizar su trabajo.

runnable en clase servidor

con que fin en tu clase servidor hacer el runnable???
en mi clase servidor la manejo asi:
como se que no le gusta leer tanto codigo dejo lo relevante
 

con referente Conexion

esta clase la veo como analoga a la que yo manejo como ListenerSocket de esta clase no estido porque
haces aqui @Resource DataSource dataSource??? el del bean @Resource OtraCosa otroBean si no le veo problema , pero ese datasource no deberia ir en los daos???

 

Imagen de ezamudio

como sea

es un ejemplo de un bean con scope prototype que se le inyectan componentes a cada instancia que se crea. Es un ejemplo, no estoy diseñando tu aplicación. Imagínate que inyecté ahí un DAO que a su vez tiene el DataSource.