ack / nack

[madkote]

trafficstars

Hi @pedrokiefer ,

## manually How to perform ack / nack in manual way?

## ack modes There are following default mode auto and also parameter auto_ack=True -> How do they play together

## message handler

• Which role does the return value play in message handler?
• are other exceptions handled?

async def on_message(frame, message):
    print('on_message:', message, frame, frame.headers)
    return True  # !!! <<< here? ACK?
    return False # !!! <<< here ? NACK?

[pedrokiefer]

Ack mode auto means the server auto acknowledge de message as soon it writes to its socket. So auto_ack on the lib doesn't do anything. See the stomp protocol for more informations.

Choosing client or client-individual mode then enables auto_ack parameter, when auto_ack=True returning True from the handler means ACK.

It's probably missing better exception handling on AutoAckContextManager, but should be easy to add ie. ensure that exceptions => NACK

You can manually call ack / nack, with something like:

stomp = AioStomp(...)

async def on_message(frame, message):
    stomp.ack(frame)

https://stomp.github.io/stomp-specification-1.2.html#SUBSCRIBE_ack_Header

[Komodo1]

Hello,

I had the same question and tried your suggestion @pedrokiefer . switching to auto_ack=True manually or leaving this blank, and returning True doesn't seem to send and ACK to ActiveMQ (message still there). the stomp.ack proposal doesn't work either. I added extra_headers={'activemq.prefetchSize': 1} to the subscribe, and creative on activeMQ a queue with 2 pending messages. None is ACK so far. In my case I got a (very) slow consumer, and need to treat them one by one, in a async mode. As I'm currently running the code on a distant machine, I can't get a fiddler, but that's my next step to try understanding what fails here.

[Komodo1]

FYI that's fixed (apparently at least) by removing the extra "," on ack functions lines 404 & 412 from aiostomp.py. Tested and work locally.

[pedrokiefer]

@Komodo1 I will look into that. I'm thinking about writing an integration test with an Activemq instance, and maybe a Rabbitmq too.

Are you marking the queued messages durable, ie. adding the header persistent = true ?

[Komodo1]

Hello @pedrokiefer Messages are imposed by an external software, and last time I checked they were indeed persistent. With the time the "logic" imposed by certain software requires to treat each message, it's a must in my case ;)