Message Expiration Problem

[rkbeach]

Hi All,

I am pretty sure someone has experienced this kind of a problem....we are running JBoss 3.2.1 server on solaris 2.8...

In the standardjboss.xml, the message driven bean pool is set to 15. When we get to a point where 15 messages expire, the MDB's do not pick up any more messages...and the queue size keeps growing...only after removing all these messages which have been
persisted (we are using file persistence) AND bouncing the server, we can get the MDB's
to start consuming messages again...

I changed the MDB pool to 20. Now, when 20 messages expire (I could see 20 'I dropped a message'entries in the log file), the MDB's do not pick up any more messages...only after removing the
persisted messages (as soon as the number of expired messages hits 20, the messages start getting written to disk) and bouncing the server, MDB's start consuming messages...

I turned TRACE on, but didn't see any error messages...

Can anyone please help?

Vishy

[adrian.brock]

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
delivery.

Regards,
Adrian

[rkbeach]

Hi Adrian,

Thanks much for your reply!!

I will try 3.2.2 and see if I can get this problem resolved.

Regards,
Vishy

[rkbeach]

Hi Adrian,

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...

Thanks much!
Vishy

[kristoff]

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.

[adrian.brock]

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.

Regards,
Adrian