nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

receiver retry count

System

Where do I set / change the retry count that is used for the receiver connect attempts in a deployment? The receiver is up and the socket open but no actions occur on that port.

"Exceeded all 3 retries to get a connection with the target OpenDeploy host."

Thanks

Find more posts tagged with

Comments

ISCBorisB

Where do I set / change the retry count?

odbase.xml, Tag <transportProperties>, attribute "connectRetries".

Note that if the base server was not able to establish a connection with the target host in three tries, changing it to 30
is normally a waste of time. You'll wait longer for termination, that's all

Migrateduser

The problem I have is that it takes 15 minuets to time out. I want to reduct that . I have change to the following;
localNode host="ControlHub" timeout="30" blockMaxWaitTime="60" blockCheckInterval="30" /

And its 15 min to time out?

Adam Stoller

The problem I have is that it takes 15 minuets to time out. I want to reduct that . I have change to the following;
localNode host="ControlHub" timeout="30" blockMaxWaitTime="60" blockCheckInterval="30" /

And its 15 min to time out?

According to the OD Deployment manual (621, page 25) the timeout value is specified in seconds - though "it may take as long as three times the timeout value for the deployment job to end"
However, at the very beginning of the section it says "... if a connectivity problem occurs during the deployment" - I'm not sure if "durring" means after a connection has already been established, or when trying to make the initial connection.

Note also that in the OD Admin Guide (621, page 158) it indicates that "You should alays configure a blockCheckInterval attribute value smaller than the timeout attribute value" - thus in the code you posted above you should probably make blockCheckInterval something like "15".

Not sure if that will help - but its worth trying to do it according to how its documented.

ISCBorisB

The problem I have is that it takes 15 minuets to time out. I want to reduct that . I have change to the following;
localNode host="ControlHub" timeout="30" blockMaxWaitTime="60" blockCheckInterval="30" /

And its 15 min to time out?

In your case all these settings are absolutely irrelevant. Note that 'timeout' terminates already established OD Session due to specified
inactivity interval ( DNR Taking too long, etc...). Your Base Server fails to establish a Session in the first place.

You either have a Connection problem (Networking, wrong Firewall settings, what have you) or your Receiver does not exist,
does not listen, does not respond, is in a funky state, etc

Migrateduser

I know I have a server problem. I am trying to reduce the time it takes for the CH to error out and continue. We use a quorum that allows the deployment to proceed. Where can I change the timeout for the connection error? I.E the connection is not rejected as in no port open on the server, but the connection is there but no CH session can be established.

Thanks for the help

ISCBorisB

I am trying to reduce the time it takes for the CH to error out...

With the regular OD the best you can do is to reduce "connectRetries" from the default "3" to 1 or 2.
Check Control Hub Documentation. May be CH exposes more configurational settings, who knows...

Migrateduser

I have gone through the docs and not found anything. I set it to 0 and got the delay down to 3 1/2 minutes

Thanks

chartExample.rptdesign

ISCBorisB

I have gone through the docs and not found anything. I set it to 0 and got the delay down to 3 1/2 minutes

Thanks

You may also want to consider using iwodcmd command to interrogate your receivers upfront and shape actual Deployments accordingly.
Format is: /od-home/bin/iwodcmd -host hostname -port portnumber serverstatus -q

Please note that
a) -q is a switch of serverstatus "action" and should go after it. In other words, this is not iwodcmd switch.
b) Interrogating (Base) host should be an "allowed" host on the target receivers