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; } } }

timeout setting in deployment

swong74

I've put a setting of timeout="10" minutes in each of our deployments. It works for normal deployments so far but apparently it doesn't count in the "DNR" time and I've seen that this bails in the middle of a DNR run which takes more than 10 minutes. So, how should I set this timeout if I don't know how long the DNR script would run beforehand esp. since the DNR does post-deployment corrections (e.g. dos2unix) and depending on # files deployment can be quick or long accordingly.

- sw

Ciao ?:-)
S. Wong

Find more posts tagged with

Comments

Adam Stoller

What version of OpenDeploy are you using here?
If you're using the 6.0 Beta (I believe you were) - please post those queries to the OD6 Beta forum.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

swong74

OD 5.6 sp1 on NT (base) and UNIX (rcvr). Yah, I'm testing the beta, too, but this is specifically for here. ;-) It's our production system and I've implemented a timeout in deployment configs because we observed a few times when the base server just hangs a deployment when the receiver gets "disconnected" somehow (network related ... either congestion or switch problems). And since we can't cancel, it's stuck until we restart the base. So, we've decided to do something like :
<localNode host="IL06WEB101" timeout="10"/>
and acc. to docs, it's the socket non-activity timeout ... but a DNR apparently is a socket inactive state so the base assumes that the deployment has gone nowhere and fails it although it is false. The reason I know this is 'coz when I set it to something like 120 (minutes), the same deployment succeeds. Then I switch it back to 10, it fails again. BTW, I clear the target path each time so I know it's the same number of files deployed each time. :-)
Thanks Fish.

Ciao ?:-)
S. Wong

Adam Stoller

Unless I'm mistaken (it does happen occasionally ;-) 'timeout' is not something which existed as a configuration option in 5.6 SP1 - there are svrTry* options (svrTryCount, svrTryInterval, svrTryDisableOverwrite, and by extension, rmReadOnly) - but those had to do with trying to replace a file that was locked by something like IIS - and not a general timeout for the deployment.

We had a couple of timeout issues at our customer's site where we were doing a multi-legged transactional deployment and there was a significant discrepancy in terms of the amount of time it took to deploy one of the legs from one of the others (discrepancy = >60 minutes) - which resulted in the shorter leg timing out waiting for the longer leg to "catch up". The solutions included re-balancing the legs of the deployment to reduce the discrepancy and [ultimately, in our case] turning off the transactional mode so that the different legs didn't wait for each other.

The source of the timeout in this case is (we believe, never 100% proved) a timeout imposed by the network configuration of the firewall we were passing through - and not something that we could control within OD.

Perhaps you can expand a bit on the details of your deployment (transactional or not? single-leg or multi-leg?, etc.)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

swong74

well, I was told by support that it was a config I could set per deployment ... it's in the reference doc (like I would've found this myself :-P). my bad, it wasn't minutes but in seconds. I guess I'll just have to bump it up to 60 seconds and see how that holds up. maybe 10 seconds is too short. but that means that during a DNR process, the base and receiver don't send anything through the socket eh? 'coz on non-DNR deployments, the 10 second timeout is just fine. unless I've not explored all possible combinations.
the deployments are single-leg and non-transactional. but OD has to wrap up after the DNR. that wait time I think is what falsely trigger the attempt to rollback. what do you think?

Ciao ?:-)
S. Wong

Migrateduser

The timeout feature you are using was introduced in the "jumbo patch" that came out after OD 5.6 SP1. The latest OD 5.6 docs cover this feature.

I think your assessment is correct... If the DNR processing time exceeds the timeout setting, then the base server will perceive this as socket inactivity and terminate the deployment.

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Adam Stoller

Ah - the jumbo patch - forgot about that one.
Is there a [reasonable] default value for the timeout? Would it be better to just leave it out all together unless the DNR is likely to run for more than 5 minutes?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

I couldn't remember and so had to look it up...

"No timeout attribute or a timeout attribute value of "0" indicates no timeout value is to be used."

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com