[BUG] Processor client error handler not called when ASB subscription is deleted about azure-sdk-for-java HOT 7 CLOSED

@anuchandy

Actually what I reported happens to a Spring Boot Starter Web application running in AKS as well. The app (in JVM) keeps running but the error handler doesn't get called.

I think you misunderstood the whole point. I expect both the error handler to get called and the retry to happen.

After adding a Thread.sleep, yes it does keep running and printing some logs, and when I recreate the subscription manually, it stops printing logs which is part of what I expect.
However, my error handler function doesn't get called, unlike in the previous versions.

In my use case, I am relying on the error handler to recreate the subscription when the subscription gets deleted, in version 5.8.0 and below, it will give me an error context with ServiceBusFailureReason.MESSAGING_ENTITY_NOT_FOUND. In 5.9.1 and above, my error handler function doesn't get called.

I don't see this change mentioned in the changelog. Do you mind telling me if it is mentioned anywhere in docs, and how my program can know if the subscription is missing or deleted?

Thanks.

from azure-sdk-for-java.

I see. Okay, my first focus was on reported observation where program exit without retry, so wanted to debug if the Processor was stopping it's "reconnect attempts" (here after entity deletion). Since Spring has a non-demon + always running parent thread, Processor’s internal reconnect attempts should not stop.

Thank you for the additional context around the application specific dependency on error inspection, it clarifies the end-to-end use case. I'll compare Processor's behavior in 5.8.0 versus 5.9.1 and get back.

from azure-sdk-for-java.

Hello @blackr1234, I looked into this, and the dropping of error notification is now addressed in #39723. Thank you for reporting this.

from azure-sdk-for-java.

@anuchandy @conniey @lmolkova

from azure-sdk-for-java.

Thank you for your feedback. Tagging and routing to the team member best able to assist.

from azure-sdk-for-java.

Updated post with dependency information and detailed descriptions of the expected and actual behaviors.

from azure-sdk-for-java.

Hello @blackr1234,

I was testing this, and as you observed the error is not propagated but unlike your case, the ServiceBusProcessorClient kept retried and connected to the entity as soon as I re-created the entity, then it resumed pumping messages.

I think your application setup is running into this #30170

So the point here is – the start() call will start the asynchronous message pumping using demon-threads. If the main/application (non-demon) thread exits for any reason, then the demon-threads pumping the messages will be killed by the JVM.

This is likely the case you’re running into. The easiest way to check this is by using a simple Java console application,

1. with the code you shared.
2. Put a sleep(10min) after the client.start()
3. Now delete the entity (queue, subscription), in the logs you will see retry happening.
4. Recreate the entity from portal (before the sleep(10min) expires), you should see the processor connecting to the entity.

from azure-sdk-for-java.