activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From " (JIRA)" <>
Subject [jira] Created: (AMQ-1080) hasSpace call looks like it may cause messages to be skipped
Date Fri, 01 Dec 2006 02:00:02 GMT
hasSpace call looks like it may cause messages to be skipped

                 Key: AMQ-1080
             Project: ActiveMQ
          Issue Type: Bug
          Components: Broker
    Affects Versions: 4.2.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.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message