You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Timothy Bish (JIRA)" <ji...@apache.org> on 2012/07/31 20:12:34 UTC
[jira] [Closed] (AMQ-3444) Fail Fast or Warn on using
fileCursors/fileQueueCursors when
[ https://issues.apache.org/jira/browse/AMQ-3444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish closed AMQ-3444.
-----------------------------
Resolution: Duplicate
Fix Version/s: 5.7.0
This is resolved by AMQ-3912
> Fail Fast or Warn on using fileCursors/fileQueueCursors when <broker persistent="false">
> ----------------------------------------------------------------------------------------
>
> Key: AMQ-3444
> URL: https://issues.apache.org/jira/browse/AMQ-3444
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
> Affects Versions: 5.5.0
> Reporter: Jason Whaley
> Fix For: 5.7.0
>
>
> 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">.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira