MSMQ Design Question

[Stephen Barrett]

I have a multi-tier application. The UI tier talks to a BL tier that is
running on a remote server. The BL tier is hosted in a windows service in a
single app domain. The BL tier sometimes needs to access a 3rd Calc tier
that does higher end processing. The process is cpu intensive, but only
takes a second or so. Due to increasing demand on the Calc tier, we need to
be able to load balance the process.

We are currently accessing the calc tier from the BL tier via SingleCall
remoting. We looked into NLB for the calc tier, but it does not take into
account that some machines can process more than others. For instance Calc
server 1 may be able to handle 5 concurrent requests, but Calc server 2 may
be able to handle 10. Using NLB, Calc server 2 will under utilized possibly
resulting in Calc server 1 getting overloaded.

We started a design using MSMQ to replace the communication between the BL
tier and the Calc tier. This works great because an individual server will
only try to process a message in the queue if it knows it has resources to
do so. The problem I am having is the call needs to seem syncronous to the
UI tier. They push a button and get the results.

I have no problems getting the message to the queue that is read for
processing. Works excellent. The problem is getting the results back to
"client" who requested the service. In the past with C/S type applications,
I had private queues on the client machine that the service would write back
to. I can't do this now, because my "client" is actually a single app
domain running multiple threads that are servicing the remoting calls. I
would almost have to build a private queue for every thread execution which
is of course not reasonable.

Does anyway know of an efficient way to handle this scenario? Some ways I
thought about are:
1. letting each thread enumerate the message queue looking for it's return
message and the do a ReceivedByID, but seems like a lot of processing power.

2. have the thread just doing a peek until their message comes back to the
front of the queue, but if something happens and a thread aborts, all
messages would be blocked because nothing would process it's message.

3. building a dispatcher that would be the only thing processing the
"client" results queue and then route it to the appropriate thread as a
message.

Any comments or suggestions would be highly appreciated.

 

[Guest]

If you require a system that appears synchronous, you are going to have to
wait for the answer, even if it comes from queue. Whatever process
communicates back to the client will be the best bet for handling this.


---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Alvin Bruney [MVP]]

One approach might be to tag the message with the thread id. The calc tier
would then package the results into a message which would be shipped off to
a central results MSMQ where it would sit and wait.

When you multiple threads fire requests, they sleep and wake periodically to
check the results queue for messages that match their thread id. If the
thread dies or is aborted, the message rots in the queue. You may probably
want to set a reasonable message timeout for this case.

--
Regards,
Alvin Bruney

Shameless Author plug
The Microsoft Office Web Components Black Book with .NET
http://tinyurl.com/27cok

 

[Nick Malik [Microsoft]]

We are currently accessing the calc tier from the BL tier via SingleCall

remoting. We looked into NLB for the calc tier, but it does not take into
account that some machines can process more than others. For instance Calc
server 1 may be able to handle 5 concurrent requests, but Calc server 2 may
be able to handle 10. Using NLB, Calc server 2 will under utilized possibly
resulting in Calc server 1 getting overloaded.

I hate to say this, because you've probably invested heavily in the MSMQ
solution already, but if you were to have invested in a better Load
Balancing solution, you would be able to balance nodes of different sizes
quite easily.

Note that NLB on Windows 2003 _does_ allow you to set the port weight, which
means that you can specify that you want five times the number of requests
to go to node 2. However, the Windows product (which is free) does not
measure the ability of the node to handle the request. It's not
particularly good for a failover solution without also installing
clustering.

On the other hand, there are solutions on the market that do measure the
ability of the servers to handle the requests. Simply purchasing one of
these solutions would be a more cost efficient mechanism than investing
heavily in software.

Using one of the higher-end products gives you the behavior you need. The
load balancer will monitor how busy a particular node is, and will send as
much traffic to that node as necessary to make it "as busy" as the other
nodes. This allows you to have a dozen nodes with different capabilities,
and the system simply adjusts. If one node goes down, the system simply
balances the new requests to other nodes. No need for complex clustering
technologies in other places. Where the Microsoft solution provides three
or four algorithms for balancing the load, higher-end solutions often
provide fifteen or more algorithms.

The products I usually recommend come from the F5 corporation. (www.f5.com)
The best way I've found to purchase them is through Dell (which makes the F5
BigIP load balancer available at a lower price than buying it directly from
F5... ). It is easy to manage and configure (all being done via a web
interface).

I'm not saying that there is anything wrong with using MSMQ. I'm just
suggesting that you may get a better solution by going back to an idea that
you may have discarded too early.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--