Open/active perpetually?

Do you mean:

  Open connection

  Send message

  Close connection

With each message?

Or do you mean stay open (as long as no one closes the connection)?

If you mean the prior, then I think clicking the ‘Close after Write’ box on the ‘Data Options’ panel of the ‘PDL Options’ Dialogue will do that.

Here we prefer a TCP/IP connection be kept persistent (that is always open whether there are any messages or not.

Who is this vendor and what is the product?

Oh – are you using a VPN?

If so there are a number of posts regarding others issues with VPNs.

However, it is possible the VPN is closing the connection.

The default for Cloverleaf TCP/IP PDL is to be persistent (open until closed whether there are messages or not) so I think you have that set up correctly in Cloverleaf.

You may need to increase your keep-alives (see other posts) or the VPN admins may need to allow the connection to stay open.

Jim,

in your response, you mentioned the Close After Write protocol option, and other posts involving problems with VPN’s.

We are receiving results from another Cloverleaf engine through a VPN, which closes the connection after 1 hour of inactivity.  The result is that our inbound thinks it’s still connected, while their outbound goes to Opening.  The administrators of the VPN are not willing to change the timeout. If Close After Write is checked on the outbound thread on the other engine, will that resolve the problem?

I haven’t seen it mentioned as a resolution in the other postings about VPN connection issues, so am wondering if it will work.  (Our other option is a script to periodically bounce the connection on our end, which seems to restore the connection)

Thanks,

Hope Schnelten

Hospital Sisters Health Systems

Springfield, Illinois

hschnelt@ccc.hshs.org

217-492-2268

Since this is a server thread on your side your best option here is to use mult-server.  That way if the port is closed another will be be used

Hi Charlie,

I have read that using Muli-Server can solve this problem in some of the other posts.  However, I’m concerned that this will create a new connection but leave the “hung/stale” connection out there.  Am I thinking correctly about this?  Or, will Cloverleaf or the OS eventually time-out and close the previous TCP connection that was dropped by the vendor Firewall?

The vendor Firewall closes the connection after one hour of inactivity.  We only plan to receive one or two message per day on this connection, so I’m worried we have the potential of creating over 20 hung/stale TCP connections on our server each day.

Thanks,

You may see some ports in a Close/Wait state but they will eventually timeout

Another option is to set your keep-alive on the Cloverleaf boxes so that it is shorter than the timeout on the VPN.

Thanks Charlie and Chris,

we’re going to get with the vendor system’s Cloverleaf programmer and hash out the options.  

Hope

Hope,

The VPN is closing the conenction after inacivity – but not releasing the port – this is what is causing the issue.

In my opinion, the fault is with the VPN – it should release the port upon closing it.

Frequently altering the keep-alives can solve this issue but some VPN/Firewall admins configure their facilities to ignore packet level keep alives which makes that resolution useless. Moreover, if you encounter another VPN with a diferent timeout demand you may not be able to set the keep-alive timing to match all of the demands.

Charlie’s suggestion can work. There are some caveats here as well. Most of the time the default timeout for releasing a port left open combined with the frequency of reassignment of ports from the ephemeral range does not cause issues (this is what happens with multi-server and the condition you are experiencing) – however it can happen that you could exceed available ephemeral ports and I think this is much harder to troubleshoot.

Personally I think these admins need to justiify not releasing the ports.

Periodic stopping and starting the connection as server can also relieve the situation but might be overkill.

Others have suggested application keep-alives (‘dummy’ messages that both sides agree to). This might be accomplishable in your case because you are not exchanging durectly with an application. The othr Cloverleaf can create a ‘dummy’ message periodically (satisfying the brain-dead VPN) and you can kill it on your end. Personally, I don’t like the idea of sending any more message traffic across a connection than is necessary,

Thanks, Jim.  

I emailed the remote system’s network admin guy, to see if they can release the port.  We agree that the admins of the VPN/firewall should fix the problem, but cannot count on that happening.

We haven’t ruled out simply bouncing the thread via a ksh script scheduled in cron, or through a qdx alert.  But the other options will be discussed with the vendor, and we’ll settle on one.

thanks again to everyone who responded to this post.

Hope