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