[omniORB] sockets/file descriptors
Ralf Walther
rw@neurotec.de
Mon, 01 Feb 99 12:13:00 GMT
Hi CORBAholics,
does anybody notice following facts, too?
- Five omniOrb servers are running
- All CORBA requests work fine
- After using database access with RogueWave (via Oracle OCI)
one omniOrb server gets blocked in the method
tcpSocketRendezvouser::run_undetached
(it is said, that this occurs, if the process can't get a new
socket, so
it has to wait until another process releases one, BUT there are
enough sockets on my machine)
- lsof -i reports following strange output:
=> myNS 28243 cminer 3u
inet 0x05fa6500 0t0 TCP *:1700 (LISTEN)
CMUserSer 28263 cminer 3u
inet 0x0bfc7900 0t0 TCP *:1704 (LISTEN)
CMSession 28266 cminer 3u
inet 0x05bd3400 0t0 TCP *:1701 (LISTEN)
CMClientS 28277 cminer 5u
inet 0t0 TCP no protocol control block
CMClientS 28277 cminer 6u
inet 0x05ff4d00 0t0 TCP idefix:2696->idefix:1700 (CLOSE_WAIT)
CMClientS 28277 cminer 8u
inet 0x0519b200 0t0 TCP idefix:2697->idefix:1703 (CLOSE_WAIT)
oracleALL 28278 cminer 3u
inet 0x07405f00 0t0 TCP *:2691 (LISTEN)
oracleALL 28278 cminer 5u
inet 0t0 TCP no protocol control block
=> oracleALL 28278 cminer 6u
inet 0x05ff4d00 0t0 TCP idefix:2696->idefix:1700 (CLOSE_WAIT)
oracleALL 28278 cminer 7u
inet 0x0bbfa900 0t0 TCP idefix:2691->idefix:2695 (CLOSE_WAIT)
Q0: What other reason than insufficient sockets could let a server block
in tcpSocketRendezvouser::run_undetached?
Q1: What does CLOSE_WAIT mean exactly? A process waits until a socket
connection was successfully closed?
Q2: Why does Oracle have a connection to the name service (see =>) on
port 1700. The port 1700 was given to the name service via command
line parameters.
Q3: Is it possible, that a socket connection could have a status, which
allows another process to use the same socket, too?
Q4: Does anyone have experiences with incorrect interactions between
omniOrb servers and other socket using apps?
Sorry for so many questions! Maybe one small hint can solve
a pile of them.
Thanks in advance
Ralf
-------------
rw@neurotec.de