0 Replies Latest reply on Sep 28, 2016 3:42 PM by bjornbak

    (Transaction)Timeout with MDB in Artimis WF 10.1

    bjornbak

      Hi,

       

      For a long running batch integration we have created a queue for queueing callbacks from our partner.

       

      We have a MDB which is annotated like this:

       

      @MessageDriven(name = "MyExecutionMDB", activationConfig = {

         @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
         @ActivationConfigProperty(propertyName = "destination", propertyValue "java:/queue/myQueue"),
         @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
         @ActivationConfigProperty(propertyName = "transactionTimeout", propertyValue = "3000000")

      })

       

      This worked perfectly in WF 9 then a callback is received by a servlet a message is queued and the partner get an acknowledged for the received callback.

       

      Then the input is asynchronously handled within the transactionTimeout. If the integration crashes the delivery attempts of the queue insures a retry..

       

      But after we upgraded to wf 10 we experience that the delivery attempts fires within seconds even if the integration is running fine and ends up have the integration several times simultaneously.

       

      I have tried to reduce the delivery attempts to 1 but then the message is delivery is received by our MDB and milliseconds latter by the Dead Letter Queue.

       

      21:18:09,305 DEBUG           Hec-SF-NEW [ClientSessionFactoryImpl] (default task-1) Trying reconnection attempt 0/1

      21:18:09,305 DEBUG           Hec-SF-NEW [ClientSessionFactoryImpl] (default task-1) Trying to connect with connector = org.apache.activemq.artemis.core.remoting.impl.invm.InVMConnectorFactory@7209d84, parameters = {serverId=0} connector = null

      21:18:09,305 DEBUG           Hec-SF-NEW [ClientSessionFactoryImpl] (default task-1) Reconnection successful

      21:18:09,306 DEBUG           Hec-SF-NEW [ClientSessionFactoryImpl] (default task-1) ClientSessionFactoryImpl received backup update for live/backup pair = TransportConfiguration(name=in-vm, factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory) ?serverId=0 / null but it didn't belong to TransportConfiguration(name=in-vm, factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory) ?serverId=0

       

      21:18:09,331 INFO            Hec-SF-NEW [MyBatchRequestServlet] (default task-1) Sending message

      21:18:09,336 DEBUG                      [QueueImpl] (Thread-1 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@7d151dff-1042760804)) QueueImpl[name=jms.queue.myQueue, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=74a582e4-855f-11e6-93b0-e528fe970026]]@12921d28 doing deliver. messageReferences=0

      21:18:09,336 INFO            Hec-SF-NEW [MyBatchRequestServlet] (default task-1) Answer received

       

      21:18:09,337 DEBUG           Hec-SF-NEW [ClientSessionImpl] (default task-1) Calling close on session ClientSessionImpl [name=4a905526-85b0-11e6-931b-45a2e453ed68, username=null, closed=false, factory = org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl@572fb346, metaData=(jms-session=,)]@1a8c4409

      21:18:09,337 DEBUG           Hec-SF-NEW [ClientSessionImpl] (default task-1) calling cleanup on ClientSessionImpl [name=4a905526-85b0-11e6-931b-45a2e453ed68, username=null, closed=false, factory = org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl@572fb346, metaData=(jms-session=,)]@1a8c4409

      21:18:09,337 DEBUG           Hec-SF-NEW [ClientSessionImpl] (default task-1) Calling close on session ClientSessionImpl [name=4a907c37-85b0-11e6-931b-45a2e453ed68, username=null, closed=false, factory = org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl@572fb346, metaData=(jms-session=,)]@24acce3b

      21:18:09,340 DEBUG           Hec-SF-NEW [ClientSessionImpl] (default task-1) calling cleanup on ClientSessionImpl [name=4a907c37-85b0-11e6-931b-45a2e453ed68, username=null, closed=false, factory = org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl@572fb346, metaData=(jms-session=,)]@24acce3b

      21:18:09,340 DEBUG           Hec-SF-NEW [ClientSessionImpl] (default task-1) Session was already closed, giving up now, this=ClientSessionImpl [name=4a907c37-85b0-11e6-931b-45a2e453ed68, username=null, closed=true, factory = org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl@572fb346, metaData=(jms-session=,)]@24acce3b

      21:18:09,340 DEBUG           Hec-SF-NEW [ClientSessionImpl] (default task-1) Session was already closed, giving up now, this=ClientSessionImpl [name=4a905526-85b0-11e6-931b-45a2e453ed68, username=null, closed=true, factory = org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl@572fb346, metaData=(jms-session=,)]@1a8c4409

       

      21:18:09,394 INFO                       [MyExecutionMDB] (Thread-9 (ActiveMQ-client-global-threads-864916798)) Received message

      21:18:09,441 INFO                       [MyExecutionMDB] (Thread-9 (ActiveMQ-client-global-threads-864916798)) Starting integration

       

      21:18:09,675 DEBUG                      [TransactionImpl] (Thread-1 (ActiveMQ-scheduled-threads-655429404)) Marking Transaction 2036 as rollback only

      21:18:09,675 WARN                       [server] (Thread-1 (ActiveMQ-scheduled-threads-655429404)) AMQ222103: transaction with xid XidImpl (387691069 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.60.78.25.100.87.-20.22.55.0.0.0.32.0.0.0.1.0.0.0.0 formatID:131077 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.60.78.25.100.87.-20.22.55.0.0.0.30.49 base64:AAAAAAAAAAAAAP__fwAAATxOGWRX7BY3AAAAIAAAAAEAAAAAAAAAAAAAAAAAAP__fwAAATxOGWRX7BY3AAAAHjEHAgIA timed out

      21:18:09,679 WARN                       [server] (Thread-1 (ActiveMQ-scheduled-threads-655429404)) AMQ222149: Message Reference[2033]:RELIABLE:ServerMessage[messageID=2033,durable=true,userID=null,priority=4, bodySize=356, timestamp=0,expiration=0, durable=true, address=jms.queue.myQueue,properties=TypedProperties[__AMQ_CID=4a905525-85b0-11e6-931b-45a2e453ed68]]@1309161598 has reached maximum delivery attempts, sending it to Dead Letter Address jms.queue.DLQ from jms.queue.myQueue

       

      21:18:09,683 INFO  int_ext_log-14310933 [MyIntegrationSessionImpl] (Thread-9 (ActiveMQ-client-global-threads-864916798)) Some debug from the running integration

       

      21:18:10,580 ERROR                      [DeadLetterQueueMDB] (Thread-11 (ActiveMQ-client-global-threads-864916798)) Message pulled from Dead Letter Queue with destination: ActiveMQQueue[DLQ]: com.mydomain.APPException: Message pulled from Dead Letter Queue with destination: ActiveMQQueue[DLQ]

        at com.mydomain.jms.deadletterqueue.DeadLetterQueueMDB.onMessage(DeadLetterQueueMDB.java:39)

       

      21:18:09,683 INFO  int_ext_log-14310933 [MyIntegrationSessionImpl] (Thread-9 (ActiveMQ-client-global-threads-864916798))  Some more debug from the running integration

       

       

      The lines with Hec-SF-NEW is the client servlet.

       

      MyExecutionMDB is the MDB receiving the message and starting the integration.

       

      MyIntegrationSessionImpl is the core integration implementation.

       

      As it shown in the debug the integration is started before the time out and continues after the Dead Letter delivery.

       

      How do I make the queue be patient with the MDB so it does not attempt redelivery or Dead Letter delivery??

       

      I suspect that the transactionTimeout property is ignored? According to the Java EE 7 documentation ActivationConfigProperty (Java(TM) EE 7 Specification APIs) do the property transactionTimeout not exist. What should I replace it with?