Servicebus processor Client start/stop, any better way than this ?

[jay-annapureddy]

Query/Question
Servicebus processor start/stop any better way than this ?

Why is this not a Bug or a feature Request?
From a springboot application, I am able to connect to Servicebus and process the messages but for this I am starting the processor client on PostConstruct and stopping it on PreDestroy. Is there any better way than this ? your help and suggestion is much appreciated.

I am using the following spring dependency and with the following application properties and java code.

		<dependency>
			<groupId>com.azure.spring</groupId>
			<artifactId>spring-cloud-azure-starter-servicebus</artifactId>
			<version>4.3.0</version>
		</dependency>

Spring

spring:
  cloud:
    azure:
      servicebus:
        enabled: true
        processor:
          entity-type: QUEUE
          entity-name: <entity-name>
          connection-string: <connection-string>
          auto-complete: false
          session-enabled: true

@Slf4j
@Service
@RequiredArgsConstructor
public class AsbMessageProcessor {

    private final ServiceBusProcessorClient processorClient;

    @PostConstruct
    public void startProcessor(){
        log.info("Processor starting");
        processorClient.start();
        log.info("Processor started");
    }

    @PreDestroy
    public void stopProcessor(){
        log.info("Processor closing");
        processorClient.close();
        log.info("Processor closed");
    }
}

@Service
@Slf4j
public class AsbQueueConfiguration {

    @Bean
    public ServiceBusRecordMessageListener messageProcessor() {
        log.info("message processor initiated");
        return messageContext -> {
            try {
                ServiceBusReceivedMessage message = messageContext.getMessage();

                log.debug("Processing message. Message # : {}, Sequence #: {}, Content : {}", message.getMessageId(), message.getSequenceNumber(), message.getBody());

                messageContext.complete(); // acknowledge message

            } catch (Exception ex) {
                log.error("exception while processing message ", ex);
                messageContext.abandon(); // // re delivered
            }
        };
    }

    @Bean
    public ServiceBusErrorHandler errorProcessor() {
        log.info("error handler initiated");
        return context -> {
            log.error("Error when receiving messages from namespace: '%s'. Entity: '%s'%n",
                    context.getFullyQualifiedNamespace(), context.getEntityPath());

            if (context.getException() instanceof ServiceBusException) {
                ServiceBusException exception = (ServiceBusException) context.getException();
                log.error("Error source: %s, reason %s%n", context.getErrorSource(),
                        exception.getReason());
            } else {
                log.error("Error occurred: %s%n", context.getException());
            }
        };
    }

}

[joshfree]

@yiliuTo could you please follow up with @jay-annapureddy on their question?

[yiliuTo]

Hi @jay-annapureddy though there are various solutions to add callback on Spring's bean level or context level, like using DisposableBean/InitializingBean, some context listener, @PostConstruct/@PreDestroy and so on. While for your request of binding the lifecycle of Service Bus processor client with Spring context, from my perspective, those solutions almost have similar effects and cost from the aspect of how you need to custom the code. Unless you have some specific requirement on the concrete lifecycle about when should these operations be triggered, you can choose one on your need.

[jbkervyn]

Hello @yiliuTo , the question of my collegue is in fact: in a spring boot application, it is the recommended way to start the processor manually, and let him run in the background by calling ServiceBusProcessorClient.start ? We were expecting to have this autoconfigured somehow... That you would only define the listeners, without having to deal with starting & stopping the processor manually.

[yiliuTo]

Hi @jbkervyn

That you would only define the listeners, without having to deal with starting & stopping the processor manually.

To meet this requirement, your solution of using @PostConstruct and @PreDestroy is a common and convenient way to achieve that, which just hands over the management of your listener to Spring context in the background.

[jbkervyn]

Hello @yiliuTo , thanks a lot for your feedback ! This answers our question !

[ghost]

Hi, we're sending this friendly reminder because we haven't heard back from you in a while. We need more information about this issue to help address it. Please be sure to give us your input within the next 7 days. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!

[yiliuTo]

Hi @jbkervyn after the internal discussion, I would like to update our previous suggestion on the way to manually start/close the processor bean. The previous mentioned way of using @PostConstruct can work actually, however there are some other limits on it: The phase when @PostConstruct takes effect is after that specific bean is being initialized, but not to say that all of the other beans have been initialized as well. So at that time the application is not in a state of ready to run. And we think a more professional way is to start the Service Bus processor when the application is ready that all the necessary Spring components have been prepared and are ready to use.

Therefore, we recommand you to use the SmartLifecycle interface , which just like its name indicated, it binds the component's lifecyle with Spring application context intelligently. It starts the required component when the application is being refreshed which is after all the beans get loaded and initialized, which we think is much safer.

And we prepare to enable this feature in the pr #30457, after it being released, you can remove your own customization to start/stop the processor manually, since our library will handle its lifecycle automatically.

[jbkervyn]

hi @yiliuTo

That's great! Any idea in which version of spring-cloud-azure it will end up in?

[yiliuTo]

Hi @jbkervyn , we currently target to release it in the version of 4.4.0, and will notice you once it gets released or there are any other changes.