Outbound Thread with infinite Reply timout

[Sundeep Kumar]

If a outbound tcp-ip pdl protocol thread in client mode has a reconnect time of ‘5’ but has a reply timeout (wait for ACK) set to -1 it seems to lead to a paradoxical situation: If the external server to which this thread talks does fail to return an ACK then the message goes to state 14 and pends and the thread just sits there without timeout. If the other server does reboot the cloverleaf client thread refuses to reconnect automatically even if you set reconnect to ‘5’ because I guess it thinks it has to wait infinitley for an ack. So nothing happens till the cloverleaf thread also is restarted. IT leads me to believe that setting a timeout of -1 on reply threads for outbound threads connecting in client mode may not be a good practice. Can anyone validate this ?

Topic

[John Hamilton]

The time out of -1 one tells the engine to wait for ever and never time out while waiting for the ACK.

The reopen on disconnect in your case  5. Says if the remote system disconnecting or is not connected wait 5 seconds before you try to connect again.

So the reality if you think you can send a message and not get the ACK then I would not set it wait on  too -1.  I have two system here one that when  it goes too the backup state it will not send the ACK’s but will accept and queue the messages. When it get done with the backup I will get an ACK for each message that was sent.

The other if I don’t get the ACK and resend, when it comes back up it will only processes the last message that was sent.

So it is based on the reliability of the ancillary system and the way it deals with messages.  I am sure there are as many combinations of what needs to done as there are people on this forum. So there is no set answer. You just need to think about what your remote system does. And configure your side to deal with it ability. And test, test test too make sure it works the way you were told.

Thank You.

[Jim Kosloskey]

Sundeep,

My guess is the receiving systm has not released the port (probably a Windows platform).

T verify,

Turn the Engine ‘noise’ level up and I bet you’ll see the engine trying to reconnect but the reconnect is failing.

The reconnect attempts after the delay time should happen no matter what the wait for reply timeout is set to.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Michael Hertel]

Sundeep,

Reconnect time is for the protocol level.

Reply timeout is for the application level.

Reconnect will not reset the Reply timeout.

[Author]

Replies