Reprocess messages which are not Ack-back by consumer

General Discussions
,
21

@Anton, sorry I looked at the original question which talked about JSCMP, I forgot you’re .net… You’re right, there’s no .close(), so I think you’d need to .dispose(). This can’t be done from the delegate.

22

@TomF I assume after calling Dispose() I have to re-create flow. Am I right?

23

@Anton, Yes exactly. You’re destroying the flow and re-creating it.

24

@TomF thanks, going to try this now…

25

@TomF so, getting closer but still not quite there.
After this sequence:
Flow.Stop()
Flow.Dispose()
Flow = Session.CreateFlow()
Flow.Start()

Message is re-delivered to another queue consumer but original one stops to receive any new message at all.

26

Found an issue - I was re-creating Flow in the received message handler. Now, when I separated into two different threads it works as expected. The last question (I hope) - can someone explain MaxUnackedMessages property on a Flow and can this property somehow affect what I’m trying to achieve. Or maybe if there is recommended values for it.

Thanks.

27

Thank you folks for your valuable time and inputs. Some of these might work, but the real solution I feel is NACK, so developer can focus on actual implementation rather managing it into application logic.

28

@Anton, I tried some variations on local transacted sessions. If I understand correctly, here’s your sequence of receive messages:

  1. Received, commit
  2. Received, commit
  3. Received, rollback
    What happens then? Do you receive messages 4 and 5, or do you close the flow after getting 3? How are you receiving the messages, usings IFlow.ReceiveMsg()?

Regarding MaxUnackedMessages, messages on a flow are sent using a windowing scheme. This window size of messages can be sent to the application before the broker stops sending messages and waits for an ack to be received. It only applies if you are setting the Flow Property AckMode to ClientAck and manually acknowledging the messages. If you’re using Ackmode AutoAck, the acknowledgement of the message will be sent as soon as the Delegate returns.

So, in your case, if you’re using ClientAck, you’ll have MaxUnackedMessages waiting for your application to process. If you receive and don’t call .ack() on the message, when you close the flow the message will be marked as undelivered, just as if you’d called .rollback()

29

@TomF with TransactedSession I was rolling back on message 3. I was not restarting the flow. After few re-deliveries message 3 and all messages behind it were put to the DMQ.

However, I successfully implemented my scenario with ClientAck and restarting the flow to simulate “nack”. So I’ll stick to this solution and wait for a Nack() method added by you guys. Regarding the MaxUnackedMessages - do I understand correctly that for my needs I need to set it to 1, so only one message at a time will be delivered to the client?