jboss-user
[Arriba] [Todas las Listas]

[jboss-Usuario] [JBoss Messaging] - Stalled Queue Consumidor en Ventanas

To: User development <jboss-user@xxxxxxxxxxxxxxx>
Subject: [jboss-Usuario] [JBoss Messaging] - Stalled Queue Consumidor en Ventanas(NIO) con Mensaje Grande y ConsumerWindow
From: Adam Malter <do-not-reply@xxxxxxxxx>
Date: Wed, 31 Aug 2011 21:47:43 -0400
Auto-submitted: yes
Delivery-date: Wed, 31 Aug 2011 21:49:13 -0400
Envelope-to: traductor@xxxxxxxxxxx
List-archive: <http://lists.jboss.org/pipermail/jboss-user>
List-help: <mailto:jboss-user-request@lists.jboss.org?subject=help>
List-id: The JBoss User main mailing list <jboss-user.lists.jboss.org>
List-post: <mailto:jboss-user@lists.jboss.org>
List-subscribe: <https://lists.jboss.org/mailman/listinfo/jboss-user>, <mailto:jboss-user-request@lists.jboss.org?subject=subscribe>
List-unsubscribe: <https://lists.jboss.org/mailman/listinfo/jboss-user>, <mailto:jboss-user-request@lists.jboss.org?subject=unsubscribe>
Reply-to: The JBoss User main mailing list <jboss-user@xxxxxxxxxxxxxxx>
Sender: jboss-user-bounces@xxxxxxxxxxxxxxx
Adam *Malter [*http://comunidad.*jboss.*org/Personas/*amalter] creó la discusión

"*Stalled *Queue Consumidor en Ventanas(*NIO) con Mensaje Grande y *ConsumerWindow"

para ver la discusión, visita: *http://comunidad.*jboss.*org/Mensaje/624167#624167

--------------------------------------------------------------
*Hi Todo,

utilizamos *HornetQ como nuestro desarrollo *JMS proveedor, y estoy intentando conseguir todo el mundo bastante cómodo a *upgrade lo a producción. Teniendo algunos problemas aun así cuándo realmente empezamos para golpear en él.

Esto es el caso:

*HornetQ corriendo en nuestro viejo *customized *JBoss caso (no incluso menciono el número de versión, *needless para decir nosotros'*ve *re-escrito bastante material que me preocupo mi caso no es genérico/fácilmente *reproducible)

En todo caso - esto es lo que estoy viendo..

*Server *config Es:


         Configuración *config = nuevo *ConfigurationImpl();

         *config.*setPersistenceEnabled(Cierto);
         *config.*setJournalDirectory(*FileUtil.*buildPath(*rootData, "revista").*getPath());
         *config.*setBindingsDirectory(*FileUtil.*buildPath(*rootData, "*bindings").*getPath());
         *config.*setPagingDirectory(*FileUtil.*buildPath(*rootData, "*paging").*getPath());
         *config.*setLargeMessagesDirectory(*FileUtil.*buildPath(*rootData, "*lobs").*getPath());
         *config.*setPersistDeliveryCountBeforeDelivery(Cierto); //requerido para *redelivery cuenta para trabajar en *rollbacks

         si (*SystemUtils.ES_VENTANAS_de OS)
            #unknown{^*config.*setJournalType(*JournalType.*NIO);
         }

         //*HornetQ Requiere usuario de grupo y *pw o *spits fuera de avisos
         *config.*setClustered(Falso);
         *config.*setClusterUser("*tcuser");
         *config.*setClusterPassword("*tradecard");
         *config.*setSecurityEnabled(Falso);

         //Sencillo *Q Servicio por ahora - sólo en transporte de VM
         *config.*getAcceptorConfigurations().Añade(nuevo *TransportConfiguration(*InVMAcceptorFactory.Clase.*getName()));
         *config.*setCreateJournalDir(Cierto);
         *config.*setCreateBindingsDir(Cierto);




Contenidos de *hornetq-versión.Propiedades de nuestro *jar archivo:


*hornetq.Versión.*versionName=HQ_2_2_5_AS_FINAL7
*hornetq.Versión.*majorVersion=2
*hornetq.Versión.*minorVersion=2
*hornetq.Versión.*microVersion=5
*hornetq.Versión.*incrementingVersion=121
*hornetq.Versión.*versionSuffix=Final
*hornetq.Versión.*versionTag=Final
*hornetq.*netty.Versión=3.2.3.Final-*r#unknown{^*buildNumber}
*hornetq.Versión.*compatibleVersionList=121



estamos corriendo en modo de XA con duradero *queues y no *selectors o prioridades graciosas. Además, el asunto sólo ocurre cuándo dejo la medida de ventana del consumidor en *default. Si cambio *setConsumerWindowSize(0), mi asunto desaparece.

Tan dentro una transacción sola, envío sobre 10 512*kb al mismo destino. El Destino les recibe *okay, inicios para procesarles, y entonces provoca un error de nivel de la aplicación (En este caso soy *purposefully provocándolo para probar nuestro *resubmit manejando)

Nuestra lógica de aplicación es que intentamos procesar el mensaje un *pre-número puesto de tiempo (deja dice 3) y antes de moverlo a letra muerta. Esto normalmente pasa en el muy primero *rollback, pero no siempre - esencialmente el consumidor/*mdb coge un mensaje, lo rueda atrás, empieza nuevo *tx, intenta coger otro y entonces cuelga con el siguiendo *stack:



"*AuditMDB[000]" - Hilo *t@113
   *java.*lang.Hilo.Estatal: CRONOMETRADO_ESPERANDO
          en *java.*lang.Objeto.Espera(Método Nativo)
          - esperando en <1#uno647*ea> (un *org.*hornetq.Núcleo.Cliente.*impl.*LargeMessageControllerImpl)
          En *org.*hornetq.Núcleo.Cliente.*impl.*LargeMessageControllerImpl.*waitCompletion(*LargeMessageControllerImpl.*java:304)
          en *org.*hornetq.Núcleo.Cliente.*impl.*LargeMessageControllerImpl.*saveBuffer(*LargeMessageControllerImpl.*java:283)
          en *org.*hornetq.Núcleo.Cliente.*impl.*ClientLargeMessageImpl.*checkBuffer(*ClientLargeMessageImpl.*java:201)
          en *org.*hornetq.Núcleo.Cliente.*impl.*ClientLargeMessageImpl.*getBodyBuffer(*ClientLargeMessageImpl.*java:101)
          en *org.*hornetq.*jms.Cliente.*HornetQBytesMessage.*getBuffer(*HornetQBytesMessage.*java:451)
          en *org.*hornetq.*jms.Cliente.*HornetQBytesMessage.*readBytes(*HornetQBytesMessage.*java:248)
          en *com.*tradecard.*server.*util.*BytesMessageInputStream.Leído(*BytesMessageInputStream.*java:68)
          en *com.*tradecard.Marco.*util.*ChunkedByteBuffer.*append(*ChunkedByteBuffer.*java:344)
          en *com.*tradecard.Marco.*util.*ChunkedByteBuffer.*append(*ChunkedByteBuffer.*java:332)
          en *com.*tradecard.*server.*mdb.*HornetQContainerInvoker$*HornetQServerSession.Carrera(*HornetQContainerInvoker.*java:287)
          en *java.*lang.Hilo.Carrera(Hilo.*java:662)


   Cerró *ownable *synchronizers:
          - Ninguno




Las porciones un poco pertinentes de nuestro *Hornet *Invoker es:


                  *xaResource = ((*XAQueueSession)sesión).*getXAResource();
                  *txManager.Empieza();
                  *tx = *txManager.*getTransaction();
                  *tx.*enlistResource(*xaResource);

                  *pooledSession.*syncRegister();
                  *tx.*registerSynchronization(*pooledSession);
                  //*cache La sesión/*senders para *QueueSender para utilizar
                  *TransactionCache.Puesto(*TransactionCache.*MQXA_SESIÓN, *pooledSession);
                  *txid = *TransactionToolbox.*getGlobalTransactionId();

                  Mensaje *requestMessage = *null;
                  *requestMessage = *receiver.Recibe(2000);

                  si (*requestMessage != *null &*amp;&*amp; !*quit)
                     #Nom_de_nom de mensaje = *null;
                     prueba
                        #unknown{^*BytesMessage *bytesMessage = (*BytesMessage)*requestMessage;
                        *BytesMessageInputStream la corriente = nueva *BytesMessageInputStream(*bytesMessage);
                        *ChunkedByteBuffer *buffer = nuevo *ChunkedByteBuffer(10000, 100);
                        *buffer.*append(Corriente);   // <--- colgando aquí
.... 



Allí no parece para ser cualquiera poseyendo la cerradura. Finalmente consigo *timeout avisos de mi *TxManager y tiene que botar el *server. Apenas boto, coge otro mensaje y procesos, deprisa consiguiendo el error otra vez.

Además, puedo ver un número de los archivos pendientes en mi *lobs directorio.

Todo de nuestra infraestructura de costumbre lo hace difícil de extraer el caso a un *postable caso de prueba. Aun así, si cualquiera lo piensa interesante y esto no parece como cualquier cosa directamente adelante, haré el intento.

La idea para poner la medida de ventana del consumidor a *zero vino del siguiendo cerrado *bug -  *https://asuntos.*jboss.*org/*browse/*HORNETQ-111 *https://asuntos.*jboss.*org/*browse/*HORNETQ-111

*Thanks para vuestro tiempo y cualquier ayuda!
--------------------------------------------------------------

Respuesta a este mensaje por ir a Comunidad
[*http://comunidad.*jboss.*org/Mensaje/624167#624167]

Empieza una discusión nueva en *JBoss *Messaging en Comunidad
[*http://comunidad.*jboss.*org/Escoge-contenedor!Entrada.*jspa?*contentType=1&*containerType=14&contenedor=2042]

Adam Malter [http://community.jboss.org/people/amalter] created the discussion

"Stalled Queue Consumer on Windows(NIO) with Large Message and ConsumerWindow"

To view the discussion, visit: http://community.jboss.org/message/624167#624167

--------------------------------------------------------------
Hi All,

We use HornetQ as our development JMS provider, and I'm trying to get everyone comfortable enough to upgrade it to production. Having some troubles however when we really start to bang on it.

This is the case:

HornetQ running in our old customized JBoss instance (I won't even mention the version number, needless to say we've re-written enough stuff that I worry my case is not generic/easily reproducible)

Anyway - this is what I'm seeing..

Server config is:


         Configuration config = new ConfigurationImpl();

         config.setPersistenceEnabled(true);
         config.setJournalDirectory(FileUtil.buildPath(rootData, "journal").getPath());
         config.setBindingsDirectory(FileUtil.buildPath(rootData, "bindings").getPath());
         config.setPagingDirectory(FileUtil.buildPath(rootData, "paging").getPath());
         config.setLargeMessagesDirectory(FileUtil.buildPath(rootData, "lobs").getPath());
         config.setPersistDeliveryCountBeforeDelivery(true); //required for redelivery count to work on rollbacks

         if (SystemUtils.IS_OS_WINDOWS) {
            config.setJournalType(JournalType.NIO);
         }

         //HornetQ requires cluster user and pw or spits out warnings
         config.setClustered(false);
         config.setClusterUser("tcuser");
         config.setClusterPassword("tradecard");
         config.setSecurityEnabled(false);

         //Simple Q Service for now - only in VM transport
         config.getAcceptorConfigurations().add(new TransportConfiguration(InVMAcceptorFactory.class.getName()));
         config.setCreateJournalDir(true);
         config.setCreateBindingsDir(true);




Contents of hornetq-version.properties from our jar file:


hornetq.version.versionName=HQ_2_2_5_FINAL_AS7
hornetq.version.majorVersion=2
hornetq.version.minorVersion=2
hornetq.version.microVersion=5
hornetq.version.incrementingVersion=121
hornetq.version.versionSuffix=Final
hornetq.version.versionTag=Final
hornetq.netty.version=3.2.3.Final-r${buildNumber}
hornetq.version.compatibleVersionList=121



We're running in XA mode with durable queues and no selectors or funny priorities. Additionally, the issue only occurs when I leave the consumer window size at default. If I change setConsumerWindowSize(0), my issue disappears.

So inside a single transaction, I send about 10 ~512kb to the same destination. Destination receives them okay, starts to process them, and then triggers an application level error (In this case I'm purposefully triggering it to test our resubmit handling)

Our application logic is that we try to process the message a pre-set number of times (lets say 3) and before moving it to dead letter. This usually happens on the very first rollback, but not always - essentially the consumer/mdb picks up a message, rolls it back, starts new tx, tries to pick up another one and then hangs with the following stack:



"AuditMDB[000]" - Thread t@113
   java.lang.Thread.State: TIMED_WAITING
          at java.lang.Object.wait(Native Method)
          - waiting on <1a647ea> (a org.hornetq.core.client.impl.LargeMessageControllerImpl)
          at org.hornetq.core.client.impl.LargeMessageControllerImpl.waitCompletion(LargeMessageControllerImpl.java:304)
          at org.hornetq.core.client.impl.LargeMessageControllerImpl.saveBuffer(LargeMessageControllerImpl.java:283)
          at org.hornetq.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:201)
          at org.hornetq.core.client.impl.ClientLargeMessageImpl.getBodyBuffer(ClientLargeMessageImpl.java:101)
          at org.hornetq.jms.client.HornetQBytesMessage.getBuffer(HornetQBytesMessage.java:451)
          at org.hornetq.jms.client.HornetQBytesMessage.readBytes(HornetQBytesMessage.java:248)
          at com.tradecard.server.util.BytesMessageInputStream.read(BytesMessageInputStream.java:68)
          at com.tradecard.framework.util.ChunkedByteBuffer.append(ChunkedByteBuffer.java:344)
          at com.tradecard.framework.util.ChunkedByteBuffer.append(ChunkedByteBuffer.java:332)
          at com.tradecard.server.mdb.HornetQContainerInvoker$HornetQServerSession.run(HornetQContainerInvoker.java:287)
          at java.lang.Thread.run(Thread.java:662)


   Locked ownable synchronizers:
          - None




The somewhat relevant portions of our Hornet Invoker are:


                  xaResource = ((XAQueueSession)session).getXAResource();
                  txManager.begin();
                  tx = txManager.getTransaction();
                  tx.enlistResource(xaResource);

                  pooledSession.syncRegister();
                  tx.registerSynchronization(pooledSession);
                  //cache the session/senders for QueueSender to use
                  TransactionCache.put(TransactionCache.MQXA_SESSION, pooledSession);
                  txid = TransactionToolbox.getGlobalTransactionId();

                  Message requestMessage = null;
                  requestMessage = receiver.receive(2000);

                  if (requestMessage != null &amp;&amp; !quit) {
                     Message message = null;
                     try {
                        BytesMessage bytesMessage = (BytesMessage)requestMessage;
                        BytesMessageInputStream stream = new BytesMessageInputStream(bytesMessage);
                        ChunkedByteBuffer buffer = new ChunkedByteBuffer(10000, 100);
                        buffer.append(stream);   // <--- hanging here
.... 



There doesn't seem to be anyone owning the lock. Eventually I get timeout warnings from my TxManager and have to bounce the server. As soon as I bounce, it picks up another message and processes, quickly getting the error again.

Additionally, I can see a number of files pending in my lobs directory.

All of our custom infrastructure makes it difficult to extract the case into a postable test case. However, if anyone thinks it worthwhile and this doesn't seem like anything straight forward, I'll make the attempt.

The idea for setting the consumer window size to zero came from the following closed bug -  https://issues.jboss.org/browse/HORNETQ-111 https://issues.jboss.org/browse/HORNETQ-111

Thanks for your time and any help!
--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/624167#624167]

Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2042]

_______________________________________________
*jboss-Usuario *mailing lista
*jboss-user@xxxxxxxxxxxxxxx
*https://listas.*jboss.*org/*mailman/*listinfo/*jboss-Usuario
_______________________________________________
jboss-user mailing list
jboss-user@xxxxxxxxxxxxxxx
https://lists.jboss.org/mailman/listinfo/jboss-user
<Anterior por Tema] Tema Actual [Siguiente por Tema>
  • [jboss-Usuario] [JBoss Messaging] - Stalled Queue Consumidor en Ventanas(NIO) con Mensaje Grande y ConsumerWindow, Adam Malter <=