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?