Major Description
When working with a broker config for a client, we attempted to use fileCursors and fileQueueCursors on all destinations. What we noticed when monitoring JMX for specific queues was behavior of vmCursors. Once the memoryLimit for an individual destination hit 100%, the broker then tried to spool the messages to disk but instead failed and the following exceptions were written to log:
2011-08-09 13:50:22,892 [Usage Async Task ] ERROR FilePendingMessageCursor - Caught an IO Exception getting the DiskList 315_PendingCursor:FLEXNET-RX-REALTIME-QUEUE
java.lang.NullPointerException
at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.getDiskList(FilePendingMessageCursor.java:454)
at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.flushToDisk(FilePendingMessageCursor.java:432)
at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.onUsageChanged(FilePendingMessageCursor.java:385)
at org.apache.activemq.usage.Usage$1.run(Usage.java:268)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
After eyeing the config a little more we noticed that <broker persistent="false">. Turning that back to "true" caused messages to spool to disk as expected.
This was obviously a misconfiguration, but there was no warning or indication that our configuration was basically invalid and destined to fail. At a minimum it would be useful to have a message at WARN log level that states that fileCursor/fileQueueCursors will fail if <broker persistent="false">.
Attachments
Issue Links
- is duplicated by
-
AMQ-3912 Durable subs store messages in error with broker attribute persistent="false"
-
- Resolved
-