trefsahl
commented
1 year ago We run a async "short-lived" client for receving messages and has tested recreating clients with the use of close(). But this does not behave in a gracefull way today. This is a list of my top values from the logs when we call close() after a few days in production with version 7.13.4 of the java lib (I guess some of the messages could be ignored, but still...)
- Cannot perform operation 'abandoned' on a disposed receiver.
- The receiver didn't receive the disposition acknowledgment due to receive link closure.
- java.lang.InterruptedException
- Cannot subscribe. Processor is already terminated
- Cannot perform operations on a disposed set.
- Delivery not on receive link.
- Cannot perform operation 'renewMessageLock' on a disposed receiver
Maybe a combination of first calling stop(), and the close() a short while later could be good choice?
Today Service Bus Processor exposes two APIs that complete the message pumping - stop and close.
The mainline use case is - the application wants the Processor to pump the message forever. When/If the application shuts down, it calls close API to dispose of the Processor.
As the engineering team recently reevaluated the past design choices, we identified that the stop API involves quite a complexity; supporting it correctly involves a reasonable (allocation, coordination) overhead and contributes to engineering costs. Additionally, the above mainline use case (that does not use stop) pays the price of this overhead.
The engineering team came to the conclusion that the mainline use case will greatly benefit from deprecating and removing stop , and saves engineering and maintenance costs.
Going forward, starting Processor that was stopped before is not recommended and this feature may be deprecated in future. Recommendation is to close the Processor instance and create a new one to restart processing.
The April 2023 version (v7.13.4) of Service Bus SDK includes a log message in the warning level to communicate this upcoming change; this is the pr.