2

We have a core system which communicates with its clients and other internal systems async through MSMQ. This is a good fit since clients are mobile phones sending sms’es and other systems has MQ adapters. Also these communication processes are asynchronous by default.

Now we have a requirement to support other systems which require a synchronous communication style be default. A typical example of this would be a handheld device, which supports rpc style request/response communication over HTTP.

There has been an solutions proposal to support this by adding a HTTP “proxy”/endpoint that pushes messages received from these clients on to inbound queue with a correlationId and then looks in outbound queue for a message with the same correlationId. Hopefully the processing of the message is done and the message with the expected correlationId will be present in the outbound queue. This would happen on the same thread as pushed the message in to the core system to mimic request response.

However we see that receiving messages by correlationId (MessageQueue.ReceiveByCorrelationId) is a performance killer. It does not take many client threads to really slow the system down.

I guess the problem is the proposed design with mimicking sync request-response using receive by correlationid approach is the issue here. In current architecture the outbound queue resides on a remote host, been reading up on this to see if that is the issue or not.

Does anyone have any other approaches for solving this? I guess the logical ting would be to stuff messages from outbound queue to a database or something from a single receiving process and then search that for messages that has the corresponding correlationId

flalar
  • 1,181
  • 3
  • 12
  • 23

1 Answers1

2

Performing a remote receive uses RPC and is not particularly quick but should be OK. When you add the use of cursors (in this case to search through the queue for the message with the desired correlationID) then performance will definitely not scale too well, as you are finding - more clients usually means more messages and a resulting slow-down as the cursor has to move further. You definitely want to do this sort of searching on a local queue.

How about getting the getting the back-end to Multicast the messages in the outbound queue? Then all servers that would normally remotely receive the Outbound queue messages can instead be sent a copy which would go into a local queue for ID-matching.

Cheers
John Breakwell

John Breakwell
  • 4,667
  • 20
  • 25