AnsweredAssumed Answered

Anyone run into issues patching from P06 to P08 on version of RSA IGL 7.1.0?

Question asked by Richard Jung on Sep 15, 2019
Latest reply on Nov 27, 2019 by Ian Staines

Like • Show 0 Likes0
Comment • 6

I get this error below. I tried extending it from 15 mins to 30 mins, but still no luck/

I tried extending it from 900 (15min) to 1800 (30

File: /home/oracle/Aveksa_7.1.0_P08/deploy/wildfly-conf/groovy/com/aveksa/wildfly/CustomizeACM.groovy

Original:

def addCmd = "${AVEKSA_HOME}/wildfly/bin/jboss-cli.sh -c --command=/system-property=jboss.as.management.blocking.timeout:add(value=900)"

Changed To:

def addCmd = "${AVEKSA_HOME}/wildfly/bin/jboss-cli.sh -c --command=/system-property=jboss.as.management.blocking.timeout:add(value=1800)"

=================================================================================

Patch Log (Error):

Creating aveksa.ear file for deployment
[zip] Building zip: /tmp/customizeACM/aveksa.war
[zip] Building zip: /tmp/customizeACM/aveksa.ear
[copy] Copying 1 file to /home/oracle/archive

Undeploying current ear...
Undeploy failed: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"aveksa.ear\")]' not found"}}

Deploying new customized ear... this may take a while...
Exception encountered while deploying Aveksa.ear
WFLYCTL0344: Operation timed out awaiting service container stability

Aveksa.ear deployment failed after 15 minutes, 22.993 seconds

Updating CURRENTLY_DEPLOYED_ARCHIVE to aveksa_7.1.0_143825_P08-2019-Sep-13-10.14.ear

aveksa_7.1.0_143825_P08-2019-Sep-13-10.14.ear archived

An error occured in the customizeACM command : error code 5

Error deploying the ear file
Step failed! See /home/oracle/Aveksa_7.1.0_P08/logs/7.1.0_P08_2019-09-13-1010.log for more information.

Ian Staines

Nov 27, 2019 7:10 PM

Correct Answer

Since I posted this information our official guidance on this problem has been improved and is tracked in the following KB article.

000038024 - WFLYCTL0344 Operation timed out awaiting service container stability error when patching RSA Identity Governance & Lifecycle

Although my work around suggested above may also work it is not usually necessary. The KB article provides a solution that is more generic and produces a repeatable result.

See the reply in context

Attachments

7.1.0_P08_2019-09-13-1010.log.zip2.7 KB

No one else had this question

Outcomes

Ian Staines

Sep 16, 2019 10:58 AM

There was an issue in early 7.1.0 builds where the WildFly timeout value was set to 300 seconds (5 minutes) which was not long enough for some customer deployments. Although the deployment should finish in a couple of minutes, some systems were taking slightly over 5 minutes. All current builds of the product have the timeout set to 900 seconds (15 minutes) which is much longer than is required for any deployment type.

If the Wildfly deployment does not finish in 15 minutes, then it will not finish in any length of time. Increasing the timeout value longer will not resolve the issue.

There is some incompatibility in the customers EAR file that is preventing successful deployment. You can attempt to troubleshoot the reason but there is no logging for this aspect of the WildFly operation. If you do identify the issue, likely the problem will require you to discard the EAR file as it is likely unrecoverable.

The fastest solution in these situations is just to restore the ear file from a known good version. Customer customization (JDBC drivers and jsp's) will have to be applied again.

There are several techniques to deploy a new EAR. I recommend deploying the 7.1.0 GA EAR file and then patching again.

Actions

Richard Jung @ Ian Staines on Sep 16, 2019 12:15 PM

Thank you Ian for your great feedback. Let me know if this makes sense in re-deploying...

Go to /home/oracle/deploy:

1. ./customizeACM.sh -c aveksa_7.1.0_143825_P06-2019-May-17-14.43.ear (Last successful EAR file on P06)

2. ./customizeACM.sh -d (Re-deploy EAR file from above)

3. ./patch.sh from /home/oracle/Aveksa_7.1.0_P08

1 person found this helpful

Actions

Ian Staines

@ Richard Jung on Sep 16, 2019 12:29 PM

Yes, that should work.

Note: To rule out other issues with starting and stopping WildFly it is often good to do a full stop and then start of acm outside of the patching or customizeACM process. Validate by examining the logs that acm is able to stop and start in a timely manner. If something is preventing acm from operating normally then it will also affect the patching.

Actions

Richard Jung @ Ian Staines on Sep 17, 2019 8:11 PM

Thank you Ian. Confirmed; your solution worked!

Actions

Shlomo Katz @ Richard Jung on Nov 27, 2019 6:55 PM

Thank you for this.

Just had to do this for 7.1.1. Patch 3.

Actions

Ian Staines

Nov 27, 2019 7:10 PM

Since I posted this information our official guidance on this problem has been improved and is tracked in the following KB article.

000038024 - WFLYCTL0344 Operation timed out awaiting service container stability error when patching RSA Identity Governance & Lifecycle

Although my work around suggested above may also work it is not usually necessary. The KB article provides a solution that is more generic and produces a repeatable result.

Actions

6 Replies

Ian Staines Sep 16, 2019 10:58 AM
Mark Correct
Correct Answer
There was an issue in early 7.1.0 builds where the WildFly timeout value was set to 300 seconds (5 minutes) which was not long enough for some customer deployments. Although the deployment should finish in a couple of minutes, some systems were taking slightly over 5 minutes. All current builds of the product have the timeout set to 900 seconds (15 minutes) which is much longer than is required for any deployment type.

If the Wildfly deployment does not finish in 15 minutes, then it will not finish in any length of time. Increasing the timeout value longer will not resolve the issue.

There is some incompatibility in the customers EAR file that is preventing successful deployment. You can attempt to troubleshoot the reason but there is no logging for this aspect of the WildFly operation. If you do identify the issue, likely the problem will require you to discard the EAR file as it is likely unrecoverable.

The fastest solution in these situations is just to restore the ear file from a known good version. Customer customization (JDBC drivers and jsp's) will have to be applied again.

There are several techniques to deploy a new EAR. I recommend deploying the 7.1.0 GA EAR file and then patching again.
Like • Show 0 Likes0
Actions
- Richard Jung @ Ian Staines on Sep 16, 2019 12:15 PM
  Mark Correct
  Correct Answer
  Thank you Ian for your great feedback. Let me know if this makes sense in re-deploying...
  
  Go to /home/oracle/deploy:
  1. ./customizeACM.sh -c aveksa_7.1.0_143825_P06-2019-May-17-14.43.ear (Last successful EAR file on P06)
  2. ./customizeACM.sh -d (Re-deploy EAR file from above)
  3. ./patch.sh from /home/oracle/Aveksa_7.1.0_P08
  1 person found this helpful
  Like • Show 2 Likes2
  Actions
  - Ian Staines @ Richard Jung on Sep 16, 2019 12:29 PM
    Mark Correct
    Correct Answer
    Yes, that should work.
    
    Note: To rule out other issues with starting and stopping WildFly it is often good to do a full stop and then start of acm outside of the patching or customizeACM process. Validate by examining the logs that acm is able to stop and start in a timely manner. If something is preventing acm from operating normally then it will also affect the patching.
    Like • Show 2 Likes2
    Actions
    - Richard Jung @ Ian Staines on Sep 17, 2019 8:11 PM
      Mark Correct
      Correct Answer
      Thank you Ian. Confirmed; your solution worked!
      Like • Show 0 Likes0
      Actions
  - Shlomo Katz @ Richard Jung on Nov 27, 2019 6:55 PM
    Mark Correct
    Correct Answer
    Thank you for this.
    Just had to do this for 7.1.1. Patch 3.
    Like • Show 1 Like1
    Actions
Ian Staines Nov 27, 2019 7:10 PM
Unmark Correct
Correct Answer
Since I posted this information our official guidance on this problem has been improved and is tracked in the following KB article.

000038024 - WFLYCTL0344 Operation timed out awaiting service container stability error when patching RSA Identity Governance & Lifecycle

Although my work around suggested above may also work it is not usually necessary. The KB article provides a solution that is more generic and produces a repeatable result.
Like • Show 1 Like1
Actions

Anyone run into issues patching from P06 to P08 on version of RSA IGL 7.1.0?

Attachments

Outcomes

Related Content

Recommended Content