When a transaction rollback/recover occurs on the 0-8/0-9/0-91 code path the messages are put back on to the queue but the subscriber is not credited for them. This can be seen with a small prefetch. The credit is lost and the client starves. Adding a restoreCredit call in the message release will address this issue.
The same issue exists in 0-10 code path but for different reasons. On 0-10, a client is required to complete commands. The Java client currently fails to complete the message.transfer commands that correspond to those messages that must be returned to the Broker due to the rollback/recover and for this reason the Brokers are failing to recredit. This problem is evident when using the Java Broker, but is masked when using the CPP Broker (by a credit window issue that results in the Broker expanding credit window beyond the requested limit).