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

reverse deploying an open file

swong74

We have a reverse deployment to pick up log files from our production system. We've set it up as a dirdiff rev deployment but we've noted that it attempts to roll back when it hits errors with open files and is stuck. I'm working with the app guys to generate a list of "closed" files and make a filelist which we'll get but my question is ... why is OpenDeploy behaving like this with an open file ... it is hanging (not terminating/timing out) ... it's been running for an hour now "rolling back."

tnx.
-sw

Ciao ?:-)
S. Wong

Find more posts tagged with

Comments

Adam Stoller

I think the problem is that OpenDeploy first gets a value for the size of the file before deploying it, and then when it goes to deploy the file it checks the size again - and if the size differs - it tends to hang (this same kind of problem occurs when trying to deploy files from workareas rather than staging areas in TeamSite)

I don't recall if there is an actual bug filed on this (and if so, whether there is a fix existing or pending) - but I think that's where the problem comes. Usually you can verify this because one of the log files will say something like "found N bytes, expected M" or something like that. Check your log files for the deployments (source and receiver side) and see if you can find an error message like that.

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

swong74

I don't think I saw something like that. I am kinda hoping that since it's in the roll-back phase, OD figured that it couldn't proceed any further and trying to bail. I'm just curious why it would even try to roll back given that it is non-transactional albeit reverse deploy.

- sw

Ciao ?:-)
S. Wong

Adam Stoller

Not sure if this applies, but I believe OD tends to go through all phases of deployment, including rollback, even if that phase is a No-Op - so you might see something about it entering Rollback on a non-transactional deployment when Rollback is a NoOp and you need to look further down to see where it really had problems.

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

swong74

to be honest, the last state is the rollback ... nothing else is written out for hours. the only way we bailed it was to stop the receiver and break the connection (base then figures it lost handshake with receiver and wraps up).

I skimmed the log and see a lot of "Could not read attr size from socket" and "Failed attribute transfer for:"

We are working to try to rotate the logs and stash it outside the working area to avoid this ... i.e., OD having an open file during transfer.

I just thought there might be some OD solution to it. ;-)

Ciao ?:-)
S. Wong

Adam Stoller

Another thing to check for (and perhaps you already have based on your follow-up with the logs) is to make sure that there is sufficient disk space on the receiver. We have found that, at times, insufficient space on the receiver would cause a deployment to hang with no clear indication of that being the cause.

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

swong74

I haven't checked the receiver's disk resource. However, if it was, I think someone would've been alerted since I think the threshold for our production systems are 85% capacity. Lemme check ...

- sw

Ciao ?:-)
S. Wong