-
Notifications
You must be signed in to change notification settings - Fork 10
Connecting to Service Bus
If you are used to handling connections to a relational database like SQL Server, you might find the way AzureNetQ handles connections a little odd. Communication with a relational database is always initiated by the client. The client opens a connection, issues a SQL command, processes the results if necessary, and then closes the connection. The general advice is that you should hold an open connection for as little time as possible and leave connection pooling to the API.
Talking to a message broker such as Service Bus is a little different because the connection tends to last the lifetime of the application. Typically you will open a connection, create a subscription and then wait for any messages to arrive on the open connection.
Unlike it's parent project EasyNetQ which employs a lazy connection approach, AzureNetQ assumes that the broker will be available at all times, and will throw an exception if the underlying broker cannot be reached. This is because it relies on Service Bus to persist message and provide delivery guarantees.
Standard practice is to create a single IBus instance for the lifetime of your application. Dispose it when your application closes.
A connection to Service Bus is represented by an IBus interface. Most AzureNetQ operations are methods on IBus. You create an IBus instance like this:
var connectionString = "Endpoint=sb://servicebus/ServiceBusDefaultNamespace;StsEndpoint=https://servicebus:10355/ServiceBusDefaultNamespace;RuntimePort=10354;ManagementPort=10355";
var bus = AzureBusFactory.CreateBus(connectionString);
The connection string is the same format used by Service Bus for Windows (as in the above example) or Azure Service Bus. Service Bus for windows will tell you your connection string during configuration. On Azure, you can find the connection string for a given namespace in the management portal.
To close the connection, simply dispose the bus like this:
bus.Dispose();
This will close the connection, channels, consumers and all other resources used by AzureNetQ.
- Quick Start
- Introduction
- Casing in point: Topics and topics, Subscriptions and subscriptions
- Installing AzureNetQ
- Connecting to Service Bus
- Logging
- Publish
- Subscribe
- Request Response
- Send Receive
- Topic Based Routing
- Controlling Queue names
- Polymorphic Publish and Subscribe
- Scheduling Events with Future Publish
- Auto Subscriber
- Non Generic Publish & Subscription Extension Methods
- Replacing AzureNetQ Components
- Using a DI Container