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

Deployments failing..

rashy

Hi,

When I try to deploy files from an OD base 5.6.0.0.0 to an OD receiver 6.2.0.0.0, it fails throwing this error.

But this deployment: from OD base 5.6.0.1.0 to the same OD receiver 6.2.0.0.0 works just fine.

So is it like 5.6.0.0.0 is not compatible with 6.2.0.0.0 while 5.6.0.1.0 is.

But I strongly believe that should not be the case, as receiver version downgrading happens just fine (from the logs)

Appreciate your help.

Thanks
Rasheed

Find more posts tagged with

Comments

rashy

I missed adding the log.

ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Sender-side handshake timeout = 120 secs
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Send version string to receiver, RC = 13
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Send attributes to receiver, RC = 1
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Read attributes from receiver.
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Receiver downgraded to the sender version as the sender is at a lower version
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Receiver Real version is 6.2.0.0.0
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Receiver downgraded to version5.6.0.0.0
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 sender-version=5.6.0.0.0 receiver-version=5.6.0.0.0
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Sender is version master
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Sender compatible with receiver: version same
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Sender profile
#session properties
#Wed Jan 27 04:45:10 EST 2010
TARGETAREA=/web/test.geconsumerproducts.com\:9260
ODADAPTERSET=
DEPLOYNAME=test
DEPUUID=test.m1.Wed_Jan_27_04\:45\:09_EST_2010
JOBID=m1
DEFNAME=toTESTRASHY
DEPLOYTYPE=103
DESCRIPTION=
DEPLOYSUFFIX=
OWNER=root
SYNCHRONIZEPHASE=false
SOURCEHOST=inftw480-08
TRANSACTIONAL=true
COMPRESSION=false
VERSION=5.6.0.0.0
LEGID=internet 07c
TARGHOST=xxxxx
SYNCH=true
VERIFYPHASE=true
REVERSE=false
LOGLEVEL=VERBOSE

LIB: LOGFILE=[/opt/OpenDeployNG/log/src.test.toTESTRASHY.inftw480-08.to.internet 07c.log]
LIB: Locale=[English_UnitedStates.US-ASCII@Binary]
client: Interwoven OpenDeploy(5.6.0.0.0 Build 15978 Interwoven 20030121)
client: LIB: Component Version (5.6.0.0.0 Build 17405 Interwoven 20030306)
client: Buffer Size (8000)
client: Protocol Version(5.0) OK
client: Connection Id(id=1)
client: Transaction Mode: ON
client: Mode(normal)
client: Protocol(normal)
client: Hostname(inftw480-08)
ERROR: Connection failed: Could not find matching OpenDeploy client for (inftw480-08).
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 After SETUP, res=-1
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 exiting setup
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 entering awaiting-cleanup
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 still waiting for 0
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 exiting awaiting-cleanup
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 entering cleanup
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 After CLEANUP, res=-1
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 exiting cleanup
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 entering task-failed
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 still waiting for 0
LIB: LOGFILE=[/opt/OpenDeployNG/log/src.test.toTESTRASHY.inftw480-08.to.internet 07c.log]
LIB: Locale=[English_UnitedStates.US-ASCII@Binary]
(2) RunScripts when=client_after_disconnect on state=failure

Adam Stoller

Hi,

When I try to deploy files from an OD base 5.6.0.0.0 to an OD receiver 6.2.0.0.0, it fails throwing this error.

But this deployment: from OD base 5.6.0.1.0 to the same OD receiver 6.2.0.0.0 works just fine.

So is it like 5.6.0.0.0 is not compatible with 6.2.0.0.0 while 5.6.0.1.0 is.

But I strongly believe that should not be the case, as receiver version downgrading happens just fine (from the logs)

It's nice that you "strongly believe" something - but you've already seemed to prove the issue empirically - and since 5.6 is [probably] no longer officially supported - you should be upgrading the software anyway.

rashy

Hi,

I understand its a very old version and we are actually on the process of migrating to the newer versions. But for the time being we need to keep this going.

So is this issue because of the incompatibilities. Then as I told earlier, why does it say:

ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Receiver downgraded to version5.6.0.0.0
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 sender-version=5.6.0.0.0 receiver-version=5.6.0.0.0
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Sender is version master
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Sender compatible with receiver: version same

Does the versions 5.6.0.0.0 & 5.6.0.1.0 behave so differently?
Or is there anything else I am missing here.

Adam Stoller

Hi,

I understand its a very old version and we are actually on the process of migrating to the newer versions. But for the time being we need to keep this going.

So is this issue because of the incompatibilities. Then as I told earlier, why does it say:

ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Receiver downgraded to version5.6.0.0.0
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 sender-version=5.6.0.0.0 receiver-version=5.6.0.0.0
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Sender is version master
ENG: 2010-01-27 04:45:10 EST GMT-05:00 Thread-7 Sender compatible with receiver: version same

Does the versions 5.6.0.0.0 & 5.6.0.1.0 behave so differently?
Or is there anything else I am missing here.

5.6.0.1.0 is a patched version of 5.6.0.0.0 - as I recall there was a patch specifically created for 5.6.0.0.0 to make it work with 6.x filelist deployments. I'm a little confused because I thought that patch was for a 5.6 receiver with a 6.x sender - but you seem to be going the other way (it still may apply).

In general - it has always been recommended to upgrade base servers before receivers as down-rev-deployments are easier to support than up-rev-deployments - so besides having very out-of-date software, you've managed to go about upgrading pieces of your environment in a manner opposite to recommendations.

The short answer though is - apply the patch to your 5.6.0.0.0 base server and you should be able to get it to work.

rashy

As you mentioned, that patch was actually for file list deployments from a 6.x sender to a 5.6 receiver. And I had done this sometime back.

Anyways thanks for the help. I could trace out the issue.
The receiver host could not identify the source server name. So got it added to /etc/hosts in the receiver.

Sometimes, we tend to miss things like these.

But I still have a question here-

Will deployments from a higher base happen properly to a lower receiver.

I had actually read sometime back that, receiver version should be either higher or similar to what base version we have.

Adam Stoller

...
But I still have a question here-

Will deployments from a higher base happen properly to a lower receiver.

I had actually read sometime back that, receiver version should be either higher or similar to what base version we have.

I believe it is the other way around - the base server should be either the same or newer than the receivers.