La cola JMS está llena

Question

Mi aplicación Java EE envía JMS a la cola continuamente, pero a veces la aplicación del consumidor JMS dejó de recibir JMS. Hace que la cola JMS sea muy grande, incluso completa, lo que colapsará el servidor. Mi servidor es JBoss o Websphere. ¿Los servidores de aplicaciones proporcionan una estrategia para eliminar los mensajes JMS "timeout"?

¿Cuál es la estrategia para manejar una larga cola JMS? ¡Gracias!

Answer 1

Con cualquier mensaje asíncrono debe lidiar con el problema "productor rápido/consumidor lento". Hay varias maneras de lidiar con esto.

1. Agregue los consumidores. Con WebSphere MQ puede activar una cola en función de la profundidad. Algunas tiendas lo usan para agregar nuevas instancias de consumidores a medida que crece la profundidad de la cola. Luego, cuando la profundidad de la cola comienza a disminuir, los consumidores adicionales mueren. De esta forma, se puede hacer que los consumidores escalen automáticamente para adaptarse a cargas cambiantes. Otros corredores generalmente tienen una funcionalidad similar.
2. Haga que la cola y el sistema de archivos subyacente sean realmente grandes. Este método intenta absorber picos en la carga de trabajo por completo en la cola. Esto es, después de todo, lo que se diseñó para hacer cola en primer lugar. El problema es que no se escala bien y debe asignar un disco que el 99% del tiempo estará casi vacío.
3. Caducar mensajes antiguos. Si los mensajes tienen un tiempo de caducidad configurado, puede hacer que se limpien. Algunos intermediarios JMS lo harán de forma automática, mientras que otros necesitarán navegar por la cola para eliminar los mensajes caducados. El problema con esto es que no todos los mensajes pierden su valor comercial y son elegibles para caducidad. La mayoría de los mensajes de "olvídate del fuego" (registros de auditoría, etc.) entran en esta categoría.
4. Regrese al productor. Cuando la cola se llena, nada puede ponerle nuevos mensajes. En WebSphere MQ, la aplicación de producción recibe un código de retorno que indica que la cola está llena. Si la aplicación distingue entre errores fatales y transitorios, puede detenerse y volver a intentarlo.

La clave para implementar con éxito cualquiera de estos es que su sistema pueda proporcionar errores "blandos" a los que la aplicación responderá. Por ejemplo, muchas tiendas elevarán el parámetro MAXDEPTH de una cola la primera vez que obtienen una condición QFULL. Si la profundidad de la cola excede el tamaño del sistema de archivos subyacente, el resultado es que en lugar de un error "suave" que afecta a una única cola, el sistema de archivos se llena y todo el nodo se ve afectado. Está MUCHO mejor sin afinar el sistema para que la cola llegue a MAXDEPTH mucho antes de que se llene el sistema de archivos, pero también instrumentando la aplicación u otros procesos para reaccionar de alguna manera a la cola completa.

Pero no importa lo que haga, la opción n. ° 4 anterior es obligatoria. Independientemente de la cantidad de disco que asigne o la cantidad de instancias de consumo que implemente o la rapidez con que caduque los mensajes, siempre existe la posibilidad de que su (s) consumidor (es) no se mantenga al día con la producción de mensajes. Cuando esto suceda, su aplicación de productor debería reducir la aceleración, o activar una alarma y detenerse o hacer cualquier otra cosa que no sea colgarse o morir. La mensajería asincrónica solo es asincrónica hasta el punto de que se queda sin espacio para poner mensajes en cola. Después de eso, tus aplicaciones son sincrónicas y deben manejar con gracia esa situación, incluso si eso significa cerrar (con gracia) el propio.

Answer 2

Sure!

http://download.oracle.com/docs/cd/E17802_01/products/products/jms/javadoc-102a/index.html Message#setJMSExpiration(long) hace exactamente lo que quiere.