You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Bastiaan Bakker (JIRA)" <ji...@apache.org> on 2008/09/18 11:29:52 UTC

[jira] Created: (AMQ-1943) hasSpace call looks like it may cause messages to be skipped (AMQ-1080 has not been applied for queues)

hasSpace call looks like it may cause messages to be skipped (AMQ-1080 has not been applied for queues)
-------------------------------------------------------------------------------------------------------

                 Key: AMQ-1943
                 URL: https://issues.apache.org/activemq/browse/AMQ-1943
             Project: ActiveMQ
          Issue Type: Bug
          Components: Message Store
    Affects Versions: 5.2.0, 5.1.0
            Reporter: Bastiaan Bakker


SVN revision 560783 modifies only 1 of the 2 DefaultJDBCAdapater.doRecoverNextMessages() methods to break from the loop if the listener.recoverMessage() returns false. The doRecoverNextMessages for queues just logs it at debug level.
Shouldn't that method break from the loop too? I'm seeing the same problems described in AMQ-1080 with the queues on our test and production servers: 
1) lots of ' Stopped recover next messages' messages and CPU usage going way up
2) messages being skipped



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Assigned: (AMQ-1943) hasSpace call looks like it may cause messages to be skipped (AMQ-1080 has not been applied for queues)

Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/AMQ-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rob Davies reassigned AMQ-1943:
-------------------------------

    Assignee: Rob Davies

> hasSpace call looks like it may cause messages to be skipped (AMQ-1080 has not been applied for queues)
> -------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-1943
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1943
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Message Store
>    Affects Versions: 5.1.0, 5.2.0
>            Reporter: Bastiaan Bakker
>            Assignee: Rob Davies
>
> SVN revision 560783 modifies only 1 of the 2 DefaultJDBCAdapater.doRecoverNextMessages() methods to break from the loop if the listener.recoverMessage() returns false. The doRecoverNextMessages for queues just logs it at debug level.
> Shouldn't that method break from the loop too? I'm seeing the same problems described in AMQ-1080 with the queues on our test and production servers: 
> 1) lots of ' Stopped recover next messages' messages and CPU usage going way up
> 2) messages being skipped

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (AMQ-1943) hasSpace call looks like it may cause messages to be skipped (AMQ-1080 has not been applied for queues)

Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/AMQ-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rob Davies resolved AMQ-1943.
-----------------------------

    Fix Version/s: 5.3.0
       Resolution: Fixed

Fixed by SVN revision 697953

> hasSpace call looks like it may cause messages to be skipped (AMQ-1080 has not been applied for queues)
> -------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-1943
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1943
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Message Store
>    Affects Versions: 5.1.0, 5.2.0
>            Reporter: Bastiaan Bakker
>            Assignee: Rob Davies
>             Fix For: 5.3.0
>
>
> SVN revision 560783 modifies only 1 of the 2 DefaultJDBCAdapater.doRecoverNextMessages() methods to break from the loop if the listener.recoverMessage() returns false. The doRecoverNextMessages for queues just logs it at debug level.
> Shouldn't that method break from the loop too? I'm seeing the same problems described in AMQ-1080 with the queues on our test and production servers: 
> 1) lots of ' Stopped recover next messages' messages and CPU usage going way up
> 2) messages being skipped

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.