S
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.
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.