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

OD receiver bounces

kaalraa

Hi all,

My OD receiver is bouncing due to 2 or more concurrent OD commands being run at the same time. Could anyone provide any suggestions or pointers as how to tackle the situation... as it is very difficult to get hold of Server admin again and again and thats too.... in off late hours.

We are calling the odcmd start command from our external task script and is in our hands to change the same. Is there any method or CLT which can check if the OD is free to deploy or busy in handling any deployment at that moment of time.

Please take this as an urgent call.

Find more posts tagged with

Comments

Adam Stoller

Hi all,

My OD receiver is bouncing due to 2 or more concurrent OD commands being run at the same time. Could anyone provide any suggestions or pointers as how to tackle the situation... as it is very difficult to get hold of Server admin again and again and thats too.... in off late hours.

We are calling the odcmd start command from our external task script and is in our hands to change the same. Is there any method or CLT which can check if the OD is free to deploy or busy in handling any deployment at that moment of time.

Please take this as an urgent call.

Please define "bouncing" - If the OD Receiver is dying - that's a problem for you to take up with IWOV Support.
If the request to perform a deployment is being denied because a request with the same instance name is already running - that's a case of either enabling the pending queue or (generally better) adding unique instance tags to your deployment command lines.
Also - please be clear about the type of deployment - handling transactional deployments is different than handling non-transactional deployments. Handling diff-based deployments is different than handling file list deployments, and so-on.
Lastly - please provide information about platforms and versions.

kaalraa

Please define "bouncing" - If the OD Receiver is dying - that's a problem for you to take up with IWOV Support.

Bouncing means the OD receiver needs to be restarted, as from that point onwards it is not going to deploy any further job. We can call it as a dead receiver.

If the request to perform a deployment is being denied because a request with the same instance name is already running - that's a case of either enabling the pending queue or (generally better) adding unique instance tags to your deployment command lines.

The same instance name is not possible as we are using job id with a random number suffixed to it.

Also - please be clear about the type of deployment - handling transactional deployments is different than handling non-transactional deployments. Handling diff-based deployments is different than handling file list deployments, and so-on.

It is just usual transactional deployments with some XML files being deployed.

Lastly - please provide information about platforms and versions.

We are working on TS 6.1 SP2 and OD 6.1.0

EmptyImage.jpg

nipper

Definitely this is a support issue.

Are there any logs you can post ?

BTW, the only times I see this is when there is an issue with the receiver logs. Often when the disk allocated to the log dir is full (it is normally a unix mount, sometimes the mount goes away and it quickly fills the local disk mount point).

If you are seeing either of these errors:

Reason from server: DEPLOY_CONFIG_FILE
Details : Got Exception: LOGUTIL_RENAME_ERROR.

it is fixed in 6.0.2 SP1, but IIRC, those were usually server errors and not receiver.

kaalraa

This is the snippet of the OD logs

ENG: 2007-04-04 06:02:40 CDT GMT-05:00 Thread-9302 Buffer Size 8000
ENG: 2007-04-04 06:02:44 CDT GMT-05:00 Thread-9302 ***ERROR - Job ID=m1174Deployment=deploy760722_1
Base: Exceeded all 3 retries to get a connection with the target OpenDeploy host.
Failed creating socket.

Adam Stoller

This is the snippet of the OD logs

That looks like it could be a network connectivity issue - though if restarting the receiver fixes the problem it would seem more likely to be a problem on the receiver server itself rather than the network.

Are there any errors in the receiver's log files?

CRB

This is the snippet of the OD logs

we only get that error when the sender can't connect to the reciever because of network issues or server is down...
it seems that your receiver quits listening on port 20014 after each deployment?

when you said "the OD receiver needs to be restarted" do you mean restart the OD services or the box?

if it is restarting the whole box that might be network/server issue and not Opendeploy issue... if it is just restarting OD services then it is Opendeploy and it might be better to contact the support.

kaalraa

we only get that error when the sender can't connect to the reciever because of network issues or server is down...
it seems that your receiver quits listening on port 20014 after each deployment?

I know... as it only happens when 2 concurrent jobs requested to deploy some files to the same folder at the same time. By the time first one gets deployed all 3 retries gets exceeded fo the 2nd job in queue. I cant say it as server is down... bcoz of the fact the first job deploy the files successfully.

when you said "the OD receiver needs to be restarted" do you mean restart the OD services or the box?
if it is restarting the whole box that might be network/server issue and not Opendeploy issue... if it is just restarting OD services then it is Opendeploy and it might be better to contact the support.

It is only the services, which needs to be restarted, not the complete set box.

I think... it should be stated to IWOV support.

Adam Stoller

I know... as it only happens when 2 concurrent jobs requested to deploy some files to the same folder at the same time. By the time first one gets deployed all 3 retries gets exceeded fo the 2nd job in queue. I cant say it as server is down... bcoz of the fact the first job deploy the files successfully.
It is only the services, which needs to be restarted, not the complete set box.

I think... it should be stated to IWOV support.

Doesn't OD6.1 have receiver-side queueing?
Have you tried that out?

kaalraa

Doesn't OD6.1 have receiver-side queueing?
Have you tried that out?

Hi Adam,

At present we are not doing of that sort, however i have not even known to that fact if it present in OD 6.1 or not.

Will check to that... and revert if need any help from you. Smiley Happy

John742

Is the Od receiver running on a Unix host? If so please check to see if the OD java process is coring. od.log should provide information on this. Also the core dump itself will be located in the root dir \ . Deploying to the same location at the same time is known to core the OD java process. Adding receiver side queueing is best if available in your OD version (registry path checking = YES) as nipper suggested. If not the best solution to this is to build logic into your workflow external task to queue deployments. Open Deploy's base side queuing OOTB leaves a lot to be desired. This is not a simple task if done correctly. If only two deployments at a time have the potential to deploy to the same location you may want to rethink your deployment naming convention and turn queueing on for the base instance

MAK

Hi,

You can also check this :
1. If you have more than 1 network card on the receiver machine ?
2. Are you using the DNS name or IP for these deployments ?
3. If multiple cards try to deploy using IP and make sure you have the OD port open for that.

Any logs from receiver od.log might be helpful.