Is asynchronous nack thread blocking?

[livius-ungureanu]

It looks like explicit nack can be used only synchronously and the only way to use it asynchronously is by supplying it as an implicit default RecoveryStrategy for BoundConsumerDefinition(i.e. the subscription).

So to consume some item asynchronously we should roughly use something like ack(Future{ body_process_result}) . The doc says that if the future fails then the RecoveryStrategy is applied(i.e the wanted nack is called). But this leads to

op-rabbit/core/src/main/scala/com/spingo/op_rabbit/impl/AsyncAckingRabbitConsumer.scala

Line 179 in ff9f8a2

Await.result(

being hit which looks like thread blocking.

Are there any plans to improve this?

And a 2nd question: Is there any other approach to use nack asynchronously besides the approach above(also used in /op-rabbit/core/src/test/scala/com/spingo/op_rabbit/consumerSpec.scala test) ?

[kw217]

I don't think this is actually a problem - the real work is handled by

op-rabbit/core/src/main/scala/com/spingo/op_rabbit/impl/AsyncAckingRabbitConsumer.scala

Lines 79 to 82 in 9a681c4

	case delivery: Delivery =>
	pendingDeliveries.add(delivery.envelope.getDeliveryTag)
	implicit val ec = handlerExecutionContext
	applyHandler("running handler", delivery)(async(subscription.handler)) pipeTo self

which runs the work (subscription.handler) asynchronously as expected. Only if the work throws does anything interesting happen - in this case the exception becomes a ReceiveResult.Fail message, which invokes the recovery strategy synchronously in

op-rabbit/core/src/main/scala/com/spingo/op_rabbit/impl/AsyncAckingRabbitConsumer.scala

Lines 178 to 185 in 9a681c4

	try
	Await.result(
	applyHandler("running recoveryStrategy", fail.delivery)(
	subscription.recoveryStrategy(subscription.queue.queueName, channel, fail.exception)),
	5.minutes)
	catch { case ex: Throwable =>
	ReceiveResult.Fail(fail.delivery, Some("exception while running recoveryStrategy"), ex) }
	} match {

The recovery strategy in our application (presumably typical) is just RecoveryStrategy.nack(requeue=true), which will complete immediately (ultimately it reduces to p.success(ReceiveResult.nack)). So the thread will only be blocked momentarily, which is not a problem.

I think this issue can probably be closed.

[kw217]

To answer point 2, isn't it the case that if the body returns ReceiveResult.nack then op-rabbit will nack the message?

[livius-ungureanu]

thank you @kw217

Right.

• On nominal scenarios the RecoveryStrategy is not called so the code is 100% async for nominal scenarios.
• Just in case of failure, the RecoveryStrategy is called synchronously, blocking the thread but this could be accepted as an insignificant amount of work done in this case (just call the RecoverStrategy.nack to send out a nack)

So the main concern does not exist. Though it would have been preferred an implementation without thread blocking at all.

Regarding the 2nd point it would be nice if op-rabbit's RecoveryStrategy would be more flexible and allow the user to specify a reject with requeue = true/false as needed. Currently the user is forced to specify only one of them.

[livius-ungureanu]

We'd like to also have op-rabbit's thoughts on this.