tcp_acknak.pdl rtimeout and tmotries

[Ryan Spires]

Was wondering if anyone else has encountered this and what you are doing to handle.

The issue:

We use bridge threasd to send data to different processes and sites.

We have found that on occasion (more recently with 5.7) that our bridge threads appear to be hanging up…

We have configured the bridges to use the tcp_acknak.pdl to reduce overhead with the reply logic.

On 5.4.1, we used this just find, but found that we needed to increase the rtimeout due to duplicate messages being created.   The reply was not getting back fast enough.  We increased the rtimeout to 1 minute or 60000000 microseconds.   This seemed to do the trick and we did not see any issues.

on 5.7, however, it appears that we are occasionally getting hangups on those bridge threads.  Upon reviewing the 5.7 documentation I found something I had not seen before….tmotries

tmotries: count

Specifies the number of timeout events to allow before giving up on writing a message. This entry is optional and defaults to zero (0).

I was wondering if anyone knows if this was added sometime after 5.4.1 and if simply adding an entry to the pdl and recompiling with a value larger than 0 would allow the thread to resend.

With that said, i did find that the message on which was “hung” was sent twice.  Once before the hang and it was the message that was sent after the hang.   This largerly wouldn’t create any issues… specifically with adt, however, with charges it might…  

I have sent an email to support also, but just thought I would also reference the collective minds of the clovertech continuum.

Ryan Spires

Topic

[Jennifer Hardesty]

Did you resolve this issue?

[Ryan Spires]

Jennifer,

Yes, turns out that the rtimeout has been replaced with timeout (timeout works birectionally) and tmotries, specifies the number of retries.

I removed rtimeout from the pdl

added tmotries:3

addied timeout:60000000

This provides sufficient time for the thread to respond and will now retry if no response.

I have attached our version.

[Author]

Replies