RPC Problem?
Hi guys.
We have a problem with our Linux servers which we are running our SAP environment on. Users are able to connect and work via SAP-GUI on all systems without any problems. However, the SAP servers need to be able to make RPC calls to each other for the purpose of transporting data, configuration and so on from one server to another. These connections fail intermittently. SAP Germany has stated that they believe it to be a network problem, which is - quite frankly - bullshit. Why then do our users not experience interruptions? Besides which, we have gone through the standard hardware troubleshooting cycle, and everything appears fine. Last week I discovered that when I try to "rpcinfo -p servername" from one server to another, nothing happens at all. Yet if I ping the server I'm trying to "rpcinfo", and THEN run the command it immediately returns the list of listening services. It's almost like the rpcd (or whatever) goes to "sleep" and doesn't answer requests until some other sort of traffic is generateed. Does anyone know of any configuration options with RPC stuff on Linux that could cause behaviour like this? I've been Googling without much success. PS: Not a DNS resolution issue as testing with IP addresses yields the same results. |
From RPC specifications (RFC1831)
http://www.ietf.org/rfc/rfc1831.txt 4. TRANSPORTS AND SEMANTICS The RPC protocol can be implemented on several different transport protocols. The RPC protocol does not care how a message is passed from one process to another, but only with specification and interpretation of messages. However, the application may wish to obtain information about (and perhaps control over) the transport layer through an interface not specified in this document. For example, the transport protocol may impose a restriction on the maximum size of RPC messages, or it may be stream-oriented like TCP with no size limit. The client and server must agree on their transport protocol choices. It is important to point out that RPC does not try to implement any kind of reliability and that the application may need to be aware of the type of transport protocol underneath RPC. If it knows it is running on top of a reliable transport such as TCP [6], then most of the work is already done for it. On the other hand, if it is running on top of an unreliable transport such as UDP [7], it must implement its own time-out, retransmission, and duplicate detection policies as the RPC protocol does not provide these services. So as I can understand, the application chose what king of transport to use... So it might be a problem with the application it self ?? Good luck! |
All times are GMT -5. The time now is 07:13 AM. |