Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-12523

Artemis gets to state when it doesn't respond to producer

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Blocker Blocker
    • 7.1.0.CR1
    • 7.1.0.ER3
    • ActiveMQ
    • None
    • Regression
    • Hide
      git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git
      cd eap-tests-hornetq/scripts/
      git checkout 9da2c9e890b9284d8a3ca8aadc595f215d9b45e1
      groovy -DEAP_VERSION=7.1.0.ER3 PrepareServers7.groovy
      export WORKSPACE=$PWD
      export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap
      export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap
      export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap
      export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap
      
      cd ../jboss-hornetq-testsuite/
      
      mvn clean test -Dtest=ReplicatedColocatedClusterFailoverTestCase#testFailbackWithMdbsShutdownDeployUsingCLI -DfailIfNoTests=false -Deap=7x | tee log
      
      Show
      git clone git: //git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git cd eap-tests-hornetq/scripts/ git checkout 9da2c9e890b9284d8a3ca8aadc595f215d9b45e1 groovy -DEAP_VERSION=7.1.0.ER3 PrepareServers7.groovy export WORKSPACE=$PWD export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap cd ../jboss-hornetq-testsuite/ mvn clean test -Dtest=ReplicatedColocatedClusterFailoverTestCase#testFailbackWithMdbsShutdownDeployUsingCLI -DfailIfNoTests= false -Deap=7x | tee log

      Scenario

      • There are two servers configured in colocated replicated HA
      • There are two producers. Each one sends messages on different server to InQueue.
      • There is MDB on server 2 which resends messages from InQueue to OutQueue
      • During the resending of messages, server 2 is restarted.
      • After all messages are resent, receiver is connected to server 1 and it receives all messages.

      Expectation: All messages sent by producers to InQueue are received by receiver from OutQueue.
      Reality: After the restart of server 2, the server 1 gets into the state when it stops to respond to the producer. Producer sends a bulk of messages which are marked as duplicates by server, but the exception packet is not sent to producer. See below for more detailed description what is happening on the server.

      Customer impact: Artemis may get into the state when it is not able to work properly. This can lead to unavailability of service.

      This is regression against 7.0.z.

      The issue wasn't reported earlier, because the test failed due to JBEAP-7968 before 7.1.0.ER3.

      Detail description of what happened on server

      I looked at the server traces to see what happened when server received session commit packet from producer. Based on the traces, the server behaved correctly and it even scheduled to send response packet with the duplication exception.

      06:17:28,206 TRACE [org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler] (Thread-6 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@37386953)) ServerSessio
      nPacketHandler::scheduling response::PACKET(ActiveMQExceptionMessage)[type=20, channelID=0, packetObject=ActiveMQExceptionMessage, exception= ActiveMQDuplicateIdException[errorType=DUPLICATE_ID_REJECTED message=
      Duplicate message detected - message will not be routed. Message information:LargeServerMessage[messageID=7034,durable=true,userID=f3b4e359-7834-11e7-bd40-001b217d6dc3,priority=4, timestamp=Thu Aug 03 06:17:28 E
      DT 2017,expiration=0, durable=true, address=jms.queue.InQueue,properties=TypedProperties[__AMQ_CID=829bf1a6-7834-11e7-bd40-001b217d6dc3,count=1699,counter=1700,_AMQ_DUPL_ID=1bfb61bf-2eca-4f33-9723-5998dcd84ed515
      01755380929,_AMQ_LARGE_SIZE=409615,color=RED]]@971671687]]
      

      The problem is that after this event, I cannot find message which would say that the packet was sent. As you can see in code snippet below, the "scheduling response" says that it was registered IOCallback, which will send the packet once it is triggered.

      private void sendResponse(final Packet confirmPacket,
                                   final Packet response,
                                   final boolean flush,
                                   final boolean closeChannel) {
            if (logger.isTraceEnabled()) {
               logger.trace("ServerSessionPacketHandler::scheduling response::" + response);
            }
      
            storageManager.afterCompleteOperations(new IOCallback() {
               @Override
               public void onError(final int errorCode, final String errorMessage) {
                  ActiveMQServerLogger.LOGGER.errorProcessingIOCallback(errorCode, errorMessage);
      
                  ActiveMQExceptionMessage exceptionMessage = new ActiveMQExceptionMessage(ActiveMQExceptionType.createException(errorCode, errorMessage));
      
                  doConfirmAndResponse(confirmPacket, exceptionMessage, flush, closeChannel);
      
                  if (logger.isTraceEnabled()) {
                     logger.trace("ServerSessionPacketHandler::exception response sent::" + exceptionMessage);
                  }
      
               }
      
               @Override
               public void done() {
                  if (logger.isTraceEnabled()) {
                     logger.trace("ServerSessionPacketHandler::regular response sent::" + response);
                  }
      
                  doConfirmAndResponse(confirmPacket, response, flush, closeChannel);
               }
            });
         }
      

      It is odd that the callback wasn't never triggered. This assumption confirms the warning printed at stopping of the server. In the OperationContext, there were still some callbacks which weren't triggered.

      06:22:41,377 WARN  [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 124) AMQ222105: Could not finish context execution in 10 seconds: java.lang.Exception: warning
              at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.waitContextCompletion(ServerSessionImpl.java:1141) [artemis-server-1.5.5.006-redhat-1.jar:1.5.5.006-redhat-1]
              at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.closeAllServerSessions(ActiveMQServerImpl.java:1103) [artemis-server-1.5.5.006-redhat-1.jar:1.5.5.006-redhat-1]
              at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:888) [artemis-server-1.5.5.006-redhat-1.jar:1.5.5.006-redhat-1]
              at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:793) [artemis-server-1.5.5.006-redhat-1.jar:1.5.5.006-redhat-1]
              at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStop(ActiveMQServerImpl.java:688) [artemis-server-1.5.5.006-redhat-1.jar:1.5.5.006-redhat-1]
              at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:681) [artemis-server-1.5.5.006-redhat-1.jar:1.5.5.006-redhat-1]
              at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.stop(JMSServerManagerImpl.java:433) [artemis-jms-server-1.5.5.006-redhat-1.jar:1.5.5.006-redhat-1]
              at org.wildfly.extension.messaging.activemq.jms.JMSService.doStop(JMSService.java:217) [wildfly-messaging-activemq-7.1.0.GA-redhat-4.jar:7.1.0.GA-redhat-4]
              at org.wildfly.extension.messaging.activemq.jms.JMSService.access$100(JMSService.java:64) [wildfly-messaging-activemq-7.1.0.GA-redhat-4.jar:7.1.0.GA-redhat-4]
              at org.wildfly.extension.messaging.activemq.jms.JMSService$2.run(JMSService.java:121) [wildfly-messaging-activemq-7.1.0.GA-redhat-4.jar:7.1.0.GA-redhat-4]
              at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_131]
              at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
              at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
              at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final-redhat-1.jar:2.2.1.Final-redhat-1]
      

      In the attachment you can find also thread dumps from the server. I didn't find there any deadlocks.

        1. server-2-thread-dumps.zip
          188 kB
        2. server-2.log
          2.22 MB
        3. server-2-trace.log.7z
          5.40 MB
        4. server-1-logs.zip
          11.99 MB
        5. server-2-trace.log.1.7z
          14.56 MB
        6. server-2-trace.log.2.7z
          14.39 MB
        7. test-trace.log.7z
          1.22 MB
        8. test.log
          2.97 MB

              mtaylor1@redhat.com Martyn Taylor (Inactive)
              eduda_jira Erich Duda (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Created:
                Updated:
                Resolved: