You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Murphy Meng <mu...@mirriad.com.INVALID> on 2018/11/15 15:36:54 UTC
Ack now or too lat - weird behaviour of transaction on ActiveMQ over
stomp
I use stomp (1.2) to connect to ActiveMQ (5.15). It is a Python client and stomp.py library is employed. A transaction begins when one message is received, the client does some processing then acknowledge the message, then commit the transaction. Such loop starts over when a new message is received.
There is a scenario where I found the problem. There could be more then one messages are received before the transaction begin-process-ack-commit loop. And such loops handle only one message in one go. What is the issue? The second message received earlier will not be acknowledged at all.
Pseudo code:
>>class mylistener:
>> def on_message(self, header, body):
>> print(‘get message %s’, header[‘ack’])
>>conn.set_listener(‘listener1’, mylistener());
>>conn.subscribe(destination=‘queue1', id=1, ack=‘client-individual’)
>>get message ID:03367ac6c23d-44027-1542285031966-10:1
>>get message ID:03367ac6c23d-44027-1542285031966-10:2
>>txid1 = conn.begin()
>>conn.ack(‘ID:03367ac6c23d-44027-1542285031966-10:1’, txid1)
>>conn.commit(txid1)
>>txid2 = conn.begin()
>>conn.ack(‘ID:03367ac6c23d-44027-1542285031966-10:1’, txid2)
>>conn.commit(txid2)
At this point, the second message is not acknowledged at all. You will find out it stays in the queue and will not be redelivered (if the client is not disconnected).
Anyone can tell me is this designed? I don’t see any statement like this in stomp spec. It looks quite problematic for me.
Best regards,
Murphy Meng
Sent from Polymail<https://polymail.io/?utm_source=polymail&utm_medium=referral&utm_campaign=signature>
Murphy Meng
API Software Developer
murphy.meng@mirriad.com /
96 Great Suffolk Street, London, SE1 0BE, GB
[https://www.mirriad.com/wp-content/uploads/2018/06/Logo.jpg]<https://www.mirriad.com>[https://www.mirriad.com/wp-content/uploads/2018/06/Social_LinkedIn.jpg]<http://www.linkedin.com/company/mirriad>[https://www.mirriad.com/wp-content/uploads/2018/06/Social_Twitter.jpg]<http://www.twitter.com/mirriad>[https://www.mirriad.com/wp-content/uploads/2018/06/Social_Facebook.jpg]<http://www.facebook.com/mirriad>[https://www.mirriad.com/wp-content/uploads/2018/06/Social_Instagram.jpg]<http://www.instagram.com/mirriad_global>
Next Gen Advertising Award winner, Content Innovation Awards.
Best Video Marketing & Advertising Platform winner, Digiday Technology Awards.
Take a look to see what Mirriad In-Video Advertising<https://player.vimeo.com/external/255397834.hd.mp4?s=fa14d977acd8d1732fcd6341d22450dc62687e87&profile_id=175> can do for your business.
This message contains confidential information and is intended only for the individual(s) addressed in the message.
If you are not the named addressee, you should not disseminate, distribute, or copy this e-mail.
If you are not the intended recipient, you are notified that disclosing, distributing, or copying this e-mail is strictly prohibited.
Re: Ack now or too lat - weird behaviour of transaction on ActiveMQ
over stomp
Posted by Tim Bain <tb...@alumni.duke.edu>.
Then this sounds like a bug. Can you please submit a bug for it in JIRA? If
possible, please attach your actual code that reproduces the problem, in
case whoever implements the fix has trouble reproducing it.
Tim
On Mon, Nov 19, 2018, 1:32 AM Murphy Meng <murphy.meng@mirriad.com wrote:
> Thanks Tim. It is a typo. Sorry.
> This issue is 100% reproducible. All messages are acknowledged properly in
> real code.
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>
Re: Ack now or too lat - weird behaviour of transaction on ActiveMQ
over stomp
Posted by Murphy Meng <mu...@mirriad.com>.
Thanks Tim. It is a typo. Sorry.
This issue is 100% reproducible. All messages are acknowledged properly in
real code.
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Re: Ack now or too lat - weird behaviour of transaction on ActiveMQ
over stomp
Posted by Tim Bain <tb...@alumni.duke.edu>.
Your pseudocode uses the same message ID for both acks, so the behavior you
describe is correct for your pseudocode. Is the pseudocode reflective of
your actual code in that respect?
Tim
On Thu, Nov 15, 2018, 8:37 AM Murphy Meng <murphy.meng@mirriad.com.invalid
wrote:
>
> I use stomp (1.2) to connect to ActiveMQ (5.15). It is a Python client and
> stomp.py library is employed. A transaction begins when one message is
> received, the client does some processing then acknowledge the message,
> then commit the transaction. Such loop starts over when a new message is
> received.
>
> There is a scenario where I found the problem. There could be more then
> one messages are received before the transaction begin-process-ack-commit
> loop. And such loops handle only one message in one go. What is the issue?
> The second message received earlier will not be acknowledged at all.
>
> Pseudo code:
> >>class mylistener:
> >> def on_message(self, header, body):
> >> print(‘get message %s’, header[‘ack’])
> >>conn.set_listener(‘listener1’, mylistener());
> >>conn.subscribe(destination=‘queue1', id=1, ack=‘client-individual’)
> >>get message ID:03367ac6c23d-44027-1542285031966-10:1
> >>get message ID:03367ac6c23d-44027-1542285031966-10:2
> >>txid1 = conn.begin()
> >>conn.ack(‘ID:03367ac6c23d-44027-1542285031966-10:1’, txid1)
> >>conn.commit(txid1)
> >>txid2 = conn.begin()
> >>conn.ack(‘ID:03367ac6c23d-44027-1542285031966-10:1’, txid2)
> >>conn.commit(txid2)
>
> At this point, the second message is not acknowledged at all. You will
> find out it stays in the queue and will not be redelivered (if the client
> is not disconnected).
>
> Anyone can tell me is this designed? I don’t see any statement like this
> in stomp spec. It looks quite problematic for me.
>
> Best regards,
>
> Murphy Meng
> Sent from Polymail<
> https://polymail.io/?utm_source=polymail&utm_medium=referral&utm_campaign=signature
> >
>
> Murphy Meng
> API Software Developer
> murphy.meng@mirriad.com /
> 96 Great Suffolk Street, London, SE1 0BE, GB
>
> [https://www.mirriad.com/wp-content/uploads/2018/06/Logo.jpg]<
> https://www.mirriad.com>[
> https://www.mirriad.com/wp-content/uploads/2018/06/Social_LinkedIn.jpg]<
> http://www.linkedin.com/company/mirriad>[
> https://www.mirriad.com/wp-content/uploads/2018/06/Social_Twitter.jpg]<
> http://www.twitter.com/mirriad>[
> https://www.mirriad.com/wp-content/uploads/2018/06/Social_Facebook.jpg]<
> http://www.facebook.com/mirriad>[
> https://www.mirriad.com/wp-content/uploads/2018/06/Social_Instagram.jpg]<
> http://www.instagram.com/mirriad_global>
>
> Next Gen Advertising Award winner, Content Innovation Awards.
> Best Video Marketing & Advertising Platform winner, Digiday Technology
> Awards.
> Take a look to see what Mirriad In-Video Advertising<
> https://player.vimeo.com/external/255397834.hd.mp4?s=fa14d977acd8d1732fcd6341d22450dc62687e87&profile_id=175>
> can do for your business.
>
> This message contains confidential information and is intended only for
> the individual(s) addressed in the message.
> If you are not the named addressee, you should not disseminate,
> distribute, or copy this e-mail.
> If you are not the intended recipient, you are notified that disclosing,
> distributing, or copying this e-mail is strictly prohibited.
>