[ 
https://issues.apache.org/activemq/browse/AMQ-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Davies resolved AMQ-1080.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 5.0.0

Fixed by SVN revision 560783

> hasSpace call looks like it may cause messages to be skipped
> ------------------------------------------------------------
>
>                 Key: AMQ-1080
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1080
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.0.0
>            Reporter: [EMAIL PROTECTED]
>            Assignee: Rob Davies
>             Fix For: 5.0.0
>
>
> DefaultJDBCAdapter makes calls back to 
> JDBCMessageRecoveryListener.recoverMessage.  This is done in a loop and the 
> loop unconditionally goes through the messages until the end of the ResultSet 
> or the specified maximum is processed.  However JDBCMessageStore's 
> implementation of the listener can "ignore" the message if a call to hasSpace 
> fails.  However, nothing tells the calling loop to stop, so there are two 
> issues:
> 1.  The loop keeps running, which is slightly inefficient (could be more than 
> slightly for non-JDBC stores).
> 2.  If hasSpace suddenly reports it has space during this loop, messages have 
> been skipped and the sequence ID is set after the point so those skipped 
> messages are not going to be recovered.
> At first glance, it looks like the Kaha store is written better, but it might 
> be a good idea to make recoverMessage / recoverMessageReference (in 
> RecoveryMessageListener) return a boolean and ensure that the loop is 
> terminated in the event that False was returned.  As currently written, there 
> seems to be no "air tight" way for recovery to fail gracefully, maybe 
> throwing an exception is "safe" and does all that is needed but I'm not sure.
> As a separate, related issue, suppose the hasSpace eventually returns False, 
> as this can be due to a usageManager reporting that there is no space.  
> Suppose that all the space is used by consumers other than one specific one.  
> What "prods" the messages to begin flowing again to that one consumer once 
> the UsageManager indicates that space is available?

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

Reply via email to