Opening status – WSAEWOULDBLOCK/WSAEINVAL

[Rick Martin]

I continue to have problems starting outbound (TCP over VPN) threads where the thread will go into OPENING status with WSAEWOULDBLOCK and WSAEINVAL connect errors.  If I just let it sit there, it will try again in the timeout period (60 secs), but usually continues to receive the WSAEINVAL error. Sometimes restarting just the thread will allow it to connect and go to UP status, but sometimes I have to restart the whole process to get it to connect and go to UP status.

I know folks have said this is most likely not a Cloverleaf error, but then why would bouncing the process instead of just the thread work?  What is Cloverleaf doing when bouncing the process that it’s not doing when bouncing just the thread?

Anyone else experiencing this?

We’re running 5.3 on Windows 2000 Server.

Topic

[Traci Zee]

Rick,

This is just a guess.  When you stop the process the OS properly disconnects the tcp/ip connection so when you restart it comes back up.  When you stop the thread, the connection sometimes drops completely and sometimes doesn’t.

For my systems which are mostly UNIX, when tcp/ip over VPN fails there is a timeout issue.  Trouble is that there’s timeouts all over the place.

One of each of these for the Sending and Receiving systems.

1.  VPN timeout

2.  Firewall timeout

3.  OS TCP/IP timeout  <<< at least on Unix I've had to adjust this. 4.  Application TCP/IP timeout Any timeouts that occur for 1, 2, or 3 may cause odd status/connectivity in 4.  I make sure these are all longer than the Cloverleaf timeouts.  1 & 2 can have ‘inactivity’ timeouts. So, to conquer this problem, start asking about timeouts, inactivity timeouts, and are there any other timeouts from your network, firewall, and systems engineers.  There may be more than one firewall device that may need to be changed and they forgot it was in the loop.   A sniffer on the network goes a long way to telling you who isn’t playing by TCP/IPs rules. Traci Zee Emdeon

[Rick Martin]

Hi Traci,

Thanks for the reply!  How the heck are you?

I’ve thought about the timeout thing, but here’s the rub.  This usually occurs when starting the thread.  Some of our outbound threads are started once per day to transmit results and then brought down until the next day.  This problem occurs when starting the thread.

The curious thing is that even though Cloverleaf is unable to open a connection, I can successfully telnet into the remote server using the same IP/port.

Thaks, Rick

[Daniel Lee]

I’m not a TCP/IP expert by any means so take this with a grain of salt.  But my thoughts is that it could be a firewall timeout that could go something like this:

1)  You have a valid TCP/IP connection.

2)  The firewall times out but neither the sending or receiving side get a TCP/IP disconnect.

3)  You stop the Qvdx thread but the receiving system doesn’t get the disconnect message because of the firewall timeout.

4)  You start the thread again but the receiving system doesn’t accept your connection because it thinks it already has an open TCP/IP connection on that port because it never got the TCP/IP disconnect.

5)  Everything sinks up fine again when you cycle the receiving systems interface.

I’ve run into something like this before with sending messages to an Open VMS system.

[Patricia Smith]

Rick,

This is John Calhoun at Owensboro Medical Health System.  We’re having the same problem that I think you had.  We have a thread that we are sending ADT and Orders to over a TCP/IP VPN connection.  I’m getting the WSAEWOULDBLOCK and WSAEALREADY errors and the thread loses connection.  Did you ever find a solution to your problem?  If so, I would like to know what you did to fix it.

Thanks again,

John Calhoun

270-852-8562

jcalhoun@omhs.org

[Rick Martin]

Unfortunately, no.  We typically have to either manually stop/restart the thread (multiple times) to try and establish the session, or sometimes shutdown the process and restart the threads in order to get a good connection.  Very strange as a simple telnet works fine.

[Nathan Martin]

Ever try an “Await Replies” Timeout of something other than -1?  And/or using “Close after write” in the protocol setup?

Just a thought.

[Rick Martin]

Hi Nathan,

No, never tried that.  We currently have Await Replies timeout set to -1, Close after write and Use DRIVERCTL control both UNchecked and Auto-reconnect checked with a Reopen time of 300 seconds.

What are your settings?  Do you think changing one of the above settings would help this situation?

Thanks, Rick

[Nathan Martin]

I use 60 or 90 seconds for Await Replies and check Auto-reconnect with a Reopen time of 5 seconds.

Close after write is usually UNchecked because I don’t like dropping connections on purpose — but it might be a good idea for particularly troublesome VPN issues.

Never have checked “Use DRIVERCTL control” on a PDL TCP/IP.  Not sure what it does.  (Documentation says it will reconnect the connection after a write.  I got the idea you could use it to reconnect to a different address or port, assuming you have a proc to update DRIVERCTL.)

If possible, we also have the network admins set their connection / vpn session timeouts for longer than the time we expect to see between messages.

[Author]

Replies