March 2009 Archives

While running the LiveCycle ES JBoss Turnkey (Windows), you will notice that even when you are not doing anything with LiveCycle, the CPU utilization is still about 5-10% If you use Microsoft's Process Monitor and watch the JBossService.exe (or java.exe, for non-turnkey JBoss) process that hosts the JBoss instance, you will notice several operations that cause this. Here are some things you can do to manage this.

Disable the Watch Folder of the Digital Signatures Sample Orchestration
------------------------------------------------------------------------------------------
The watch folder is called ..\LCWatchFolder\Signatures\. In the LiveCycle AdminUI, navigate to Services->Applications and Services->Service Management. Filter on the category 'Samples - DigitalSignatures'. Click on 'VerifyDigitalSignatures: 1.0'. Click on the EndPoints tab. Check the checkbox against the 'WatchedFolder' provider and disable it.

The watch folder functionality of LiveCycle essentially works by frequently polling the input folder for any input documents. Login to the LiveCycle Admin UI and disable the watch folder, assuming you are not using it!

Watch folders are expensive but convenient. If you have too many watch folders configured, you run the risk of them overwhelming your CPUs even when there's no work for them!

Configure LiveCycle Document Sweeps to Happen Less Often
----------------------------------------------------------------------------
In DEV environments, in the LiveCycle AdminUI, navigate to Settings->Core System Settings->Configurations and set 'Document sweep interval' to 600 (10 minutes) from the default 30 seconds.

Disable JBossAS Application Auto-deploy Feature
------------------------------------------------------------
This feature also works by a polling mechanism. It is less expensive on the CPU front. This feature lets you just drag and drop a new application (WAR or EAR) into the \deploy folder of JBossAS and have it deployed and started automatically. This is a great feature in a development environment but should be turned off in production and test environments.

In %JBOSS_HOME%\server\all\conf\jboss-service.xml, set the attribute 'ScanEnabled' of the mbean 'org.jboss.deployment.scanner.URLDeploymentScanner' to false.

Increase the JBossAS Log4J ConfigurationURL RefreshPeriod
---------------------------------------------------------------------------
In %JBOSS_HOME%\server\all\conf\jboss-service.xml, set the attribute 'RefreshPeriod' of the mbean 'org.jboss.logging.Log4jService' to 600 (10 minutes) from the default 60 seconds.

Can you tell us where in the configuration the location of the GDS is identified?
Login to the LiveCycle Admin Console (http://server:port/adminui) navigate to Settings->Core System Settings->Configurations. Look under "Global document storage root directory".

Was a location defined at install time, or will this exist at some default location?
Yes, it was probably defined at install time. There is a default, which varies with the OS. It is a bad idea to leave it blank (default).

How do I change the location after the install?
Please see here.

Is the GDS a file (or files) in the file system?
Yes, always. It can be a local filesystem but has to be an NFS/CIFS mount for a cluster. There can only be one of these, even if the cluster has 20 members. It is used to store any document larger than what is cofigured for "Default Document Max Inline Size" (AdminUI). It is also used to store Record and Playback output (Workbench). In fact, it is used whenever LiveCycle serializes a document .

If so, can this file(s) be copied (cp) or zipped?
Yes. But please make sure that the appserver instance hosting LiveCycle is stopped.

Does the GDS need to be in any particular state in order to copy it?
The ideal state is where the appserver instance(s) hosting LiveCycle is stopped. In 24x7 environments, put LiveCycle into "backup mode".

The doc implies that the GDS will store long-term. If so, would tape backup make the most sense?
Not necessarily. The "long-term" implication probably comes from our use of the term "long-lived" which only means orchestrations (workflows) involving human actors. So if you have business processes that last months, that's how long-term things need to be.

Can LiveCycle be changed to "backup mode" via a batch command script? If so, do you have an example you can share?
Those sample scripts are available at .../adobe/livecycle8.2/LiveCycle_ES_SDK/misc/Foundation/BackupRestoreCommandline/

The most fundamental thing to remember is that the backup of the database has to be time-synchronized with the backup of the GDS. More here.

The installation of the 64-bit version of Sun's HotSpot JDK on Solaris on SPARC is different from the installs of the other versions. To get a 64-bit JDK up and running, you have to download and untar the 32-bit version first. Then, download and untar the 64-bit supplement which will add some additional libraries to the previous 32-bit installation to give the complete 64-bit environment.

- Go here
- Choose "JDK 5.0 Update nn" where "nn" is the latest patch level
- Choose "Solaris SPARC"
- Download and run jdk-1_5_0_17-solaris-sparc.sh
- Download and run jdk-1_5_0_17-solaris-sparcv9.sh

Ensure that in the server startup scripts, the JVM arguments include -d64 to start the 64-bit JVM. Also, in the case of WebLogic, the following line would be necessary in the setDomainEnv.sh script:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$WL_HOME/server/native/solaris/sparc64
Otherwise, you will get the following warning:
Unable to load performance pack. Using Java I/O instead. Please ensure that a native performance library is in...

LiveCycle Configuration Manager (LCM) assumes that you are running your WebLogic instances using Node Manager. There are several large deployments out there where this is not the case. If yours is one of them, this is for you.

After configuring the WebLogic instance with JDBC and JMS, LCM will try to restart the instances. It will succeed in shutting them down but will fail to start them. This is because it needs the Node Manager to be runing in order to do this.

At this stage, do NOT run LCM again.

Add the changes made by LCM in the WebLogic Admin Console to the startup script of the managed server that hosts LiveCycle (startManagedWebLogic.sh). You can view these changes in the WebLogic Admin Console by navigating to [your_domain_name]->Environment->Servers->[your_managed_server_name]->Configuration->Server Start. The fields of interest are 'Class Path' and 'Arguments'.

In a typical non-clustered managed server, the script addition will look as follows (WebLogic 10 on Solaris 10 example used):

JAVA_OPTIONS="-Dadobeidp.RootDirectory="/opt/bea_home/user_projects/domains/livecycle" ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Dfile.encoding="utf8" ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Djava.net.preferIPv4Stack="true" ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Djava.io.tmpdir="/opt/bea_home/user_projects/domains/livecycle/lc_java_io_tmpdir" ${JAVA_OPTIONS}"
JAVA_OPTIONS="-Djava.security.policy="/opt/bea_home/wlserver_10.0/server/lib/weblogic.policy" ${JAVA_OPTIONS}"
CLASSPATH="/opt/bea_home/user_projects/domains/livecycle/lib/pop3.jar:
/opt/bea_home/wlserver_10.0/server/lib/weblogic.jar:
/opt/bea_home/jdk150_11/lib/tools.jar:
/opt/bea_home/user_projects/domains/livecycle/lib/ojdbc14.jar:"

If you are copy-pasting this, make sure that the line breaks in the CLASSPATH are all removed.

In addition, edit the setDomainEnv.sh script and add the following (lc_server1 is the name of the managed server, minimum and maximum heapsize is being set to 1 GB):

if [ "${SERVER_NAME}" = "lc_server1" ] ; then
MEM_ARGS="-Xms1024m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=256m"
export MEM_ARGS
fi

Start the managed server using the script. Ensure that the changes prescribed in the starup scripts have taken effect by verifying the managed server log. The heap size setting is very important, so is the setting for adobeidp.RootDirectory. The default heapsize is too low and will cause OutOfMemoryExceptions during the deployment of the DSCs or of the sample orchestrations.

Continue with the rest of the steps (initialize database, deploy DSCs etc).

For WebLogic 9.2, the CLASSPATH entry in startManagedWebLogic.sh will not work. In this case, add it to setDomainEnv.sh as follows:

PRE_CLASSPATH="/opt/bea_home/user_projects/domains/livecycle/lib/pop3.jar:
/opt/bea_home/wlserver_10.0/server/lib/weblogic.jar:
/opt/bea_home/jdk150_11/lib/tools.jar:
/opt/bea_home/user_projects/domains/livecycle/lib/ojdbc14.jar:"

If you are copy-pasting this, make sure that the line breaks in the CLASSPATH are all removed.

A bug introduced with LiveCycle Designer ES Update 1 (8.2) is now fixed in LiveCycle service pack 2 and the Acrobat 9.1 update. The bug causes a processing instruction ex. <?templateDesigner StyleID aped3?> to get copied repeatedly while working with the form. This can lead to extremely large file sizes and sometime causes crashes. The fix removes duplicate StyleID's found in existing forms and prevents them from being created.

If you installed Livecycle Designer with Acrobat Pro or Acrobat Pro extended you'll need to apply the update
Acrobat Pro Extended
Acrobat Pro

If you installed LiveCycle Designer with LiveCycle Workbench or as a stand alone product and have a maintence and support agreement in place please contact Adobe Enterprise Support .

The first set of updates to resolve a critical vulnerability found in Acrobat 9 and Reader 9 has been posted. It is recommended users of Adobe Reader and Acrobat 9 update to Adobe Reader 9.1 and Acrobat 9.1.

"Hub" is a new client application that connects your users desktops to LiveCycle ES services giving them the ability to do things like generating PDFs or assembling PDF packages. It's also a great example of how to write an AIR application that connects to custom services so you can start writing your own "Dashboard".

From the downloads page you can download both the installer as well as the project source code and for a general overview check out the Hub home page now on Adobe labs.

LC ES Developer Express version 1.1 has been released and brings with it support for LiveCycle ES 8.2.1 running on Microsoft Windows 2003 Server Enterprise Edition within Amazon EC2, using JBoss 4.2.0 and Microsoft SQL Server 2005 Express.

The Windows-based virtual instances of LiveCycle ES are configured with all of the same features as the existing RedHat Linux-based virtual images, including support for BAM, ContentSpace, and PDF Generation using OpenOffice.

If you still don't have access to Express and the AEDP, be sure to sign up here: http://www.adobe.com/devnet/aedp.

LiveCycle's InstallShield-based installer is GUI-based. If you are installing LiveCycle on an AIX/Solaris or Linux environment hosted in a datacenter, this will force you to connect to the desktops on those boxes via an X11 server from a remote Windows XP or Vista machine. Cygwin works fine in Windows XP but not on Windows Vista. Cygwin also has a very large disk footprint since in addition to being a X11 server, it is also a complete UNIX environment for Windows.

A much smaller footprint option is Xming. For Windows Vista as well as XP, Xming, along with an SSH client such as PuTTY will work great to export displays to Windows.

1) Download and install PuTTY from here.

2) Download and install Xming from here.
Follw installation instructions here.

3) Start Xming

4) Start PuTTY
Create a profile for your server. Make sure that the SSH->X11 setting is set to 'Enable X11 Forwarding'. Save the profile.

5) Load the profile

6) Connect and login

7) Test using xclock
If the X11 packages are properly installed and configured on the server, you are now ready to test. For example, in Solaris 10, run the command:
/usr/openwin/bin/xclock
and if everything works, you should have a clock window pop up on your Windows machine.

In SUSE Linux Enterprise Server 10, the command is /usr/X11R6/bin/xclock

8) Run the LiveCycle installer.

On some operating systems like AIX, this approach might not work. In those cases, try the following:

1) Create a batch file with the following contents:
@echo off
SET DISPLAY=127.0.0.1:0.0
SET REMOTE_HOST=bladerunner.company.com
SET LOCAL_HOST=10.20.30.40
start Xming -query %REMOTE_HOST% -nodecoration -lesspointer -from %LOCAL_HOST% -notrayicon -clipboard

where bladerunner.company.com is the DNS name of your UNIX host and 10.20.30.40 is the IP address of your Windows client.

2) Copy it to the Xming folder. Run it to start Xming. You should get the UNIX machine's login screen displayed on your Windows desktop. Login.

3) Run the LiveCycle installer.