000037136 - Error using customizeACM Command in RSA Identity Governance & Lifecycle 7.1.0

Document created by RSA Customer Support Employee on Mar 7, 2019
Version 1Show Document
  • View in full screen mode

Article Content

Article Number000037136
Applies ToRSA Product Set:  Identity Governance & Lifecycle
RSA Version/Condition: 7.1.0+
Application Server: WildFly 10

IssueRunning the CustomizeACM script ./customizeACM.sh -d fails with the following error:
Exception encountered while deploying Aveksa.ear WFLYCTL0343: The service container has been destabilized by a previous operation and further run-time updates cannot be processed. Restart is required. Aveksa.ear deployment failed after 15 minutes, 11.880 seconds Updating CURRENTLY_DEPLOYED_ARCHIVE to aveksa_7.1.0_143825_P04-2019-Jan-23-9.12.ear aveksa_7.1.0_143825_P04-2019-Jan-23-9.12.ear archived
An error occurred in the customizeACM command : error code 5
CauseBy default, prior to RSA Identity Governance & Lifecycle 7.1 P01, WildFly had a timeout of 300 seconds (5 minutes) for application deployment. WildFly 10 is known to take longer to deploy the .ear files compared to earlier versions of WildFly. Hence, starting in RSA Identity Governance & Lifecycle 7.1.0 P01, we have increased the timeout value to 900 seconds

Although the default timeout value has been increased to 900 seconds (15 minutes), this may not be enough for some enterprise applications, or if your application executes some lengthy operations during deployment. In this case, you may need to fine-tune the application deployment timeout setting for your environment. If you observe the above error, you should increase the timeout value for jboss.as.management.blocking.timeout, as described in the Workaround section below.

ResolutionThere is no resolution at this point of time.  Please refer to the workaround section below. 
WorkaroundThere is a system property named jboss.as.management.blocking.timeout that can be increased in order to resolve this error.  This property is not a timeout per deployment, but a timeout on container stability and if jboss.as.management.blocking.timeout is reached during startup, then all applications will be un-deployed and the container is shutdown. The reasoning behind this is that having a half-working server is potentially dangerous as you may not notice major failures.

To increase this timeout in a standalone installation setup, please run following steps:

For cluster setup, please refer to Notes section below.

  1. Stop AFX:

afx stop

  1. Using  text editor such as vi, open file /home/oracle/wildfly/standalone/configuration/aveksa-standalone-full.xml.
  2. Go to the <system-properties> section and change the value of timeout property jboss.as.management.blocking.timeout from 900 to a higher value (like 1200), as shown:

<property name="rsavialg.security.keydir" value="/home/oracle/security"/> 
<property name="jboss.as.management.blocking.timeout" value="1200"/> 

  1. Restart ACM

acm restart

  1. Execute the customizeACM script:

/home/oracle/deploy/customizeACM.sh -d

  1. Start AFX once the .ear is deployed successfully

afx start    

Increasing the timeout value for cluster environment

  1. Update the domain.xml file located at /home/oracle/wildfly/domain/configuration, as described on page 19 of the RSA Identity Governance and Lifecycle 7.1: Configuring Wildfly Clustering Guide.

Update Management Timeout

The jboss.as.management.blocking.timeout value defaults to 300 seconds. This property is a timeout on container stability. If jboss.as.management.blocking.timeout is reached during startup, all applications are undeployed and the container is shut down.

The following example shows the commands to set a custom value, such as 900 seconds:
<property name="jboss.as.management.blocking.timeout"

Restart the cluster with following commands:

SUSE 11 commands

service aveksa_cluster stop
service aveksa_cluster start

SUSE 12 commands

systemctl stop aveksa_cluster
systemctl start aveksa_cluster