Skip to content

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

Closed

Description

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 (@nullable) String subscription,
@Nonnull (@nonnull) MessageListener<?> messageListener,
@Nonnull (@nonnull) ServiceBusErrorHandler errorHandler,
Nullable (@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

Activity

  1. added
    ClientThis issue points to a problem in the data-plane of the library.
    customer-reportedIssues that are reported by GitHub users external to the Azure organization.
    questionThe issue doesn't require a change to the product in order to be resolved. Most issues start as that
    Service AttentionWorkflow: This issue is responsible by Azure service team.
    on Feb 18, 2026
  2. github-actions commented on Feb 18, 2026

    @github-actions
    Contributor

    Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc Eldert Grootenboer (@EldertGrootenboer) Srini Karri (@skarri-microsoft).

  3. added
    bugThis issue requires a change to an existing behavior in the product in order to be resolved.
    and removed
    questionThe issue doesn't require a change to the product in order to be resolved. Most issues start as that
    on Feb 19, 2026
  4. added this to the 2026-03 milestone on Feb 24, 2026
  5. moved this from Todo to In Progress in Spring Cloud Azureon Feb 24, 2026
  6. moved this from In Progress to Done in Spring Cloud Azureon Feb 28, 2026
  7. locked and limited conversation to collaborators on May 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions