Common Issues & Workarounds

This help page contains a list of common installation / update problems as well as troubleshooting steps and work arounds. 

Patch Install Failures

Patch Fails with message: Use the above command to remove the dbex.lck files

This failure is a preventative failure to keep the patch from being installed if the DTS Service is running on Linux installations.  The DTS can sometimes leave lock files so the error can occur even if the DTS has been shut down.  To work around, verify that the DTS and Staging DTS services are shutdown by running the <InstallDir>/TomcatShutdown.sh and <InstallDir>/Staging/TomcatShutdown.sh command, then copy,paste, and run the delete / find command in the error message to the console.  After the command is run you can run the patch install.sh again.  This failure may happen twice in installations with both production and staging DTS instances installed in the Installation tree. 

Patch fails to install with a database connection / database permission error

This error usually occurs on installations that have been migrated between servers or between databases.  It can also happen if the database username or password has changed since the product was originally installed.  To resolve follow the steps to verify / updated the <InstallDir>/rxconfig/Installer/rxrepository.properties file in Appendix A of the Migrating Percussion Environments page to correct the file.  Once that is complete, uninstall the failed patch by running ./uninstall.sh or uninstall.bat, and then run the patch install again. 

Patch fails to install with a mysql repository database error on foreign key / index

This error can be caused by an incorrect database collation on the mysql server.  To correct this, make sure that the database collation is correct on the database.  Run the following SQL:

ALTER DATABASE yourdb CHARACTER SET utf8 COLLATE utf8_general_ci;

Once completed, uninstall and then install the patch again. 

Post Installation Issues

DTS Fails to start with com.percussion.tomcat.valves.PSSimpleRedirectorValve.invoke(PSSimpleRedirectorValve.java:104) ~[perc-tomcat-common-1.0.0-SNAPSHOT.jar:?] Errors in Logs

This error can be caused by a missing or broken database driver when the DTS service is started.  If the DTS is configured for MySQL and you are using a symbolic link for the MySQL Java Connector.  Verify that the link is still good by checking the mysql-connector.jar file in the Deployment/Server/lib/mysql-connector.jar location. 

FTP Publishing Fails With Error

"An unexpected problem occurred: Problem connecting to ftp server: connect: timeout can't be negative".  This error can be caused by a missing timeout setting, corrected in a later patch, on the FTP publisher configuration.  You can work around this problem by editing the AppServer/server/rx/deploy/rxapp.ear/rxapp.war/WEB-INF/user/config/spring/publisher-beans.xml file and add a timeout property to the sys_ftp and sys_ftp_only bean configurations.

 <bean id="sys_ftp"
class="com.percussion.rx.delivery.impl.PSFtpDeliveryHandler">
<!-- Properties that can be set here:
timeout
(defaults to -1 as not defined.
It is the socket timeout in milliseconds for both when opening a
socket and a currently open connection).
usePassiveMode
(defaults to false.
Determines if using passive or active mode for the FTP client.
Defaults to use active mode. If using passive mode is on, then it
will also disable the remote verification
-->
<property name="usePassiveMode" value="true" />
<property name="timeout" value="10000" />
</bean>

<bean id="sys_ftp_default"
class="com.percussion.rx.delivery.impl.PSFtpDeliveryHandler">
<!-- Properties that can be set here:
timeout
(defaults to -1 as not defined.
It is the socket timeout in milliseconds for both when opening a
socket and a currently open connection).
usePassiveMode
(defaults to false.
Determines if using passive or active mode for the FTP client.
Defaults to use active mode. If using passive mode is on, then it
will also disable the remote verification
-->
<property name="usePassiveMode" value="true" />
<property name="timeout" value="10000" />
</bean>

Saving this file and restarting the instance will correct this error.

Full Publishing Fails with error: Prepared or callable statement has more than 2000 parameter markers

This can be caused by a known issue / limitation of the Ignore Unmodified Assets feature of the publisher. To work around, uncheck the "Ignore Unmodified Assets" option and save the Publishing Server configuration.  After de-selecting this option, Full Publish will work correctly.

 Saving this file and restarting the instance will correct this error.

Full Publishing Completes with errors: "java.lang.RuntimeException: Error when executing method: HTTP/1.1 400 "

This message can occur for different reasons, but it can also be caused by a configuration issue due to defining the DTS port of 8443 (default port), and connecting via HTTP instead of HTTPS (secure port).  The problem is in the <admin-connection-url>http://instanceURL-dts:8443</admin-connection-url>  defined in the rxconfig/DeliveryServers/delivery-servers.xml file.  If this is set to HTTP, change it to the secure HTTPS port 8443.  Stop the CM1 service.  Update the configuration file to use HTTPS instead, then restart. Publishing should run through.

Additional caching instruments can cause "Out of Memory" errors 

The default, out of the box, configuration is only allocated a maximum of 2GB of RAM for the CMS, so if that was never configured to utilize available system memory you could run into memory threshold issues with the recent patch (cm1 5.3 SR1 5315_20190901 Patch) based on number of sites, pages, or navigation elements.

We have updated additional cache utilization in the patch and hence you might need to adjust the current memory settings.  You may see an “Out of Memory” exception in the server.log file that may look like this: 

“Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
2019-09-20 03:38:25,544 ERROR [org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver] Error occurred during error handling, give up!
org.apache.cxf.interceptor.Fault: GC overhead limit exceeded”

Open the PercussionServer.lax(PercussionServer.bin.lax for Linux) file to verify the current memory allocation.

Based upon available memory you can update the lax.nl.java.option.additional section of the PercussionServer.lax or PercussionServer.bin.lax (Linux) file with below values (see bolded value) or your environments available memory.  For larger environments, we recommend changing this value even higher if there is allocated memory available.

lax.nl.java.option.additional=-Dprogram.name=RhythmyxServer.exe -Xms256m -Xmx4096m -Djava.endorsed.dirs="AppServer/lib/endorsed" -Djava.library.path=./bin -server -XX:MaxPermSize=512m -Dfile.encoding=UTF8 -Dsun.jnu.encoding=UTF8 -Djboss.server.log.dir=logs/AppServer -Djava.rmi.server.hostname=127.0.0.1  -Dhttps.protocols=TLSv1.1,TLSv1.2 -Djava.net.preferIPv4Stack=true

You will need to restart the service for this setting change to take effect.

NOTE:

As a System Administrator it is a common practice to backup a configuration file when making changes to it.  Normally this is a good practice.  When working with files in the WEB-INF/config/folder structure like the config/user/beans/publisher-beans.xml file, it is important to make sure that you do not save a backup of the file in this folder tree.  We recommend either using XML comments <!-- commented stuff --> in the files, or to save the backup to a different location.  The product processes all files that exist in this special config folder tree as active configuration files to support 3rd party or customer created Java extensions.  If a backup file is located in these directories, it will be processed as a valid and active configuration, and may overwrite your intended production config.  To avoid troubleshooting headaches, either use XML comments, or backup to a different location.