You might want to check that you don't have clock skew between your client and server.
For instance if your client's clock says that it's 13:24:00 and your server's clock says that it's 13:22:45. It's only a two minute difference, and something you wouldn't normally notice. But in the case of a JMS message with a 1000ms ttl. The message is sent, and at that time currentTime+1000 is put in the timeout field. So the message is told to timeout at 13:24:01. Well when it get's to the server, the server will wait until it's clock reaches 13:24:01, which is much longer than the 1 second you thought it would take.
I'd recommend using a network time daemon like ntp to keep all your machine's clocks synched.
I also thought about that, but I used a Qeueu Browser
to look at the message and compare their expiry
time with the current time on the server and it
does not expire. Time expiry time is earlier than
the current time on the server but when I re-query
the queue, the message is still there. I made
very sure about that, that is why I think that
there is a bug in SpyderMQ
Any other suggestions?
Instead of using a QueueBrowser try and recieve an expired message. I have had the feeling in the past that expired messages might not immediatly get removed from the queue. However these messages are not delivered. JBoss may come around later and clean these messages up in a separate thread. There could be a bug that allows you to view them in a QueueBrowser. I don't know. I'm not a JBoss developer.
See if you can send a message to a server. Then wait for it to expire and then try and get that message back. In my experiance it won't come back, but still might not immediatly get expunged from the server.