Resolution:
When a queue receiver with explicit acknowledge mode receives a message with the JMSExpiration header, and the JMS_TIBCO_PRESERVE_UNDELIVERED property is set before the messages expires but acknowledges after the message has expired, the message will be moved to the $sys.undelivered queue.

If this property is not set then the message will be removed by the EMS server. This behavior, where the message has been received but not ACK’d, is the same as when sending a message with an “expiration” set to a queue and there are no consumers on the queue to pick it up. The EMS server does not log any error or warning message in this situation. However, if you have the ”trace” property enabled for the message or the queue, you can easily check what  happened to the message. In such situations, the client application receives an exception when it tries to ACK the receiver that no longer exists. In Java, you will see the following exception at the receiving client side:

javax.jms.IllegalStateException: Attempt to acknowledge message(s) not valid for this consumer
        at com.tibco.tibjms.Tibjmsx.buildException(Tibjmsx.java:565)
        at com.tibco.tibjms.TibjmsxSessionImp._confirmNonTransacted(TibjmsxSessionImp.java:3403)
        at com.tibco.tibjms.TibjmsxSessionImp._confirm(TibjmsxSessionImp.java:3503)
        at com.tibco.tibjms.TibjmsxSessionImp._confirmNonAuto(TibjmsxSessionImp.java:4811)
        at com.tibco.tibjms.TibjmsMessage.acknowledge(TibjmsMessage.java:608)
        at tibjmsQueueReceiver.<init>(tibjmsQueueReceiver.java:117)
        at tibjmsQueueReceiver.main(tibjmsQueueReceiver.java:131)

Your application needs to handle this exception appropriately in your code.

When a queue receiver with explicit ACK mode receives a message with the JMSExpiration header, and the JMS_TIBCO_PRESERVE_UNDELIVERED property is set before messages expiry but acknowledges after expiry, the message will be moved to the $sys.undelivered queue.