2

I'm having a similar situation described here, but cannot comment there because just registered on this site. A workaround for "pausing" with SetNumberOfWorkers(0) works in most cases. However, if SetNumberOfWorkers(0) is called during a lengthy message handler, I receive the following error at the end of the message handler:

An error occurred when attempting to complete the transaction context Rebus.Exceptions.RebusApplicationException: Could not complete message with ID <...> and lock token <...> ---> Microsoft.Azure.ServiceBus.MessageLockLostException: The lock supplied is invalid. Either the lock expired, or the message has already been removed from the queue.

Note, that "Worker Rebus 1 worker 1 stopped" messages are received for all workers almost immediately after calling SetNumberOfWorkers(0) despite handler is still running.

After bringing number of workers back to normal all further messages throw a similar error at the end of the handler.

Any advice how to correctly deal with the pause of rebus?

(I need to pause because my microservice requires to periodically updating some resources and handlers can't run during those update)

Ilya
  • 21
  • 1
  • When you say "lengthy message handler", what are we talking about then? If your handlers take a long time, possibly getting near or even over the 5 minute default lease timeout in Azure Service Bus, then you need to tell Rebus automatically renew the peek lock: https://github.com/rebus-org/Rebus/wiki/Azure-Service-Bus-transport#long-running-message-handlers – mookid8000 Mar 25 '19 at 17:03
  • @mookid8000, no it's 20-60 seconds. Everything is working fine till the moment `SetNumberOfWorkers(0)` is called when one of the handlers is still running. – Ilya Mar 25 '19 at 20:42
  • Could you maybe update your question with some more output from the log, including the lines surrounding the error..? – mookid8000 Mar 26 '19 at 09:29
  • At the moment my handler just waiting for 60 seconds with `Task.Delay` and error in the log appears after the handler's `Handle` method quits. I've also tried to throw an exception from the handler in this case (I can check at the end that the number of workers is 0) in order to "delay the message" but the same locking error appears. Do you want to see the log in terms of timing? – Ilya Mar 26 '19 at 11:25
  • ok, great.... I think you've explained enough for me to reproduce it.... I'll have time to look at it later today, then I'll get back to you :) – mookid8000 Mar 26 '19 at 13:17
  • @mookid8000, have you managed to reproduce it? Should I try to create a small app for this? – Ilya Apr 04 '19 at 13:51
  • oh yeah sorry for not getting back to you! and yes, it would be a big help if you would do that – mookid8000 Apr 04 '19 at 18:38

0 Answers0