[QUERY] Specific and detailed information for Service Bus connection management
See original GitHub issueQuery/Question How exactly should we manage Service Bus client connections, and can we have details added to the documentation?
I will have hundreds and possibly thousands of concurrent requests writing to Service Bus. How should I share connetions in a way that optimizes performance and resource management, without risk to integrity?
Should we always call .close()
in the client after a “send” operation? I noticed by the logs that when doing this it seems that the whole connection gets recreated and it takes a long time to complete, sometimes close to 2 seconds.
When I leave a client without closing it the speed is much faster, however I get that are opened clients sharing a connection. Is this a bad practice?
# of open clients with shared connection: 13391
What is thread safe? What isn’t thread safe? Can I share a client instance within for my application?
@Bean
@Scope(value = "singleton")
public ServiceBusSenderClient getClientBuilder() {
return new ServiceBusClientBuilder()
.connectionString(connectionString).sender()
.queueName(ORDERS_QUEUE)
.buildClient();
}
What does “done” means? Like, “done” in a user request sense? Or, when shutting down the application process?
// When you are done using the sender, dispose of it.
sender.close();
I was reading the connection section in the documentation however it is not clear how to optimally manage connections.
Sharing of connection between clients
The creation of physical connection to Service Bus requires resources. An application should share the connection between clients which can be achieved by sharing the top level builder as shown below.
// Create shared builder.
ServiceBusClientBuilder sharedConnectionBuilder = new ServiceBusClientBuilder()
.connectionString("<< CONNECTION STRING FOR THE SERVICE BUS NAMESPACE >>");
// Create receiver and sender which will share the connection.
ServiceBusReceiverClient receiver = sharedConnectionBuilder
.receiver()
.queueName("<< QUEUE NAME >>")
.buildClient();
ServiceBusSenderClient sender = sharedConnectionBuilder
.sender()
.queueName("<< QUEUE NAME >>")
.buildClient();
What is a “dedicated connection”? I couldn’t find to work with it in the documentation.
Why is this not a Bug or a feature Request? To provide detailed information about high-performance connection management.
Setup (please complete the following information if applicable):
- OS: Any
- IDE: Any
- Library/Libraries: com.azure:azure-messaging-servicebus:7.11.0
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
- Query Added
- Setup information Added
Issue Analytics
- State:
- Created a year ago
- Comments:12 (8 by maintainers)
Top GitHub Comments
Hi @epomatti For dedicated health check, after discussion, we decided not to implement this additional API as
createBatchMessage()
cover the same functionality.For the custom control of timeout, I am still waiting the response from service team.
Hi @epomatti, I have some updates for your requirements:
For sender sync/async clients, the
createBatchMessage()
API can establish a connection without sending any messages to the service bus. The method is used when you want to send batch messages, you can firstly know the max size of messages in one batch that transport allows.As a workaround, you can firstly call
createBatchMessage()
when you want to start up the connection. And if you want to keep the connection active and have a send link ready in place, you can call this method at least every 10 minutes. (Since if there are no messages to be sent within 10 minutes, the send link will be force-detached, and if there is no active link for 5 minutes, then the connection will be forced-closed).The link and connection timeout are set on service end, so we need to contact service team for the reason why they pick the fixed value. But the reason for setting timeout is release resources for unused endpoints. For your case, if you know the exactly sending time, I think you can schedule to call
createBatchMessage()
to startup connection and if you keep sending messages for 30 minutes, the connection can be active during this time.