Error acknowledging message AUTO_ACKNOWLEDGE DUPS_OK_ACKNOWLEDGE mode

Error acknowledging message AUTO_ACKNOWLEDGE DUPS_OK_ACKNOWLEDGE mode

While working with JMS if you see below warning:

Aug 26, 2016 9:46:04 AM com.solacesystems.jms.impl.MessageAckHandlerImpl acknowledge
WARNING: Error acknowledging message – in AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE mode

Solution: This happens if you are using non durable topic and try to acknowledge the message to the server.

To fix the issue please use: Client-acknowledge mode

JMS Acknowledgment Modes:
JMS session acknowledgement modeS determines way application handles exchange of acknowledgement information when receiving messages from a broker. Below are possible acknowledgement modes:

Auto-acknowledge mode: Message Queue client runtime immediately sends client acknowledgement for each message it delivers to message consumer. It then blocks waiting for a return broker acknowledgement confirming client has received and done acknowledgement. In this type of acknowledgement handshake between broker and client broker is handled automatically by client runtime system and no need to take explicit.

Client-acknowledge mode: Client application must explicitly do acknowledgement of receipt for messages it received. It allows to defer acknowledgement until after you had finished processing message and ensuring broker not delete from persistent storage until processing is complete. You could acknowledge each message individually or in a batch of multiple messages then acknowledgement all together. Client acknowledgement send to broker applies to all messages received since previous acknowledgement.

Dups-OK-acknowledge mode: Session automatically sends client acknowledgement each time it has received of fixed number of messages. When fixed time interval been elapsed when last acknowledgement was sent. ()Please note: The fixed batch size and time-out interval are currently 10 messages & 7 seconds respectively these are not configurable from client.) As first two modes described above broker doesn’t acknowledge receipt of client acknowledgement & session thread doesn’t block awaiting return acknowledgement from broker. It means you have no way to confirm about your acknowledgement has been received. Suppose it is lost in the transmission then broker may redeliver exact same message more than once. Because client acknowledgements are batched also session thread doesn’t block. Applications which can tolerate multiple delivery of same message can achieve higher throughput in this mode than in auto acknowledgement OR client acknowledgement mode.

Message Queue if extends JMS specification by adding then you could use below acknowledgement mode:

No-acknowledge mode: Client application doesn’t do acknowledgement of messages nor does broker expect any such acknowledgement. So that no guarantee whatsoever that any message sent through broker been successfully received. If you use this mode then sacrifices all reliability for sake of maximum throughput of message traffic.

int  ackMode = mySession.getAcknowledgeMode();
switch (ackMode)
  {
    case Session.AUTO_ACKNOWLEDGE:
      /* Code here to handle auto-acknowledge mode */
      break;
    case Session.CLIENT_ACKNOWLEDGE:
      /* Code here to handle client-acknowledge mode */
      break;
    case Session.DUPS_OK_ACKNOWLEDGE:
      /* Code here to handle dups-OK-acknowledge mode */
      break;
    case com.sun.messaging.jms.Session.NO_ACKNOWLEDGE:
      /* Code here to handle no-acknowledge mode */
      break;
  }

For more information please visit this link