[QUERY] Service bus - maxConcurrentSessions internal management

[salvinif]

Query/Question
I'm trying to understand how connections to the bus are managed internally in the event of queues with the active session and a maximum number of active sessions > 1. In particular, looking at the logs, it seems that from the start of the application until it is closed , the create link, token renewal, etc. operations are carried out for the maximum number of potentially active sessions, even if there is no message in the queue. So, for example, set a maxConcurrentSessions = 5 and we have only one message with sessiondId = 1 we still have the same operations repeated 5 times. Shouldn't the number of such operations depend on the number of actually active sessions?

An example of what we got. This is repeated every time

`2025-01-16 10:00:23 [reactor-executor-1] [/] INFO c.a.c.a.i.h.ReceiveLinkHandler2 - {"az.sdk.message":"Receiver link was never active. Closing endpoint states","connectionId":"MF_1ab516_1737017668077","entityPath":"SOME.SOME.QUEUE.NAME","linkName":"session-_d525a4_1737017964120"}
2025-01-16 10:00:23 [reactor-executor-1] [/] INFO c.a.c.a.i.h.ReceiveLinkHandler2 - {"az.sdk.message":"Receiver link was never active. Closing endpoint states","connectionId":"MF_1ab516_1737017668077","entityPath":"SOME.SOME.QUEUE.NAME","linkName":"session-_dde554_1737017964117"}
2025-01-16 10:00:23 [reactor-executor-1] [/] INFO c.a.c.a.i.h.ReceiveLinkHandler2 - {"az.sdk.message":"Receiver link was never active. Closing endpoint states","connectionId":"MF_1ab516_1737017668077","entityPath":"SOME.SOME.QUEUE.NAME","linkName":"session-_5bd90d_1737017964121"}
2025-01-16 10:00:23 [reactor-executor-1] [/] INFO c.a.c.a.i.h.ReceiveLinkHandler2 - {"az.sdk.message":"Receiver link was never active. Closing endpoint states","connectionId":"MF_1ab516_1737017668077","entityPath":"SOME.SOME.QUEUE.NAME","linkName":"session-_b545f0_1737017964119"}
2025-01-16 10:00:23 [reactor-executor-1] [/] INFO c.a.c.a.i.h.ReceiveLinkHandler2 - {"az.sdk.message":"onLinkFinal","connectionId":"MF_1ab516_1737017668077","linkName":"session-_3571a2_1737017964120","entityPath":"SOME.SOME.QUEUE.NAME"}
2025-01-16 10:00:23 [reactor-executor-1] [/] INFO c.a.c.a.i.h.ReceiveLinkHandler2 - {"az.sdk.message":"onLinkFinal","connectionId":"MF_1ab516_1737017668077","linkName":"session-_d525a4_1737017964120","entityPath":"SOME.SOME.QUEUE.NAME"}
2025-01-16 10:00:23 [reactor-executor-1] [/] INFO c.a.c.a.i.h.ReceiveLinkHandler2 - {"az.sdk.message":"onLinkFinal","connectionId":"MF_1ab516_1737017668077","linkName":"session-_dde554_1737017964117","entityPath":"SOME.SOME.QUEUE.NAME"}
2025-01-16 10:00:23 [reactor-executor-1] [/] INFO c.a.c.a.i.h.ReceiveLinkHandler2 - {"az.sdk.message":"onLinkFinal","connectionId":"MF_1ab516_1737017668077","linkName":"session-_5bd90d_1737017964121","entityPath":"SOME.SOME.QUEUE.NAME"}
2025-01-16 10:00:23 [reactor-executor-1] [/] INFO c.a.c.a.i.h.ReceiveLinkHandler2 - {"az.sdk.message":"onLinkFinal","connectionId":"MF_1ab516_1737017668077","linkName":"session-_b545f0_1737017964119","entityPath":"SOME.SOME.QUEUE.NAME"}

2025-01-16 10:00:23 [reactor-executor-1] [/] INFO c.a.c.a.i.ReactorSession - {"az.sdk.message":"Creating a new receiver link.","connectionId":"MF_1ab516_1737017668077","sessionName":"QUEUE.NAME","sessionId":"H_68bd1d_1737017668689","linkName":"session-_466bf6_1737018023121"}
2025-01-16 10:00:23 [reactor-executor-1] [/] INFO c.a.c.a.i.ReactorSession - {"az.sdk.message":"Creating a new receiver link.","connectionId":"MF_1ab516_1737017668077","sessionName":"QUEUE.NAME","sessionId":"H_68bd1d_1737017668689","linkName":"session-_70a22c_1737018023122"}
2025-01-16 10:00:23 [reactor-executor-1] [/] INFO c.a.c.a.i.ReactorSession - {"az.sdk.message":"Creating a new receiver link.","connectionId":"MF_1ab516_1737017668077","sessionName":"QUEUE.NAME","sessionId":"H_68bd1d_1737017668689","linkName":"session-_d67e69_1737018023123"}
2025-01-16 10:00:23 [reactor-executor-1] [/] INFO c.a.c.a.i.ReactorSession - {"az.sdk.message":"Creating a new receiver link.","connectionId":"MF_1ab516_1737017668077","sessionName":"QUEUE.NAME","sessionId":"H_68bd1d_1737017668689","linkName":"session-_267118_1737018023124"}
2025-01-16 10:00:23 [reactor-executor-1] [/] INFO c.a.c.a.i.ReactorSession - {"az.sdk.message":"Creating a new receiver link.","connectionId":"MF_1ab516_1737017668077","sessionName":"QUEUE.NAME","sessionId":"H_68bd1d_1737017668689","linkName":"session-_f95aaf_1737018023125"}`

Our actual config

private static final String SERVICE_BUS_REACTOR_VERSION2 = "com.azure.messaging.servicebus.session.reactor.asyncReceive.v2";

@Value("${queue.sender.name}")
private String queue;

@Bean
ServiceBusClientBuilder serviceBusClientBuilder(CustomAzureServiceBusProperties customAzureServiceBusProperties) {
	return new ServiceBusClientBuilder().connectionString(customAzureServiceBusProperties.getConnectionString())
			.transportType(AmqpTransportType.AMQP_WEB_SOCKETS)
			.configuration(new com.azure.core.util.ConfigurationBuilder()
					.putProperty(SERVICE_BUS_REACTOR_VERSION2, BooleanUtils.TRUE).build());
}

@Bean
ServiceBusProcessorClient serviceBusSessionProcessorClient(ServiceBusClientBuilder builder,
		CustomAzureServiceBusProperties customAzureServiceBusProperties,
		ServiceBusProcessManager serviceBusProcessManager) {
	return builder.sessionProcessor().receiveMode(ServiceBusReceiveMode.PEEK_LOCK)
			.queueName(queue)
			.maxConcurrentSessions(customAzureServiceBusProperties.getMaxConcurrentSessions())
			.processMessage(serviceBusProcessManager::processMessage)
			.processError(serviceBusProcessManager::processError)
			.maxAutoLockRenewDuration(
					Duration.ofSeconds(customAzureServiceBusProperties.getMaxAutoLockRenewSeconds()))
			.sessionIdleTimeout(Duration.ofSeconds(customAzureServiceBusProperties.getSessionIdleTimeoutSeconds()))
			.disableAutoComplete().buildProcessorClient();
}

Why is this not a Bug or a feature Request?
Need clarification on how maxConcurrentSession internally works

Setup (please complete the following information if applicable):

• OS: [Windows 11]
• IDE: [Eclipse]
• Library/Libraries:

azure-messaging-servicebus:7.17.7
azure-core-amqp:2.9.11

[github-actions]

@anuchandy @conniey @lmolkova

[github-actions]

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

[anuchandy]

Hello @salvinif, thanks for the question. As per the Service Bus broker contract – the client should request broker to open maxConcurrentSessions (e.g. 5) AMQP links. If there are 5 sessions available, the broker will associate each link open request with a session and acknowledge. At this point, the client can start receiving session messages through those links.

Once the client sends a link open request, the broker will wait for approximately 1 minute for a session to become available. If the broker cannot find a session within this timeout, then the broker will terminate the link open request. This termination occurs if there aren't enough free sessions (e.g. sessions are already associated with other links). The client must send the request again when such terminations happen.

The broker does not proactively inform the client when a new session becomes available; instead, the client needs to poll the broker for any available sessions as explained. Hope this clarifies.

[github-actions]

Hi @salvinif. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.