Ack now or too lat - weird behaviour of transaction on ActiveMQ over stomp

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Ack now or too lat - weird behaviour of transaction on ActiveMQ over stomp

Murphy Meng-2

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
[hidden email] /
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.
Reply | Threaded
Open this post in threaded view
|

Re: Ack now or too lat - weird behaviour of transaction on ActiveMQ over stomp

Tim Bain
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 <[hidden email]
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
> [hidden email] /
> 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Ack now or too lat - weird behaviour of transaction on ActiveMQ over stomp

Murphy Meng
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
Reply | Threaded
Open this post in threaded view
|

Re: Ack now or too lat - weird behaviour of transaction on ActiveMQ over stomp

Tim Bain
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 <[hidden email] 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
>