Manual ack/nacks

[ghost]

Hey there,

Thanks a lot for Hutch! I am really enjoying it. I am looking to do something that may or may not be possible today, if not, I am glad to help make it happen.

I see that broker.rb has a "nack" and "ack" method, however they seem to only be used by Hutch internally in "worker.handle_message" (maybe others). I "think" Hutch will only send a "nack" if it has a problem handling the message and not if it fails to complete the "work" the message entails.

Would there be a way for me to "nack" or "ack" from within Worker's job itself, vs having Hutch do it automatically? Specifically, would it be possible to implement this logic:

A) A worker who executes without exceptions sends an "ack" after successful execution.
B) A "nack" is sent if the worker code hits any exception.

My goal here would be that if my code hits an exception, a job is not lost, but later retried. Any advice appreciated!

Cheers,

Tim

[michaelklishin]

@tvaillancourt Hutch currently acks successfully processed messages automatically. So what are you looking to do, ack manually or let Hutch do it?

Note that re-queueing on exception can (and frequently will) lead to very long or endless redelivery loops.

[ghost]

Thanks Michael!

I think what I'd specifically like to do is have Hutch send a "nack" if my Hutch worker encountered a Ruby Exception while working on the message. It would be cool if this was automatic or could be defined as some sort of Exception handler, but manual would be fine also.

Ultimately, my goal is to keep messages if my worker code is faulty or I cannot process the message somehow. In my scenario, a redelivery loop is better than a lost message, essentially.

Cheers,

Tim

[michaelklishin]

After reviewing #168, I think there should be 3 acknowledgement modes:

• automatic (as in Bunny)
• manual (as in Bunny)
• framework (current default, Hutch acks unless there was an exception)

The 3rd option may include what @teodor-pripoae suggested in #169.

Thoughts?

[teodor-pripoae]

I think we can handle user defined callbacks on consumer level, similar to activerecord. I'm not sure if the use case should be global or consumer based.

First option is the most clean one but not extensible, the 2nd and 3rd are more verbose.

class MyConsumer
  include Hutch::Consumer

  on_failure :requeue
  # or  
  on_failure :failure_callback
  # or
  on_failure Proc.new{ requeue! }

  def failure_callback
    requeue!
  end
end

[michaelklishin]

This looks good but I'd perhaps add it after we merge the new acknowledgement modes. This also needs to play well with exception loggers/collectors.

[erithmetic]

I threw together a way to customize what happens when a consumer fails. By default a nack is always sent. erithmetic@e9e3a1f

[michaelklishin]

This is in part addressed by #177. I'm curious how many people are interested in customizing when messages are (positively) acknowledged. I'd expect not that many, so maybe #177 addresses this entirely?

[gottfrois]

I would appreciate per consumer callbacks. Allows to handle those cases in context of the consumer instead of moving the logic too far, in another class.