3 Replies Latest reply on Apr 22, 2004 7:24 AM by adrian.brock

    Duplicate key in JMS_MESSAGES

    kevindaly
    kevindaly Apr 22, 2004 6:04 AM

      Hi,

      We are experiencing the below exception on our JBoss 3.2.1 Server. Other messages in the forum have attributed this exception to having
      more than one JBoss instance interacting with the JMS_Messages file, this
      is not the case on our production server.

      Could someone articulate what the .-2147483616 (see exception trace) in TOPIC.GPRS.KermitMessageClient.-2147483616 refers to. We have
      a KermitMessageClient destination configured within JMS but the
      "temporary" destinations are continually appearing in the messages file
      and are the source of the exception. We have never seen any contention
      on the actual KermitMessageClient destination.

      The message

      http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48760

      seems very like the problem we are experiencing, could it be the same
      bug.

      We are considering deleting the temporary destination from the production
      database but are reluctant to do so until we know what these destinations
      refer to.

      The system has been in production for several months now and the error is getting increasingly frequent which again is somethinh we don't understand, the application code has been very stable in that time.

      Regards.

      - Kevin.

      2004-04-21 10:03:35,968 [MessageListenerThread - GPRS] ERROR com.celtrak.jms.Publisher - org.jboss.mq.SpyJMSException: Could not store message: 142010 msg=78714 hard NOT_STORED PERSISTENT queue=TOPIC.GPRS.KermitMessageClient.-2147483616 priority=4 hashCode=12204633; - nested throwable: (java.sql.SQLException: [Microsoft][SQLServer JDBC Driver][SQLServer]Violation of PRIMARY KEY constraint 'PK__JMS_MESSAGES__095F58DF'. Cannot insert duplicate key in object 'JMS_MESSAGES'.)
      2004-04-21 10:03:35,968 [MessageListenerThread - GPRS] ERROR com.celtrak.jms.Publisher - org.jboss.mq.pm.jdbc2.PersistenceManager.saveToStorage(PersistenceManager.java:1164)
      org.jboss.mq.server.MessageCache.saveToStorage(MessageCache.java:411)
      org.jboss.mq.server.MessageReference.makeSoft(MessageReference.java:229)
      org.jboss.mq.server.MessageCache.validateSoftReferenceDepth(MessageCache.java:354)
      org.jboss.mq.server.MessageCache.addInternal(MessageCache.java:133)
      org.jboss.mq.server.MessageCache.add(MessageCache.java:102)
      org.jboss.mq.server.JMSTopic.addMessage(JMSTopic.java:282)
      org.jboss.mq.server.JMSDestinationManager.addMessage(JMSDestinationManager.java:404)
      org.jboss.mq.server.JMSDestinationManager.addMessage(JMSDestinationManager.java:384)
      org.jboss.mq.server.JMSServerInterceptorSupport.addMessage(JMSServerInterceptorSupport.java:135)
      org.jboss.mq.security.ServerSecurityInterceptor.addMessage(ServerSecurityInterceptor.java:162)
      org.jboss.mq.server.TracingInterceptor.addMessage(TracingInterceptor.java:234)
      org.jboss.mq.server.JMSServerInvoker.addMessage(JMSServerInvoker.java:137)
      org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:86)
      org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:355)
      org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:377)
      EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:732)
      java.lang.Thread.run(Thread.java:536)

      2

      • 3712 Views
      • Tags:
        • 1. Re: Duplicate key in JMS_MESSAGES
          adrian.brock Apr 22, 2004 6:18 AM (in response to kevindaly)

          There is a bug in 3.2.1 (fixed in 3.2.3) where messages left in temporary destinations
          were not getting deleted. They would likely end up in the cache store with a
          TX_OP of 'T'.
          A server restart should delete them, it deletes all 'T'=temporary records
          during the recovery process.

          Which part is not working for you?

          Regards,
          Adrian

            • Actions
          • 2. Re: Duplicate key in JMS_MESSAGES
            kevindaly
            kevindaly Apr 22, 2004 7:05 AM (in response to kevindaly)

            Adrian,

            We have another crash this morning which forced our hand and we deleted the "temporary destinations". The systems is running for
            1 hour so far and we have seen no "temporary destinations" created
            yet. We will monitor the server and try and get an answer to your
            question. Our experience was that temporary records were surviving
            restarts, though I am not sure what the TX_OP field were.

            Do entries in the JMS_Message file such as TOPIC.GPRS.KermitMessageClient.-2147483616 refer to Temporary subscribers and when are they created.

            Currently our Application restarts when we experience this exception, is
            this overkill or can the JMS Persistance Manager eventually recover from
            these exceptions.

            Thanks,
            Kevin.

              • Actions
            • 3. Re: Duplicate key in JMS_MESSAGES
              adrian.brock Apr 22, 2004 7:24 AM (in response to kevindaly)

              The symptoms you report are exactly the problem that was fixed in 3.2.3

              1) Start a client VM - and connect using a ClientID
              2) Send messages to a temporary queue/topic but don't receive them
              3) Don't close the connection properly, leaving the server to try to tidy up for you
              (it does not - it doesn't delete the messages in the temporary queue)
              4) Repeat from (1)

              The other part to reproduce the problem is that the message cache must have
              softened the undeleted temporary messages into the db. i.e. at some point
              JBossMQ thought you were running low on memory.

              If this is not your problem (try it on 3.2.3), then please include an analysis
              similar to what I have done above.

              The persistence manager cannot recover from the problem. Everytime you
              start a client (new VM) with the same client id, it will try to use the same
              key for the temporary destinations, but there are still records lying around from
              the previous client to confuse it.

              TOPIC.GPRS.KermitMessageClient.-2147483616

              Means:
              [DestinationType.Name.SubscriptionID.ClientVMsConnectionNumber]

                • Actions