November 2008 Archives

While deploying LiveCycle and initializing its tables against the MySQL database, you might run into the following error during the deployment of the Document Service Components (DSCs):
com.mysql.jdbc.PacketTooBigException: Packet for query is too large (1499558 > 1048576). You can change this value on the server by setting the max_allowed_packet' variable.

Please see here for a discussion about this at the MySQL website. According to MySQL, 'max_allowed_packet' controls the "largest possible packet that can be transmitted to or from a MySQL 5.0 server or client". The default value is 1M (1 MB). LiveCycle DSC deployment requires this to be at least 50M (50 MB).

This can be set in the my.ini configuration file for MySQL as follows:
max_allowed_packet=50M

It can also be configured using MySQL Administrator, the GUI Admin Tool for MySQL.

LiveCycle can be run as a user who is not the 'root' super user on IBM AIX, Sun Solaris, Red Hat Enterprise Linux and Novell SUSE Enterprise Linux. However, there are several requirements.

If the appserver (JBoss, WebSphere, WebLogic) is being run as the user 'apsrvusr', it is normal for the entire appserver folder structure to be owned by that user. In such a case, install LiveCycle also as that user.

After installation, ensure that the entire LiveCycle folder structure is also owned by this user. To be sure, you can run the following command, assuming you installed LiveCycle to /opt/adobe/livecycle8.2/ and the user belongs to the group 'appsrv':
chown -R apsrvusr:appsrv /opt/adobe/

Also make sure that you run LiveCycle Configuration Manager (LCM) as the same non-root user.

If you had configured everything to run as a non-root user and had also successfully run LiveCycle but then accidentally ran LiveCycle as 'root', it will throw exceptions if you subsequently run it as the original non-root user. The first exception will look something like this:
[com.adobe.livecycle.cache.adapter.GemfireCacheAdapter] Unable to load configuration file cache.xml
This is caused by the ownership of the Gemfire cache configuration XML file in the LiveCycle Temporary Folder (../adobejb_your_appserver_instance_name/Caching/cache.xml)changing ownership to 'root' and becoming non-writable by 'other' users. To fix this, shut down the appserver instance and re-run the 'chown' command (as 'root') on the appserver folder structure, assuming that the LiveCycle Temporary Folder is somewhere in that structure:
chown -R apsrvusr:appsrv /opt/jboss_4.2.0/

If you had pointed the LiveCycle "Temporary Folder", the "Global Document Storage" folder, the "Fonts" and "Customer Fonts" folders, the "Content Storage Root" and the "Content Storage Index" folders elsewhere, remember to execute the 'chown' command on those also.

Sometimes, the default logging level for WebSphere is not detailed enough to debug a LiveCycle issue. Also, in Production deployment, there is a need to minimize the amount of information logged because of its significant negative impact on performance as well as the increased storage requirements imposed by large log files.

WebSphere supports the following levels of logging.
- fatal
- severe (recommended for production deployment)
- warning (recommended for test environments)
- audit
- info (default)
- config
- detail (recommended for development environments)
- fine
- finer
- finest

The level can be applied globally, or separately to various packages deployed. All LiveCycle packages will begin with com.adobe.* and org.quartz.* (the open-source Quartz Job Scheduler) However, Content Services ES packages will begin with org.alfresco.* as well as org.hibernate.* (it uses the open-source Hibernate relational persistence framework) and org.springframework.* (it uses the open-source Spring application framework).

If you are not interested in being that specific, you can set the logging level for all packages by typing in this (for the 'detail' logging level):
*=detail

Change Log Level
----------------------
- In WebSphere Admin Console, click on the appserver instance that hosts LiveCycle
- Under the 'Troubleshooting' section, click on 'Change Log Level Details'
- Wait a few minutes for WebSphere to load all of the deployed packages.
- Click on the packes you are interested in. If you would like to include all packages, click on * [All Components], then 'Message and Trace Levels', and then choose your desired logging level.
- Click 'Apply', then 'Save'.

An appserver instance re-start is required for this to take effect.

The combinations of Operating Systems, J2EE Application Servers, Java Development Kits (JDKs), Database Management Systems (DBMSs) and LDAP Directories supported by LiveCycle are published. For LiveCycle ES Update 1 (8.2.1), please see this. For LiveCycle ES (8.0.1) and 7.2.2, please see this.

For the JBoss Turnkey, all LiveCycle database connections to MySQL are through a JDBC connection pool. This is usually defined in %LC_INSTALL_ROOT%\jboss\server\all\deploy\adobe-ds.xml.
Usually, three connection pools are defined. EDC_DS is for Rights Management, IDP_DS is for the rest of LiveCycle and com.celequest.metadata.metaDatasource is for Ithe IBM Cognos Business Activity Monitor (BAM). If you don't plan to use Rights Management ES or BAM, you can delete the definitions for those two.
For a long-running, reliable and stable LiveCycle ES environment, the data source definition for MySQL should look something like as shown below. Only the definiton for IDP_DS is shown. If parts of the XML are cut off in the display, please look at the page source or download it (hover over the link, right-click the mouse and choose "save target as".

<?xml version="1.0" encoding="UTF-8"?>
 <datasources>
  <local-tx-datasource>
   <jndi-name>IDP_DS</jndi-name>
   <connection-url>jdbc:mysql://localhost:3306/adobe</connection-url>
   <driver-class>com.mysql.jdbc.Driver</driver-class>
   <user-name>adobe</user-name>
   <password>password</password>
   <min-pool-size>1</min-pool-size>
   <max-pool-size>30</max-pool-size>
   <valid-connection-checker-class-name>com.mysql.jdbc.integration.jboss.MysqlValidConnectionChecker</valid-connection-checker-class-name>
   <exception-sorter-class-name>com.mysql.jdbc.integration.jboss.ExtendedMysqlExceptionSorter</exception-sorter-class-name> 
   <new-connection-sql>SELECT count(*) from DUAL</new-connection-sql>
   <check-valid-connection-sql>SELECT count(*) from DUAL</check-valid-connection-sql>
   <blocking-timeout-millis>20000</blocking-timeout-millis>
   <idle-timeout-minutes>1</idle-timeout-minutes>
   <autoReconnect>true</autoReconnect>
   <prepared-statement-cache-size>50</prepared-statement-cache-size>
   <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
  </local-tx-datasource>
 </datasources>

Adobe has published a technote on additional configuration that is required to ensure that installations of the LiveCycle ES Update 1 (8.2.1) JBoss Turnkey run stable over a long term. This only applies to JBoss Turnkey installations. The changes include:
1) replacing the 3.x version of the MySQL JDBC driver with a 5.0.x version
2) removing some of the JVM init arguments

These changes are HIGHLY recommended. These need to be made even if you have applied the recently released service pack (SP1).

Flash Player 10 broke the Reader Extensions sample application included with LiveCycle ES 8.0.1, and 8.2.1. When you use it, it will essentially hang. The workaround is to revert back to Flash Player 9 on those machines you use as LiveCycle clients. There is an Adobe technote that goes into more details. Also, please see this discussion on the Adobe Forum for LiveCycle ES Installation & Configuration.

LiveCycle ES Update 1 now supports custom-level Java Management EXtensions (JMX). Details are available in this technical guide.

JConsole that comes with all JDKs (Sun HotSpot, IBM J9 and Oracle JRockit) can be used to view this information. Instructions are available. Another commercial tool is CA Wily Introscope.