Uploaded image for project: 'ActiveMQ Classic'
  1. ActiveMQ Classic
  2. AMQ-9252

java.lang.NoSuchMethodError: 'void javax.jms.Message.setJMSDeliveryTime(long)'

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 5.18.0
    • None
    • JMS client
    • None
    • ActiveMQ 5.18.0

      OpenJDK 11

       

    Description

      Getting this exception starting in 5.18:

       

      WARN  JMSConnection - Could not send keep alive for openunisuron-tasks-1, recreating

      java.lang.NoSuchMethodError: 'void javax.jms.Message.setJMSDeliveryTime(long)'

              at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1993) ~[activemq-client-5.18.0.jar:5.18.0]

              at org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:329) ~[activemq-client-5.18.0.jar:5.18.0]

              at org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:289) ~[activemq-client-5.18.0.jar:5.18.0]

              at org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:224) ~[activemq-client-5.18.0.jar:5.18.0]

              at org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:270) ~[activemq-client-5.18.0.jar:5.18.0]

              at com.tremolosecurity.provisioning.jms.JMSConnection$2.sendKeepAliveMessage(JMSConnection.java:158) [unison-sdk-1.0.34.jar:?]

              at com.tremolosecurity.provisioning.jms.JMSConnection$2.run(JMSConnection.java:129) [unison-sdk-1.0.34.jar:?]

              at java.lang.Thread.run(Thread.java:829) [?:?]

       

      this seems to be introduced from https://github.com/apache/activemq/commit/ead9533d5300fb2b5c48cfe70ef8b8fd84f46feb

       

      this error is not consistent, it comes up randomly.  Some runs, there are no issues but others this error happens.

      Attachments

        Activity

          robbie Robbie Gemmell added a comment -

          This almost certainly means the JMS 1.1 API is on the classpath and taking precedence, perhaps shifting position on the classpath between runs to explain the variation, and that the new partial-JMS-2.0 client isnt handling that while sending one of its own 2.0 messages, as it tried to call Message.setJMSDeliveryTime(long), which doesnt exist on the old Interface and so the JVM threw when the method wasnt found at runtime.

          The application should really avoid getting into this situation. The client can also be tweaked so it handles it though.

          robbie Robbie Gemmell added a comment - This almost certainly means the JMS 1.1 API is on the classpath and taking precedence, perhaps shifting position on the classpath between runs to explain the variation, and that the new partial-JMS-2.0 client isnt handling that while sending one of its own 2.0 messages, as it tried to call Message.setJMSDeliveryTime(long), which doesnt exist on the old Interface and so the JVM threw when the method wasnt found at runtime. The application should really avoid getting into this situation. The client can also be tweaked so it handles it though.

          > This almost certainly means the JMS 1.1 API is on the classpath and taking precedence

          Yes, looking at the classpath both JMS 1.1 and 2.0 libraries are there.  It looks like the activemq client changed including it themselves from 5.17.1 --> 5.18.0. 

          > The application should really avoid getting into this situation. The client can also be tweaked so it handles it though.

          Dropping support for JMS 1.1 seems like much more then a point release change.  

          mlbiam Marc Boorshtein added a comment - > This almost certainly means the JMS 1.1 API is on the classpath and taking precedence Yes, looking at the classpath both JMS 1.1 and 2.0 libraries are there.  It looks like the activemq client changed including it themselves from 5.17.1 --> 5.18.0.  > The application should really avoid getting into this situation. The client can also be tweaked so it handles it though. Dropping support for JMS 1.1 seems like much more then a point release change.  
          robbie Robbie Gemmell added a comment -

          JMS 2.0 incorporates all the JMS 1.1 APIs so support wasnt exactly 'dropped', its just that in this case you have mixed in the actual 1.1 API jar and the new impl isnt tolerant of that, though it could be made to be so with some changes.

          Simply remove the 1.1 spec jar for now and that will fix things. An application built against 1.1 will still work with the new (/10 year old) 2.0 spec jar.

          robbie Robbie Gemmell added a comment - JMS 2.0 incorporates all the JMS 1.1 APIs so support wasnt exactly 'dropped', its just that in this case you have mixed in the actual 1.1 API jar and the new impl isnt tolerant of that, though it could be made to be so with some changes. Simply remove the 1.1 spec jar for now and that will fix things. An application built against 1.1 will still work with the new (/10 year old) 2.0 spec jar.

          People

            Unassigned Unassigned
            mlbiam Marc Boorshtein
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: