activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <hi...@hiramchirino.com>
Subject Re: Consumer released before TX commit on APLO-218
Date Fri, 20 Jul 2012 17:59:02 GMT
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
<christian.posta@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/>*

*
*

*
*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message