[BUG] IllegalStateException when cancelling Service Bus session acquisition on a Reactor thread

Aperta
  • Qualcosa non va?
#51,213 2 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
56/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
azure, java
Ambito
backend

Direzione di ricerca

Start with ServiceBusSessionAcquirer.java around the cancellation cleanup at line 213, then trace how it disposes the receive link through ReactorReceiver.java and its close methods. Compare the 7.17.17 and 7.18.1 cancellation paths and inspect related tests for session acquisition cancellation. Done means cancellation closes the link without triggering Reactor’s blocking-operation exception and the processor handles the acquisition outcome.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Client customer-reported needs-team-attention question Service Attention Service Bus

Describe the bug

A session-enabled Service Bus processor intermittently raises a Reactor IllegalStateException when session acquisition is cancelled.

The exception occurs while the SDK closes the receive link after cancellation. The close operation calls Mono.block(...) from a Reactor non-blocking scheduler thread.

Exception or Stack Trace

java.lang.IllegalStateException: block()/blockFirst()/blockLast() are blocking, which is not supported in thread parallel-2
    at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:121)
    at reactor.core.publisher.Mono.block(Mono.java:1754)
    at com.azure.core.amqp.implementation.ReactorReceiver.close(ReactorReceiver.java:309)
    at com.azure.core.amqp.implementation.ReactorReceiver.dispose(ReactorReceiver.java:304)
    at com.azure.messaging.servicebus.ServiceBusSessionAcquirer.lambda$acquireSession$4(ServiceBusSessionAcquirer.java:213)
    at reactor.core.publisher.FluxDoFinally$DoFinallySubscriber.runFinally(FluxDoFinally.java:146)
    at reactor.core.publisher.FluxDoFinally$DoFinallySubscriber.cancel(FluxDoFinally.java:135)
    at reactor.core.publisher.MonoFlatMap$FlatMapMain.cancel(MonoFlatMap.java:207)
    at reactor.core.publisher.Operators$MultiSubscriptionSubscriber.drainLoop(Operators.java:2425)
    at reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.handleTimeout(FluxTimeout.java:295)

To Reproduce

  1. Use a session-enabled Service Bus queue or subscription.
  2. Create a session-enabled ServiceBusProcessorClient.
  3. Start the processor.
  4. Let session acquisition be cancelled, for example when acquisition times out while a receiver is being created.
  5. Observe the exception during receiver disposal.
    The issue is intermittent and depends on session acquisition cancellation, broker latency, or session contention.
    Expected behavior
    Cancelling session acquisition should close the receive link without invoking a blocking operation on a Reactor non-blocking thread.
    The processor should recover or report the acquisition failure without raising a Reactor blocking-operation exception.

Screenshots

Not applicable.

Setup

  • OS: Linux, running in Kubernetes
  • Libraries:
  • com.azure:azure-messaging-servicebus:7.18.1
  • com.azure:azure-core-amqp:2.12.2
  • Previous version: com.azure:azure-messaging-servicebus:7.17.17
  • Java version: 21
  • App Server/Environment: Kubernetes
  • Frameworks:
  • Spring Boot
  • Reactor
  • OpenTelemetry Java agent

Additional context

The issue appeared after upgrading the Azure SDK from: azure-messaging-servicebus:7.17.17 (azure-core-amqp:2.12.1) to: azure-messaging-servicebus:7.18.1 (azure-core-amqp:2.12.2)
The new version was deployed on 6 November 2026. The exception then appeared intermittently in Application Insights.
By comparing the implementations between 7.17.17 and 7.18.1, the session acquisition cancellation path appears to have changed.
In 7.18.1, cancellation disposes the receive link. ReactorReceiver.dispose() delegates to close(), which synchronously calls closeAsync().block(...).
The corresponding cancellation cleanup callback is not present in 7.17.17.
No application code calls block() in this execution path. The blocking call originates inside the Azure SDK during cancellation cleanup.
The issue was observed with session-enabled consumers.

Information Checklist

  • Bug Description Added
  • Repro Steps Added
  • Setup information Added
Lingua principale
Java
Stelle
2.6k
Fork
2.2k
Merge medio
1g 17h
PR unite (30g)
259

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Azure/azure-sdk-for-java

Tutte le issue di Azure/azure-sdk-for-java

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.