Lost or forgotten messages in queue

[logicacmg-phoenix]

Hi,

using JBoss 3.0.5 in production we have a problem concerning messages which are physically present in the queue (db/jbossmq/file/Q_xxx), however the client is unable to receive some of them. Eg. there are 10 messages/files in the queue, but only some of them (some of the newer ones) get delivered. When we check the attribute QueueDepth of the StateManager MBean it says that QueueDepth is 5 even though it should be 10, right?!

Is there a quick way to fix this in 3.0.5? Trying to redeploy the queue or touching the messages in the queue yielded no results. The messages are stuck in the queue so to speak. Unfortunately we can't upgrade to a newer release of JBoss where this bug might be resolved.

Thanks a lot!

[genman]

The queue depth only includes messages not yet delivered to JMS consumers. If you have client connections open (say, 5), then those 5 messages are considered in transit.

You should use the JDBC persistence manager rather than the file one.

[maitaibernie]

Is JDBC persistence more reliable than the file persistence manager or why, in your opinion, show they prefer JDBC persistence? If you say "The queue depth only includes messages not yet delivered to JMS consumers" do you think that JBoss behaves right saying QueueDepth is five (meaning 5 messages already delivered to the client), although there are 10 msgs in the queue physically? Or are you saying the file persistence manager is buggy?

[jardia]

Just a few references to the file persistence manager.
Adrian (JBossMQ lead) says that the file persistence manager is not supported anymore and that it is only there for backward compatibility with 2.4.

http://www.jboss.org/index.html?module=bb&op=viewtopic&t=43492
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48381

There are problems with the file persistence manager. I think one of the causes is that it is not transactionally reliable. This is because not all JVMs guarantee that when a call to flush() returns, that the data is actually on disc...
I think that there are also scalability issues with file persistence (max no of files in one dir on windows, startup times?).

[adrian.brock]

Yes there are two problems with the file persistence managers.

1) They do not guarantee the data is flushed to the physical disk,
it could still be held in OS buffers.

2) They have no checksum so it is impossible to detect data corruption.