Service broker - multiple queues vs single queues when communicating with external apps -


We currently have an application that uses a service broker to queue messages sent to an external system. , Which we communicate through the web service interface.

At present, we are only integrated with one company, so a line is enough - although we have to start conveying to many companies which all use the same web service interface.

I am thinking that a single queue system is enough for this or we have a queue per company, with queue per company I am concerned about scaling it because we have many lines and then There are too many connections to check queues.

With a queue, we can only add more readers as needed. However, if we can not talk to an external system (such as a connectivity issue), there is no problem with the message, and we want to try it again, but we do not want to delay the messaging of companies whose The systems are up, I was wondering how people are working with such scenarios?

We can rejoin the message, but I worry about it that we do not guarantee delivery order.

I assume that a message is "rescheduled", which means that you Roll back which had received it. The effect will be that the message will be available to retrieve the message as a message before a given conversation (so do not worry about preserving delivery order). He said, there is a problem with this approach, that is, if the queue received from the given queue is brought back 5 times, the queue will be inactive.

An alternative approach, which is described in detail, is a table of pending requests. As soon as the active process receives a request message from the service broker queue, it tries to call the web service. If this fails for some reason, the request is placed in the pending request table and once again the attempt is made (you can use it to reschedule), in this way, if any web service is available If not, this service will not block the broker reader from serving other companies (assuming the timeout for the first request is too small). And since the web service call does not matter if you succeed, you will not run into the poison message problem.


Comments

Popular posts from this blog

sql - dynamically varied number of conditions in the 'where' statement using LINQ -

asp.net mvc - Dynamically Generated Ajax.BeginForm -

Debug on symbian -