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

Deployment timeout - how does it work?

System

We're running into the situation where we've got a deployment that deploys to multiple targets and, if one of the receivers is down, then the whole deployment sits there for a long time before completing (with errors).

I looked at the doco on setting up a timeout - but it isn't totally clear.

If I set up a timeout for on a deployment that targets 3 servers and one of the servers isn't available, will the whole deploymnet fail? To all receivers?

Or is there a way to configure it so that the deployment will go to all servers that are available, and do a quick timeout on the ones that aren't available?

This is all on Solaris, v. 6.02 of OD.

Wally Box
Nike, Inc.

Find more posts tagged with

Comments

Migrateduser

If the target receiver isn't available, perhaps due to the server being offline, there is a connection retry count setting you can use to determine when the sender should give up.

The timeout doesn't come into play unless a connection is successfully established between a sender and receiver.

If a deployment is non-transactional, all targets should receive content, except for the one that wasn't available or timed out.

If a deployment is transactional, a failed connect or timeout should trigger rollback on all targets, unless you set the quorum value to something less than the total number of targets.

rodigz

Hi Todd,
Where to setup the retry setting?

thanks!

nipper

Page 186 of the OD 6.2 Reference manual

rodigz

thanks. my version is 6.1 Solaris 10.
Basically. If deployment failed; I want to do retry at least 3 or 4 times.
I can re-run the command if fail.
Just checking, what is the best practice??
thanks.

nipper

page 148 of the 6.1 reference manual lists the SvrTryCnt and SvrTryInterval parameters in the transfer-rules section of the config xml file.

Page 127 talks about the localnode timeout.

rodigz

thanks. mentioned in the svrTryInterval (Windows only) — receiver should be in windows. How about a solaris environemt?
thanks.

ProfessorX

If the target receiver isn't available, perhaps due to the server being offline, there is a connection retry count setting you can use to determine when the sender should give up.

The timeout doesn't come into play unless a connection is successfully established between a sender and receiver.

If a deployment is non-transactional, all targets should receive content, except for the one that wasn't available or timed out.

If a deployment is transactional, a failed connect or timeout should trigger rollback on all targets, unless you set the quorum value to something less than the total number of targets.

Is this the same for doing a reverse deploy?
Because I currenty have an issue that netwroking is working on...the Server is up...OD reciver is running but there is an issue with the OD port.
I am able to ping the server but unable to telnet to the IP and port

When I run the OD reverse dpeloyment I get this in the logs
ENG: 2008-07-16 14:17:54 EDT GMT-04:00 Thread-16848 Connecting to host=****.****.****.**** port=xxxxx
ENG: 2008-07-16 14:17:54 EDT GMT-04:00 Thread-16848Sender Side timeout set for the entire deployment
ENG: 2008-07-16 14:17:54 EDT GMT-04:00 Thread-16848 Buffer Size is 8000
ENG: 2008-07-16 14:36:22 EDT GMT-04:00 Thread-16848 ***ERROR - Job ID=000000000000000016Deployment=SvrLogs/location/LOGS_NEXTGEN
Base: Exceeded all 3 retries to get a connection with the target OpenDeploy host.
Failed creating socket.
ENG: 2008-07-16 14:36:22 EDT GMT-04:00 Thread-16848 exiting setup

I have this set in the deployment config

Question? Why does it take over 18 minutes to complete if I have the time out set to 180 secs or 3 minutes?

OD Version 6.2.0.0.0

Found this link on the support site but I dont think it applies here since I have 6.2 installed
https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=52465

Frederik

I realise this is an old thread, but I'm having the same issue.

Sender OD is stuck forever (or too long IMHO), when connecting to a targer OD server. The target Unix server is up, but OD receiver itself isn't running on it (some port or permission issue is stopping it from launching)


ENG: 2009-03-23 15:37:29 MET GMT+01:00 Thread-2664 entering setup
LIB: 2009-03-23 15:37:29   LOGFILE=[/logfiles/od/src.my_deployment.config.scws0001.to.target02.log]
LIB: 2009-03-23 15:37:29   Locale=[English_UnitedStates.US-ASCII@Binary]
ENG: 2009-03-23 15:37:30 MET GMT+01:00 Thread-2664 Connecting to host=scwaa180 port=20014

ENG: 2009-03-23 15:37:30 MET GMT+01:00 Thread-2664 Sender Side timeout = 120

ENG: 2009-03-23 15:37:30 MET GMT+01:00 Thread-2664Sender Side timeout set for the entire deployment

ENG: 2009-03-23 15:37:30 MET GMT+01:00 Thread-2664 Buffer Size 8000
ENG: 2009-03-23 15:52:32 MET GMT+01:00 Thread-2664 ***ERROR - Job ID=m1314Deployment=bzws_deployment_configWA
 Base: Exceeded all 3 retries to get a connection with the target OpenDeploy host.
       Failed creating socket.

While this deployment is stuck, other deployments started are queued but not processed.

I added the localNode timeout="120" attribute, hoping to have that reduce the timeout time, but it's having no effect.

Well, Todd did say earlier in the thread: "The timeout doesn't come into play unless a connection is successfully established between a sender and receiver.", which isn't really how I would have interpreted the doc on this, but it does support my findings.

So how do I cut down on the timeout time, if a deployment is targeting a server where the receiver is down?

ISCBorisB

I realise this is an old thread, but I'm having the same issue.

Sender OD is stuck forever (or too long IMHO), when connecting to a targer OD server. The target Unix server is up, but OD receiver itself isn't running on it (some port or permission issue is stopping it from launching)
ENG: 2009-03-23 15:37:29 MET GMT+01:00 Thread-2664 entering setup
LIB: 2009-03-23 15:37:29   LOGFILE=[/logfiles/od/src.my_deployment.config.scws0001.to.target02.log]
LIB: 2009-03-23 15:37:29   Locale=[English_UnitedStates.US-ASCII@Binary]
ENG: 2009-03-23 15:37:30 MET GMT+01:00 Thread-2664 Connecting to host=scwaa180 port=20014

ENG: 2009-03-23 15:37:30 MET GMT+01:00 Thread-2664 Sender Side timeout = 120

ENG: 2009-03-23 15:37:30 MET GMT+01:00 Thread-2664Sender Side timeout set for the entire deployment

ENG: 2009-03-23 15:37:30 MET GMT+01:00 Thread-2664 Buffer Size 8000
ENG: 2009-03-23 15:52:32 MET GMT+01:00 Thread-2664 ***ERROR - Job ID=m1314Deployment=bzws_deployment_configWA
 Base: Exceeded all 3 retries to get a connection with the target OpenDeploy host.
       Failed creating socket.
While this deployment is stuck, other deployments started are queued but not processed.

I added the localNode timeout="120" attribute, hoping to have that reduce the timeout time, but it's having no effect.

Well, Todd did say earlier in the thread: "The timeout doesn't come into play unless a connection is successfully established between a sender and receiver.", which isn't really how I would have interpreted the doc on this, but it does support my findings.

So how do I cut down on the timeout time, if a deployment is targeting a server where the receiver is down?

Have you tried to play with 'block' attributes of the localNode Tag?
blockCheckInterval (seconds, default 30)
blockMaxWaitTime (seconds, default 1800)
(OD Administration Guide, Chapter "Enabling Concurrency Management")

Note that 'timeout' terminates already established OD Session due to specified inactivity interval ( DNR Taking too long, etc...)

Frederik

Hi Boris,
thanks for your suggestion. The answer is no, I haven't played with those params. But based on reading the documentation, I don't see how they could possibly be related to my need. These params deal with concurrency management, which only comes into play if the Sender can open a socket to the Receiver. In my case, the connection is simply not created, because the Receiver isn't running OD. Yet it takes the sender a very long time to realise that.

ISCBorisB

Hi Boris,
thanks for your suggestion. The answer is no, I haven't played with those params. But based on reading the documentation, I don't see how they could possibly be related to my need. These params deal with concurrency management, which only comes into play if the Sender can open a socket to the Receiver. In my case, the connection is simply not created, because the Receiver isn't running OD. Yet it takes the sender a very long time to realise that.

Try it. I've used 'blockMaxWaitTime' before to quickly terminate deployments to *dead* receivers.

Note that I did not even have Receivers' pathRegistryChecking attribute set, so Concurrency Management
was not enabled. Note also that I do not know if this will work in the Reverse Deployment case

Frederik

Hi Boris, all

I finally tried this out, but with no luck. The delay is exactly the same for me, after adding

blockMaxWaitTime="60" blockCheckInterval="15"

to my deployment config.

ENG: 2009-04-01 11:40:16 MEST GMT+02:00 Thread-3928 Buffer Size 8000
ENG: 2009-04-01 12:06:30 MEST GMT+02:00 Thread-3928 ***ERROR - Job ID=m1944Deployment=bzws_deployment_globalBR
 Base: Exceeded all 3 retries to get a connection with the target OpenDeploy host.
       Failed creating socket.

I'm not sure why you're seeing different results...
BTW, I'm deploying from Solaris + OD 6.0.2 to AIX + OD 6.1.0

Deployment config below, just in case.

[HTML]

[/HTML]

ISCBorisB

I'm not sure why you're seeing different results...

Not sure either. If memory serves, we had "on Target" DNRs in my case, may be that's what really caused "fast" timeout.

Btw, you can use iwodcmd command to interrogate your receivers upfront. Perhaps that may help?
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