JMS setTimeToLive

The JMS specification does not require the provider to ever delete the message. Some providers delete expired messages rather quickly. Some do not delete them until a browse or get operation evaluates the message for expiry. Some will arbitrarily delete messages every so often regardless of whether a client has attempted to browse or get them. Keeping a background task alive to delete expired messages quickly obviously consumes resources so most providers will opt for some degree of "lazy" expiration.

Interestingly, the JMS specification also states that "clients should not receive messages that have expired; however, JMS does not guarantee that this will not happen." Most providers do a good job of preventing expired messages from being delivered but this is not a hard requirement.

So the answer is that although seeing the message in the DB or on a queue/topic after expiry may not be intuitive as the "expected" behavior, it is within the spec. The more important question is whether said message is delivered to your application or not. Hopefully it is not - but even if it is, the spec does not rule this out.

Your Publisher/Subscriber should be coded in such a way to discard the expired messages as per the JMS specification. There is no guareente that the message is removed from the queue after it expires.

Hi TTL also depends on configuration of application of Application Server, If you are using Jboss 6 then its internally using HornetQ for JMS, Hence some configuration are needed in standalone-full.xml for TTL to be working effectively.

message-expiry-scan-period, max-delivery-attempts that need to be configured in order to make TTL working.