Consumer released before TX commit on APLO-218

[Christian Posta <ch...@gmail.com>]

APLO-218 has a perl test case that demonstrates a bug handling tx commits
after a consumer has been unsubscribed.

Here are the effective steps his test case takes:

1) consumer subscribe to "queue"

2) consumer begin tx

3) producer.send to "queue"

4) consumer receive and ack

5) consumer unsubscribe

6) consumer commit tx


After step 5, the callback to the consumer's AckHandler will fail because
when the consumer closes itself after all the "release" calls are made on
it (last one looks to be in the Subscription.close call), it will close its
ack_handler, which sets its consumer_acks to null. When the transaction
tries to call the "perform_ack" as a closure, it fails because there is an
assert in perform_ack to make sure there are consumer_acks.

I looked at how ActiveMQ handles this same case, but it seems the
destination subscriptions and the "StompSubscriptions" are treated
differently. The ProtocolHandler keeps around the StompSubscription even
after a unsubscribe call, so that a transaction still sees what messages
were left unacked. I could be off a little, but I think that's what I saw.

Any quick suggestions?

Re: Consumer released before TX commit on APLO-218

[Hiram Chirino <hi...@hiramchirino.com>]

Try doing a consumer.retain() when a transacted ACK is received, and
then consumer.release() once it's committed or rolled back.  That should
avoid the consumer from closing out before TX outcome is resolved.

On Fri, Jul 20, 2012 at 1:53 PM, Christian Posta
<ch...@gmail.com>wrote:

> APLO-218 has a perl test case that demonstrates a bug handling tx commits
> after a consumer has been unsubscribed.
>
> Here are the effective steps his test case takes:
>
> 1) consumer subscribe to "queue"
>
> 2) consumer begin tx
>
> 3) producer.send to "queue"
>
> 4) consumer receive and ack
>
> 5) consumer unsubscribe
>
> 6) consumer commit tx
>
>
> After step 5, the callback to the consumer's AckHandler will fail because
> when the consumer closes itself after all the "release" calls are made on
> it (last one looks to be in the Subscription.close call), it will close its
> ack_handler, which sets its consumer_acks to null. When the transaction
> tries to call the "perform_ack" as a closure, it fails because there is an
> assert in perform_ack to make sure there are consumer_acks.
>
> I looked at how ActiveMQ handles this same case, but it seems the
> destination subscriptions and the "StompSubscriptions" are treated
> differently. The ProtocolHandler keeps around the StompSubscription even
> after a unsubscribe call, so that a transaction still sees what messages
> were left unacked. I could be off a little, but I think that's what I saw.
>
> Any quick suggestions?
>



-- 

**

*Hiram Chirino*

*Software Fellow | FuseSource Corp.*

*chirino@fusesource.com | fusesource.com*

*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*

*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*

*
*

*
*