Is there a way to monitor Request / Reply message traffic?What are the best practices for monitoring request / reply based projects?
Article ID: KB0086479
Updated On:
| Products | Versions |
|---|---|
| TIBCO Rendezvous | - |
| Not Applicable | - |
Description
Resolution:
Request / Reply mechanism uses the _INBOX subject. INBOX subject is a true point to point (unicast) message. It is not multicast, it goes directly to the IP address that it is targeted to; meaning that the network hardware may not even allow you to see the message.
Unfortunately, we do not have any tool which can be used to listen to "_INBOX.>". The reason is that it is not possible to listen to an _INBOX subject name that is created by another transport.
The _INBOX subject name is created by RV API and is guaranteed to be unique endpoints for receiving data. The inbox name is only valid for use with the same transport that created it. When calling tibrvEvent_CreateListener(), you must pass the same transport object that created the inbox subject name. Therefore, there is no tool that could capture the _INBOX reply messages.
Rvtrace (network analysis tool) also can be of limited help in this scenario as there is a further limitation on rvtrace in a switched ethernet environment. In a switched ethernet environment, rvtrace will see only those point-point messages which originate from or are directed to the machine on which rvtrace is running. Given that rvtrace should only be run on a dedicated machine, this is clearly a limiting factor.
Following is an excerpt from the documentation “TIBCO Rendezvous Administration” Chapter 11 Protocol Monitor (rvtrace):
“Switched network environments (such as switched Ethernet, or ATM) further limit the usefulness of rvtrace as a diagnostic tool. Since switching hardware forwards every point-to-point packet directly to its destination host, rvtrace detects point-to-point packets only when they either originate or terminate in the computer running rvtrace. In some switched networks, you can ameliorate this situation by disabling switching behavior—for example, by setting one port to diagnostic mode, or by using a diagnostic utility. This tactic can yield the full stream of point-to-point packets in a limited portion of the network; run rvtrace in that portion.”
Request / Reply mechanism uses the _INBOX subject. INBOX subject is a true point to point (unicast) message. It is not multicast, it goes directly to the IP address that it is targeted to; meaning that the network hardware may not even allow you to see the message.
Unfortunately, we do not have any tool which can be used to listen to "_INBOX.>". The reason is that it is not possible to listen to an _INBOX subject name that is created by another transport.
The _INBOX subject name is created by RV API and is guaranteed to be unique endpoints for receiving data. The inbox name is only valid for use with the same transport that created it. When calling tibrvEvent_CreateListener(), you must pass the same transport object that created the inbox subject name. Therefore, there is no tool that could capture the _INBOX reply messages.
Rvtrace (network analysis tool) also can be of limited help in this scenario as there is a further limitation on rvtrace in a switched ethernet environment. In a switched ethernet environment, rvtrace will see only those point-point messages which originate from or are directed to the machine on which rvtrace is running. Given that rvtrace should only be run on a dedicated machine, this is clearly a limiting factor.
Following is an excerpt from the documentation “TIBCO Rendezvous Administration” Chapter 11 Protocol Monitor (rvtrace):
“Switched network environments (such as switched Ethernet, or ATM) further limit the usefulness of rvtrace as a diagnostic tool. Since switching hardware forwards every point-to-point packet directly to its destination host, rvtrace detects point-to-point packets only when they either originate or terminate in the computer running rvtrace. In some switched networks, you can ameliorate this situation by disabling switching behavior—for example, by setting one port to diagnostic mode, or by using a diagnostic utility. This tactic can yield the full stream of point-to-point packets in a limited portion of the network; run rvtrace in that portion.”
Issue/Introduction
Is there a way to monitor Request / Reply message traffic?What are the best practices for monitoring request / reply based projects?
Feedback
Yes
No
Powered by
