Hung Deployment

I am running a file list deployment out of one of my workareas that seems to have simply hung with the following error (if you could call it an error - it is moreso simply a number...)

LIB: 2007-08-21 18:59:39 Local_directories to deploy: 1
LIB: 2007-08-21 18:59:39 BEGINNING Transactional Deployment
ENG: 2007-08-21 18:59:39 EDT GMT-04:00 Thread-73780 After SETUP, res=0
ENG: 2007-08-21 18:59:39 EDT GMT-04:00 Thread-73780 exiting setup
ENG: 2007-08-21 18:59:39 EDT GMT-04:00 Thread-73780 entering awaiting-dotask
ENG: 2007-08-21 18:59:39 EDT GMT-04:00 Thread-73780 still waiting for 0
ENG: 2007-08-21 18:59:39 EDT GMT-04:00 Thread-73780 exiting awaiting-dotask
ENG: 2007-08-21 18:59:39 EDT GMT-04:00 Thread-73780 entering dotask
ENG: 2007-08-21 18:59:39 EDT GMT-04:00 Thread-73780 COMPARE
LIB: 2007-08-21 18:59:39 Options: do_deletes deploy user=teamsite group=TS_dom file_perm=755 dir_perm=755 ignore_acls do_manifest_for_dnr verbose_level=5
ENG: 2007-08-21 18:59:39 EDT GMT-04:00 Thread-73780 After COMPARE, res=0
ENG: 2007-08-21 18:59:39 EDT GMT-04:00 Thread-73780 PRECOMMIT
LIB: 2007-08-21 18:59:39 DEPLOYING - [/iwmnt/default/main/internet/dom/internet_comm/STAGING] to [/export/web/app/qa/dom]
LIB: 2007-08-21 18:59:39 Filelist=[/app/interwoven/OpenDeployNG/conf/file_lists/dom_internet_comm/5522273.qa.txt]
LIB: 2007-08-21 18:59:39 Sending [./templates/layout_19.template.html] [reason file_list]
LIB: 2007-08-21 18:59:39 00032

Does anyone know what this means? The admin console simply has 'setup done transferring'. It's been in this state for several hours.

We are deploying one file. It exists in the source area and an older version exists in the target area. Subsequent deployments (by a frustrated user) worked fine (of the same file.)

I can stop and start OD, which will more then likely clear this out, but I am wondering if there is a deeper seated problem here.

Find more posts tagged with

Comments

nipper

You need to get the log from the receiver.

However often when I see a deployment that is hung, it is caused by the log files on the receiver filling up a disk. Check that 1st.

Recovery requires restarting the receiver and sender processes

jajtiii

Thanks.

I did find the following in the receiver log :

LIB: 2007-08-21 18:59:39 ERROR: Failed transferring contents of (./templates/layout_19.template.html)
LIB 00017: 2007-08-21 18:59:39 ERROR: Could not get file data(templates/layout_19.template.html).
LIB: 2007-08-21 18:59:39 ERROR: deploy-failed.
LIB: 2007-08-21 18:59:39 ERROR: Failed deploying filelist[0]
LIB: 2007-08-21 18:59:39 ERROR: Failed 1 of 1 filelists

The file does exist and it is not corrupt, but there is no way of telling if there that WAS the case when OD kicked out this error (the end user kicked off the same Workflow again and it did successfully run, which may have pushed out an uncorrupted version of the file.)

At any rate, thanks for your time. I will have to file this away for the time being.

jt

Adam Stoller

Thanks.

I did find the following in the receiver log :

LIB: 2007-08-21 18:59:39 ERROR: Failed transferring contents of (./templates/layout_19.template.html)
LIB 00017: 2007-08-21 18:59:39 ERROR: Could not get file data(templates/layout_19.template.html).
LIB: 2007-08-21 18:59:39 ERROR: deploy-failed.
LIB: 2007-08-21 18:59:39 ERROR: Failed deploying filelist[0]
LIB: 2007-08-21 18:59:39 ERROR: Failed 1 of 1 filelists

The file does exist and it is not corrupt, but there is no way of telling if there that WAS the case when OD kicked out this error (the end user kicked off the same Workflow again and it did successfully run, which may have pushed out an uncorrupted version of the file.)

At any rate, thanks for your time. I will have to file this away for the time being.

jt

From the original log:

...
LIB: 2007-08-21 18:59:39 DEPLOYING - [/iwmnt/default/main/internet/dom/internet_comm/STAGING] to [/export/web/app/qa/dom]
...

Try changing the source area path to use the non-cached mount point /[color=red].iwmnt/default/main/internet/dom/internet_comm/STAGING

[/color] - you are likely running into a timing issue between when the file was submitted and when it actually gets propagated to the cached mount point.

jajtiii

Many thanks for the tip.

I have subsequently done a fair amount of searching for a clear explanation of the difference between /iwmnt and /.iwmnt, to no avail (outside of a diagram in the Unix Admin guide.)

Don't want to waste anyone's time, but could someone direct me to documentation on this file system (and risks of using it vs. /iwmnt, if any)?

nipper

It is not documented anywhere very much.

/iwmnt is a cached mount point
/.iwmnt is a non-cached point.

/iwmnt will be faster to access, but *may* be out of date.

If the deployment is done in a WF after a submit your choices are:

/.iwmnt/.../STAGING
or /iwmnt/.../WORKAREA

If you use /iwmnt/.../STAGING what can happen is you get partial deployments. I saw files where the previous version was 1000 bytes, the new version was 1200 bytes. OD would grab the cached size (1000 bytes), by the time OD started, the cache was good, so it would only take the 1st 1000 byes of the new version.

Trust me that was a serious pain.

Andy

Adam Stoller

It is not documented anywhere very much.

/iwmnt is a cached mount point
/.iwmnt is a non-cached point.

/iwmnt will be faster to access, but *may* be out of date.

If the deployment is done in a WF after a submit your choices are:

/.iwmnt/.../STAGING
or /iwmnt/.../WORKAREA

If you use /iwmnt/.../STAGING what can happen is you get partial deployments. I saw files where the previous version was 1000 bytes, the new version was 1200 bytes. OD would grab the cached size (1000 bytes), by the time OD started, the cache was good, so it would only take the 1st 1000 byes of the new version.

Trust me that was a serious pain.

Andy

The timing issue is the same with the workarea - and frankly IMO - you should only deploy from the workarea if you are deploying to a staging / preview server prior to "approval" of the changes - once the file(s) have been approved, the work should be submitted and the files deployed from either staging or an edition (after an iwpublish).

/.iwmnt/.../STAGING/...

is the best choice for deploying approved files on Unix. (There's only Y:/ on Windows)

jajtiii

The error number (32) that was kicking out in the OD log was actually something that OD was picking up from the Solaris box.

It turns out that the file system had been mounted (to the NAS, in this case) in a Read Only configuration. Even the root user could not write to that file system.

Fixed this by changing the mount configuration and all is good.