azure-sdk-for-java: Azure Service Bus SessionReceiver Retry TryTimeout Behavior

Did the amqp retry behavior change since this post? https://github.com/Azure/azure-sdk-for-java/issues/18778

.retryOptions(new AmqpRetryOptions().setTryTimeout(Duration.ofSeconds(20)))

For the life of me, I can’t get the processor client to grab onto new sessions any faster than a 60 second interval.

Here is my ServiceBusClientBuilder config

return new ServiceBusClientBuilder()
    .credential(serviceBusNamespace, clientSecretCredential)
    .retryOptions(new AmqpRetryOptions()
        .setTryTimeout(Duration.ofSeconds(5)))
    .sessionProcessor()
    .topicName(topicName)
    .subscriptionName(subscriptionName)
    .receiveMode(ServiceBusReceiveMode.PEEK_LOCK)
    .maxConcurrentSessions(10)
    .processMessage(messageHandler::processMessage)
    .processError(messageHandler::processError)
    .buildProcessorClient();

I would expect this to generate a client that would receive message from 10 session (which it does) and if there are no messages received in 5 seconds for a session, it would move on to next session and start getting message from next available session. However, the next sessions are not processed until that 60 second loop is complete. I can see that the duration is applied to the session and that it reports out that there are no other messages within that 5 second window, but I must be missing something in my understanding of how this should work.

FWIW, I do see quite a few “Error occurred while getting unnamed session.” log entries

{“timestamp”:“2022-12-05 19:41:49.260”,“message”:"{"az.sdk.message":"Error occurred while getting unnamed session.","exception":"The operation did not complete within the allotted timeout of 00:00:04. The time allotted to this operation may have been a portion of a longer timeout. For more information on exception types and proper exception handling, please refer to https://aka.ms/ServiceBusExceptions . TrackingId:47be4424-fdd8-4481-bc7e-1cbfd628036a_B11, SystemTracker:bach-cps-vendor-comm-service-bus:Topic:eligibility|autoresolverefill, Timestamp:2022-12-06T00:41:49 TrackingId:68aaed80ab4f4e75904c619d080f2887_G39, SystemTracker:gateway7, Timestamp:2022-12-06T00:41:49, errorContext[NAMESPACE: bach-cps-vendor-comm-service-bus.servicebus.windows.net. ERROR CONTEXT: N/A, PATH: eligibility/subscriptions/AutoResolveRefill, REFERENCE_ID: session-_4e373c_1670287305150, LINK_CREDIT: 0]","entityPath":"eligibility/subscriptions/AutoResolveRefill","attempt":5}

I can trace that exception back to The ServiceBusSessionManager and from there it appears that there is a hard-coded 1 minute delay that can’t be changed.

Additionally, if I start my application and there are no messages on the subscription, when I do publish messages to the topic, it takes however long I’m into the 60 second loop to complete before the messages begin to be processed. I found this post so it appears that the old SDK did the same thing at one time but was addressed. Now the new SDK has the same issue?

I’m using

<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-messaging-servicebus</artifactId>
    <version>7.13.0</version>
</dependency>

Java 11 with Spring Boot 2.5.5.

Thanks.

_Originally posted by @JRiggenbach in https://github.com/Azure/azure-sdk-for-java/issues/18778#issuecomment-1338291995_