Problem:
- Product Name: VisiBroker for C
- Product Version: 4.x
- Product Component: ORB, Communication
- Platform/OS Version: Windows
Questions about TCP resets and CORBA::TRANSIENTS behavior of Visibroker:
TCP Resets occur because of excessive (greater than 62 connections) connections held by a CORBA server. Once the number of connections exceeded the "maximum" (originally, around 62), CORBA would then use 5 TCP "backlog" connections. Once these TCP connections were used, CORBA would then begin "breaking" the TCP connections (causing the TCP Reset errors we saw).
When does the CORBA::TRANSIENT occur? Why? From where does it occur?
Resolution:
The magic number of 62 is only related to shared memory connection cases on Windows, it is the maximum limit. It has nothing to do with TCP.
The number 5 is the connection backlog for windows NT workstation. It does not mean only 5 TCP connection is allowed. Also for Windows 2000 Advanced Server the maximum backlog limit is 200 .
Once these TCP connections were used, CORBA would then begin "breaking" the TCP connections (causing the TCP Reset errors). This is a different issue and not related to CORBA::TRANSIENTs encountered when binding using LIOP for which VBC 4.5.P29 is provided.
VisiBroker does connection swapping and does not break connections.
A CORBA::TRANSIENT exception will occur if the attempt to make a connection fails. This is as designed to report errors. This exception is thrown from the Visibroker runtime and usually on the is_local() and request() call in the stub method.
Related Articles
[[knowledge_base: Failure 38137: VBC 4.x, 5.x: Clients getting CORBA::TRANSIENT exceptions on Windows during high load on server when using LIOP]]
[[knowledge_base: Questions about the details of shared memory implementation in Visibroker]]
[[knowledge_base: How to find number of connections used by a specific CORBA server?]]
[[knowledge_base: Visibroker Connection Management Settings Advice]]
#Security
#VisiBroker
