This has been fixed for 3.2.2
There was a bug where message consumer didn't go back to
the server after it encountered an expired message.
We have also added processing so that the server expires
messages, rather than waiting for the client to check it at
Thanks much for your reply!!
I will try 3.2.2 and see if I can get this problem resolved.
Looks as if this bug has indeed been fixed in 3.2.2
I have been using 3.2.2 RC4, and I could see that my problem has been resolved...
But, this still begs the question as to why 3.2.1 is still posted as "Download JBoss 3.2.1 for Production"
We have had so many problems with JMS under 3.2.1 that it's a joke.
First, there's the whole HSQL bug where it wont release TCP/IP connections. Now this. How can 3.2.1 possibly be seen as "fit for production?" It should be pulled.
What has hsqldb got to do with message expiration?
The hsqldb bug you refer to is a joke in itself.
To suffer from it you have to make the following mistakes:
1) Use hsqldb - it is toy used for testing - we recommend
using a real database. Why would you keep it installed
using threads and sockets if you don't use it?
2) Not change the password for the system administator
"sa" in hsqldb
3) Install jboss directly on the internet and not check what
ports are open.
If you do this, I would guess you also leave
http://yourhost:8080/jmx-console unprotected as well.
Which is a lot easier to use to control the jboss server than
figuring out how to invoke native commands using hsqldb.