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 running Forever

MichaelS

Hi,

I started a deployment and it entered into "commit" phase. Now it is running for 26 hours already and I have no way of stopping it. No "Remove" or "Cancel" because it is in "commit" state. Does anybody know how can I get rid of it?

Find more posts tagged with

Comments

jbonifaci

You could try iwoddeploycancel or stop and start the service, =].

Bubas_IWOV

Hi,

Start and stop the server is the solution i have been applying that type of problems. All the rest doesnt seem to work very well.

Bruno

mstevens

If you are on a Unix box, you can kill the java process associated with your deployment, with out taking down the OD service.

Migrateduser

Actually, the deployment is a thread within the OD process.

This type of hang situation usually occurs when a second deployment writes to the same target area, resulting in file collisions. It can also happen if a transient file gets locked during the deployment, which has been known to happen on Windows systems running the indexing service, for example.

Unfortunately, the existing deployment cancel feature is limited to certain windows of opportunity during the deployment. There is a feature request to provide finer grained termination (#36873).

There are also a couple of feature requests on file which would help prevent the hang situations in the first place. One is for providing automatic receiver-side queuing, which would detect and prevent target area collisions (#21765). The other feature is to allow transient files to be written to a location outside of the target area, thereby shielding them from being accidentally locked during a deployment transaction (#27839).

Please contact me if you would like your company attached to any of these feature requests.

Thanks,
Todd

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Migrateduser

I've been having that trouble too with this reverse deployment. I finally got it to run (this is all still in simulation) but it says that I don't have a directory specified for deployment (which I do - a workarea to receive all the intitial files), and that I have an invalid configuration file (which I'm working on now). This is all from the micro audit log, and it hangs there. I waited 30 minutes before stopping and starting the service, and that seems to be the only thing to really stop it.

What goes up must come down. Ask any system administrator.

Adam Stoller

This type of hang situation usually occurs when a second deployment writes to the same target area, resulting in file collisions. It can also happen if a transient file gets locked during the deployment, which has been known to happen on Windows systems running the indexing service, for example.

We've been seeing this hanging recently a lot - with 5.6 SP1 on Solaris 8 - in which we were deploying from /default/main/.../STAGING/ after an iwsubmit returned control back to the script (that then subsequently launches the deployment). We know about the idea of using the non-caching mount point (/.iwmnt/default/...) however, for reasons not worth going into right now, that's not a viable solution at present.

Basically - the problem seems to be that OpenDeploy performs a stat on the file early during the process of setting up the deployment, and then gets horribly confused when, as it goes to actually deploy the file, the size of the file to be deployed differs from what was originally seen.

While I consider part of this to be a failure of iwsubmit (not having an option to make it wait until the action has been flushed to the cache) - I think part of this is also a problem in OpenDeploy. It traps the error situation (as seen in the logfile) but then seems to have no idea how to gracefully abort the deployment.

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

Migrateduser

This is a known issue. OpenDeploy deploys from STAGING as if it were a regular directory path. Since STAGING is a moving source area, OpenDeploy gets confused if files change beneath it during a deployment.

There is a feature request for handling this situation automatically (FR #37162). Anyone wishing to be attached to this FR should contact Tech Support or mail me with your company name.

Cheers,

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Adam Stoller

Thanks,

I've opened a case to track the feature request for my customer.

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