Skip to content

[BUG] DefaultServiceBusNamespaceProcessorFactory doesn't remove disposed/closed ServiceBusProcessorClients from processorMap cache #48030

@stephenstachelski-tr

Description

@stephenstachelski-tr

Describe the bug
The DefaultServiceBusNamespaceProcessorFactory fails to clean up closed processors from its internal cache, causing it to return non-functional processors.

Problem Details:

  1. When a ServiceBusProcessorClient is disposed or closed, it remains in the factory's processorMap cache
  2. Subsequent calls to createProcessor() retrieve these closed processors from the cache
  3. These closed processors cannot process messages from the queue
  4. The processorMap is only cleared when the factory itself is disposed, not when individual processors are closed

Impact:

  • Message processing fails silently because the factory returns cached processors that are no longer operational.

Exception or Stack Trace
No stack trace

To Reproduce

  • Create processor by calling one of the create methods
  • Dispose/close the processor (simulating a non transient error that closes the processor)
  • Call createProcessor and the disposed/closed processor is returned

Code Snippet
DefaultServiceBusNamespaceProcessorFactory.java#doCreateProcessor

The below snippet shows that the return for doCreateProcessor is either a value from the cache (which is never cleared or pruned) or it creates a new processor

`
private ServiceBusProcessorClient doCreateProcessor(String name,
@nullable String subscription,
@nonnull MessageListener<?> messageListener,
@nonnull ServiceBusErrorHandler errorHandler,
@nullable ProcessorProperties properties) {
ConsumerIdentifier key = new ConsumerIdentifier(name, subscription);

    return processorMap.computeIfAbsent(key, k -> {
        ProcessorPropertiesParentMerger propertiesMerger = new ProcessorPropertiesParentMerger();
        ProcessorProperties processorProperties = propertiesMerger.merge(properties, this.namespaceProperties);
        processorProperties.setEntityName(k.getDestination());
        if (!k.hasGroup()) {
            processorProperties.setEntityType(ServiceBusEntityType.QUEUE);
        } else {
            processorProperties.setEntityType(ServiceBusEntityType.TOPIC);
            processorProperties.setSubscriptionName(k.getGroup());
        }
  ...

`

Expected behavior
The factory should either:

  • Remove processors from processorMap when they are closed/disposed, OR
  • Detect closed processors and create new ones when createProcessor() is called

Setup (please complete the following information):

  • OS: Windows/WSL Ubuntu 22.04.5
  • IDE: Intellij
  • Library/Libraries: com.azure.spring:spring-messaging-azure-servicebus:5.24.1
  • Java version: 17
  • App Server/Environment: Tomcat
  • Frameworks: Spring

Additional context
In our environment, we noticed that over time, messages would stop being consumed from the queues. We tried stopping and starting the listeners, but the only thing that worked was restarting the application. Stepping through the code we noticed the processors were disposed/closed and that no matter what we did, we could not get the factory to return a non disposed processor.

As a workaround, we used reflection to access the processor map and clear it when we detected the processors were closed so that the factory would create new processors when we stopped and started the messageListener.

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

  • Bug Description Added
  • Repro Steps Added
  • Setup information Added

Metadata

Metadata

Labels

ClientThis issue points to a problem in the data-plane of the library.Service AttentionWorkflow: This issue is responsible by Azure service team.Service BusbugThis issue requires a change to an existing behavior in the product in order to be resolved.customer-reportedIssues that are reported by GitHub users external to the Azure organization.needs-team-attentionWorkflow: This issue needs attention from Azure service team or SDK team

Type

Projects

Status

In Progress

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions