You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Jason Whaley (JIRA)" <ji...@apache.org> on 2011/08/10 15:51:27 UTC

[jira] [Created] (AMQ-3444) Fail Fast or Warn on using fileCursors/fileQueueCursors when 

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


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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (AMQ-3444) Fail Fast or Warn on using fileCursors/fileQueueCursors when

Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
     [ 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