Responder Communication Framework White Paper
Responder’s MSMQ .NET Remoting Channel infrastructure is built on top of MSMQ to facilitate communication between components. MSMQ .NET Remoting Channel handles communication between the following. Note that these are the blue lines on the diagram on the Responder Communication Framework Overview page.
- Responder Explorer and Data Services (Client-Server)
- Query Services and Data Services (Server-Server)
- Archive Services and Data Services (Server-Server)
- Prediction Services and Data Services (Server-Server)
- The Responder web application and Data Services (Web Server-Server)
- The Responder web application and Prediction Services (Web Server-Server)
- Archive Explorer and Archive Services (Client-Server)
MSMQ .NET Remoting Channel uses message queues to reliably send messages back and forth as needed. The Responder applications automatically create the necessary message queues for their roles on start-up. For example, if you need to create (or recreate) message queues for Archive Services, you must start Archive Services.
Troubleshooting Tip
Should message queues be deleted, simply restart the corresponding application or service to create the queues again. |
A client machine (e.g., running ArcMap and Responder Explorer), should have the following queues. The rxarchivexplorer queues are only created if you're running Archive Explorer.
| Responder Explorer: | ArcMap: | Archive Explorer: |
|---|
| rxexplorer.acknowledge | arcmap.acknowledge | rxarchiveexplorer.acknowledge |
| rxexplorer.response | arcmap.response | rxarchiveexplorer.response |
Your Responder set-up will likely include multiple client machines. Each machine will have its own set of message queues. The Responder server machine also has its set of message queues used by the Responder service (e.g., Data Services, Prediction Services). The following message queues are created on the Responder server when the corresponding service is started.
| Archive Services: | Prediction Services: | Data Services: |
|---|
| rxarchive.service | rxprediction.service | rxserver.service |
| *rxarchive.service.delay | *rxprediction.service.delay | *rxserver.service.delay |
| *rxarchive.service.high | *rxprediction.service.high | *rxserver.service.high |
| *rxarchive.service.low | *rxprediction.service.low | *rxserver.service.low |
*As of version 9.3 Rev2 these queues exist on the message router rather than on the Responder server.
Your Responder configuration may include multiple Responder servers or a single server. If you have multiple Responder server machines, each server will have its own set of message queues for each type of service being run (e.g., Data Services, Prediction Services). A Responder server may run multiple instances of each service (e.g., Data Services). However, there will still be one set of message queues per service type per server machine (not per service).
Message Router
The message router facilitates communication between the client machines and the Responder servers using message queues. Every Responder server in your configuration will have an internal message router by default. If you have a single Responder server machine, there is no additional configuration necessary for the message router. However, if your configuration includes multiple Responder server machines, you will need to configure each server to point to a single message router (see the Message Router Configuration topic in the Responder Configuration Guide). This message router can be on a separate machine or on one of the Responder server machines. Following are the message queues used by the message router. Each service will have its own control queue to be used by the message router.
| Archive Services: | Prediction Services: | Data Services: |
| rxarchive.request | rxprediction.request | rxserver.request |
| rxarchive.control | rxprediction.control | rxserver.control |
|
*rxarchive.request.low
| *rxprediction.request.low | *rxserver.request.low |
| *rxarchive.request.high | *rxprediction.request.high | *rxserver.request.high |
| *rxarchive.request.delay | *rxprediction.request.delay | *rxserver.request.delay |
*Prior to version 9.3 Rev2 these queues existed on the Responder server rather than the message router.
Troubleshooting Tip
In 9.3 Rev2 and later, if you see a build-up in the .request queues, start-up additional instances of message routers. A build-up in the request.high or request.low queues may indicate a need for more instances of Responder services.
|
The following diagrams depict how Responder Explorer (client machine) communicates with Data Services (Responder server machine) using MSMQ .NET Remoting Channel and the message router. These diagrams differ in the number of clients and servers in the Responder configuration.
Integrated message router (above)
Separate message router
The numbers below correspond to the numbers in the diagrams above. The diagrams above that have multiple servers do not show the message router component on the additional servers. Every Responder server has a message router. However when you have multiple servers in your configuration, all servers should use a single message router.
- From the Responder server machine(s), Data Services sends a message to the rxserver.control queue on the message router to indicate that it is available. This message contains a reply address to that specific Data Services service queue.
- Responder Explorer sends a request message to the message router’s rxserver.request queue.
- The message router prioritizes the request messages into the high and low queues.
- The message router gets a message from the high or low request queue and forwards it to Data Services using the forwarding address from the rxserver.control queue.
- A Data Services process receives the message from the service queue and processes it. You may have multiple Data Services processes accessing the rxserver message queues.
- Once processing is complete, the Data Services process sends a response to the rxexplorer.response queue on the client machine from which the message originated.
- Should Data Services encounter an error during processing it still sends a response to the client machine. If the error is one Responder believes it can process at a later time, the message is placed in the delay queue.
- The message router monitors the delay queue and after a set amount of time moves a message out of the delay queue and back to the request queue where it is reprioritized and processed (step 3).
Note
Messages are always sent from the message router to the Responder server machine(s), eliminating the need for remote reads.
|
