If you are using Service Bus, you should know that you have the ability to be notified when a message is available in the queue or in a subscription. Using this feature you don’t need to call the "Receive" method and catch the timeout exception when there are no new messages are available.
When using Service Bus, you pay for each transaction. Because of this each call of “Receive” method will consume a transaction. Even if there are no available messages and the call finish with a timeout exception, you will have to pay for one transaction.
Base on this, we should know that a similar thing is happening when we are using “OnMessage”. The behind implementation of this method use “Reveive” method and has a timeout value. Because of this, even if you register to “OnMessage” once you will notify that more than one transactions are consumed even if you don’t have messages in the Service Bus.
This is happening because “OnMessage” calls “Receive” method that will consume a transaction when a message is available or when a timeout exception occurs. The default timeout value is 60 seconds. This timeout value can be easily change using MessagingFactory.
From the cost perceptive you should not have any kind of problems. The cost of each client that use “OnMessage” method and has the timeout value set to 60 seconds is 4.3 cents per month.
In conclusion “OnMessage” is very useful because offer out of the box a mechanism that give us the possibility to be notified when a message is available – until now we had to implement this mechanism every time. You should not forget that this mechanism will handle each new message on a different thread and there are times when you want to control the concurrent level. Also it generates some costs, but the cost is similar with the “Receive” mechanism – in the end “OnMessage” use “Receive”.
OnMessageOptions messageOptions = new OnMessageOptions()
{
AutoComplete = true,
ExceptionReceived += LogErrorsOnMessageReceived
};
queueClient.OnMessage((message) =>
{
...
}, messageOptions);
As you can see, you register to an event that will be called when a new message is available. If there are more than 1 messages available the event will be triggered more than one. Each notification will run on a different thread. To be able to control the number of concurrent messages that can be received by a client you should change the value of "MaxConcurrentCalls".OnMessageOptions messageOptions = new OnMessageOptions()
{
AutoComplete = true,
ExceptionReceived += LogErrorsOnMessageReceived
MaxConcurrentCalls = 5
};
queueClient.OnMessage((message) =>
{
...
}, messageOptions);
But what about the costs?When using Service Bus, you pay for each transaction. Because of this each call of “Receive” method will consume a transaction. Even if there are no available messages and the call finish with a timeout exception, you will have to pay for one transaction.
Base on this, we should know that a similar thing is happening when we are using “OnMessage”. The behind implementation of this method use “Reveive” method and has a timeout value. Because of this, even if you register to “OnMessage” once you will notify that more than one transactions are consumed even if you don’t have messages in the Service Bus.
This is happening because “OnMessage” calls “Receive” method that will consume a transaction when a message is available or when a timeout exception occurs. The default timeout value is 60 seconds. This timeout value can be easily change using MessagingFactory.
From the cost perceptive you should not have any kind of problems. The cost of each client that use “OnMessage” method and has the timeout value set to 60 seconds is 4.3 cents per month.
In conclusion “OnMessage” is very useful because offer out of the box a mechanism that give us the possibility to be notified when a message is available – until now we had to implement this mechanism every time. You should not forget that this mechanism will handle each new message on a different thread and there are times when you want to control the concurrent level. Also it generates some costs, but the cost is similar with the “Receive” mechanism – in the end “OnMessage” use “Receive”.
Do you have any guidance for choosing a value for MaxConcurrentCalls?
ReplyDeleteA magic number don't exists. Depends on what kind of action you are executing when a new message is available. For example if the action will call the DB that you may be limited of the number of connection that you can have to DB. On the other hand if you have an action that is CPU intensive that you will not be able to run in parallel to many tasks.
ReplyDeleteBased on my experience this value should be around 5 or 10.
But how to gracefull shutdown/stop a message pump!?
ReplyDeleteThere is now yet a gracefull mechanism. You can cal 'close' method, but odd behavior can appear.
Deletewhats the default value of MaxConcurrentCalls property?
ReplyDeleteDefault value is '16'
Delete