-
1. Re: Lost or forgotten messages in queue
genman Aug 17, 2004 3:07 PM (in response to logicacmg-phoenix)
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. -
2. Re: Lost or forgotten messages in queue
maitaibernie Aug 18, 2004 3:27 AM (in response to logicacmg-phoenix)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?
-
3. Re: Lost or forgotten messages in queue
jardia Aug 18, 2004 7:50 AM (in response to logicacmg-phoenix)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?). -
4. Re: Lost or forgotten messages in queue
adrian.brock Aug 20, 2004 12:41 PM (in response to logicacmg-phoenix)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.