activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Davies (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (AMQ-1080) hasSpace call looks like it may cause messages to be skipped
Date Mon, 23 Jul 2007 10:45:49 GMT

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

Rob Davies reassigned AMQ-1080:
-------------------------------

    Assignee: Rob Davies

> 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: jk@penguinsfan.com
>            Assignee: Rob Davies
>
> 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.


Mime
View raw message