Two CL servers using same port

[Jeff Dinsmore]

I have a strange thing going on that I’m not understanding.

Today, I discovered that my production CL6.1.1 has two server threads configured to listen on the same port.  While that’s not unheard of, it looks like they’re both servicing connections – and from different servers.

Here is the current state of the two.  Note two separate CL processes have the same port (17202) open – each, apparently, with independent connections from different servers

Quote:

[hci@CLOVERPROD revisions]$ lsof | grep 17202

hciengine 20660       hci   38u     IPv4          561147294                  TCP cloverprod.chealth.org:17202->capsulevs2.chealth.org:61252 (ESTABLISHED)

hciengine 29900       hci   34u     IPv4          280203944                  TCP cloverprod.chealth.org:17202->6089900mlp.chealth.org:64726 (ESTABLISHED)

[hci@CLOVERPROD revisions]$ ps -ef | grep 20660

hci      20660 20659  0 10:02 ?        00:00:13 /opt/cloverleaf/cis6.1/integrator/bin/hciengine -S capsule -p capsule_ib

[hci@CLOVERPROD revisions]$ ps -ef | grep 29900

hci      29900 29899  0 Mar03 ?        00:09:32 /opt/cloverleaf/cis6.1/integrator/bin/hciengine -S pharmacy -p ib_from_pyxis

To make things even stranger, the two connections seem to be routing inbound messages to the correct inbound threads.

So, either I’m completely missing something obvious, or the OS (RHEL 6.7) and Cloverleaf are conspiring together to successfully do something that shouldn’t work…

I’m assuming it’s the former.  Can any of you spot what I’m missing?

Thanks!

Jeff Dinsmore
Chesapeake Regional Healthcare

Topic

[Keith McLeod]

Does your server have multiple network cards?  Are these ports bound to the same ip?  What does netstat show?

[Jeff Dinsmore]

The Cloverleaf VM has a single NIC.

Some netstat results:

Quote:

[hci@CLOVERPROD revisions]$  netstat -ae | grep 17202

tcp        0      0 cloverprod.chealth.or:17202 capsulevs2.chealth.or:61599 ESTABLISHED hci        561825913

tcp        0      0 cloverprod.chealth.or:17202 6089900mlp.chealth.or:55292 ESTABLISHED hci        561820695

[hci@CLOVERPROD revisions]$ netstat -r

Kernel IP routing table

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface

10.180.12.0     *               255.255.255.0   U         0 0          0 eth0

link-local      *               255.255.0.0     U         0 0          0 eth0

default         10.180.12.1     0.0.0.0         UG        0 0          0 eth0

Please let me know if you’re interested in any other netstat info.

Thanks,

Jeff Dinsmore
Chesapeake Regional Healthcare

[Levy Lazarre]

Jeff,

A while ago, I experienced the same situation you are reporting. I couldn’t understand how it could work, until I noticed that in the Protocol Properties of one of the server threads, somebody had checked the box “Use DRIVERCTL control”. That basically created a Multi-Server configuration for the common port (even though the Multi-Server option was not enabled!)

You may want to compare the two configurations to see if something similar is not happening in one of the connections. Somehow, you may be running Multi-Server.

[Paul Glezen]

The netstat output seems to indicate that port 17202 is a TCP CLIENT port (by virtue of only having the ESTABLISHED state).

[Jeff Dinsmore]

Levy –

Neither of the threads has “Use DRIVERCTL Control” checked.

Paul –

Both of the connections in question are, indeed, server threads.  

Once a connection is made, the “LISTEN” state goes away for a regular server thread – on my Linux OS, at least.  That would be consistent with allowing just one connection to any given listener that’s configured as “Server”.

If the thread is configured as “Multi-Server”, it continues to listen after connections are made.

So, I continue to be stumped.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Russ Ross]

I’m curious if in the Protocol Properties the

Local Binding Address

is set to anything for either of them.

Russ Ross
RussRoss318@gmail.com

[Jeff Dinsmore]

Nope.  No local binding addresses defined.

Jeff Dinsmore
Chesapeake Regional Healthcare

[Author]

Replies