› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Outbound thread using TCP/IP help
-- Max Drown (Infor)
It maybe something in your VPN connection. You’ll have to have your Network Grus look into it. You can start by trying to PING the address you are trying to connect to… Firewalls on both sides also cause lots of problems if not configured properly….
Hope it helps, Mary.
If I turn on enable-all in the thread, what should I look for in the log?
It doesn’t take that long and could save some headache.
I would confirm the message encapulation. Many times in my past this has happend where the vendor is expecting something other the the standard MLP.
[pdl :PDL :ERR /0: Nighthawk:03/26/2008 14:29:35] read failed: Connection timed out
[pdl :PDL :ERR /0: Nighthawk:03/26/2008 14:29:35] read returned error 78 (Connection timed out)
[pdl :PDL :ERR /0: Nighthawk:03/26/2008 14:29:35] PDL signaled exception: code 1, msg device error (remote side probably shut down)
Engine idle — 03/26/2008 14:29:50
Engine idle — 03/26/2008 15:40:22
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 1 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:42:15 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 2 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:42:45 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 3 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:43:15 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 4 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:43:45 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 5 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:44:15 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 6 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:44:45 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 7 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:45:15 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 8 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:45:45 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 9 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:46:15 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 10 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:46:45 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 11 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:47:15 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 12 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:47:45 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 13 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:48:15 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 14 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:48:45 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 15 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:49:15 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 16 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:49:45 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 17 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:50:15 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 18 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:50:45 EDT 2008
[pdl :PDL :ERR /0: Nighthawk:03/26/2008 15:50:53] read failed: Connection timed out
[pdl :PDL :ERR /0: Nighthawk:03/26/2008 15:50:53] read returned error 78 (Connection timed out)
[pdl :PDL :ERR /0: Nighthawk:03/26/2008 15:50:53] PDL signaled exception: code 1, msg device error (remote side probably shut down)
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 19 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:51:15 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 20 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:51:45 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 21 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:52:15 EDT 2008
RESEND_OB_MSG_38/Nighthawk/reply_gen: Resend 22 of saved msg with MID ‘0.0.16989925’ at Wed Mar 26 15:52:45 EDT 2008
I have await replies set to 30 seconds
I found a pdl that had the following settings:
hci_pd_msg_style basic phrase:basic-msg
field:data
resync:\xb
timeout:60000
I used this pdl and turned eo config to PDL enable-all. In the recovery database it had a message in state 14. I started up the thread and viola it was sent, a reply was received and state 14 was removed. I need to try more messages, as I am not convinced the pdl is the issue, but this is at least promising.
We had the same issue with a number of our VPN’s as well. The cause was that the VPN tunnel was going down but not notifying the engine. We solved 99% of our problems by decreasing our servers tcp keep alive setting to 15 minutes. Here is a previous post that give a good discussion of this:
John Mercogliano
Sentara Healthcare
Hampton Roads, VA
I have noticed in the process log where this thread resides every 2hr and 13minutes I see the time out pdl error. The engine will be idle, then 2hrs and 13 minutes, the pdl time error appears. Then if I try to send out some messages and I never get an ack back. I don’t see this error in the process logs that have idle time. I’ve talked to our network guy and he states if I can ping the receiver server everthing is ok. How can I tell if the VPN tunnel is going down?
Gary
They only way is I’ve made the assumption that the tunnel is down if that the connection is up but messages are queueing. They only thing we can do at that point is bounce the connection and see if it comes backup. Also, pinging is not a real solution because just the act of pinging causing the vpn software to reattach, so just because the ping worked does not mean the tunnel did not go down.
John
John Mercogliano
Sentara Healthcare
Hampton Roads, VA
Thanks to all for tips and suggestions!
Gary