December 2008 Archives

LiveCycle ES 8.2 comes with a new distributed cache from Gemstone called Gemfire. Here's a press release from Gemstone in this regard. In cluster deployments, it is critical that all members of a LiveCycle cluster be able to find one another so that they can keep their individual caches in synch with one another.

Members of a LiveCycle cluster find and communicate with one another using IP multicasting. UDP is simpler to configure than TCP because TCP requires that you run an additional TCP Locator service. However, UDP has limitations of its own, especially when cluster members are not all in the same IP subnet.

UDP

To over-ride the default IP address used by Gemfire, a JVM argument can be used. The following example sets the address a well as the port (35001):

-Dgemfire.mcast-address=239.255.2.10 -Dadobe.multicast-port=35001

For guidelines from Cisco about allocating IP Multicast addresses, see here. The most restrictive ("Site-Local Scope") is the range 239.255.0.0 to 239.255.254.255

To verify that the cache is working, navigate to the LiveCycle Temporary Folder (configured using the LiveCycle Configuration Manager and later on changeable via the LiveCycle Admin UI) and open Gemfire.log. In WebSphere, the path will be:
$LC_TEMP/adobews_yourcellname_yournodename_yourappserverinstancename/Caching/

If the cache is working, you should see entries such as these:

GemFire P2P Listener started on tcp:///10.10.20.22:41585
Starting distribution manager aix1:62840/41585
Initial (membershipManager) view = [aix2:42282/35386, aix1:62840/41585]
admitting member ; now there are 1 non-admin member(s)
admitting member ; now there are 2 non-admin member(s)

TCP

In environments were UDP does not work, TCP has to be used. Copy the folder %LIVECYCLE_INSTALL_ROOT%\lib\caching\ and its contents to at least two of the horizontal cluster members. If only one TCP Locator instance is run, it will become a single point of failure. Edit and then run startlocator.bat (or startlocator.sh in Unix) so that the last line looks something as follows:
java -cp .\gemfire.jar com.gemstone.gemfire.internal.SystemAdmin start-locator -port=22345 -Dgemfire.license-type=production -Dlocators=node1.company.com[22345]
where 22345 is the port specified by you while running LiveCycle Configuration Manager (LCM) and added as a JVM argument
(-Dadobe.cache.cluster-locators=node1.company.com[22345],node2.company.com[22345]).

Before you run the startlocator batch/sh file, make sure that there are no files named .locator or PID_file in that folder. If they exist, delete them first.

In 64-bit Windows environments, edit and use the file startlocator_win64.bat

See the LiveCycle clustering guides for more details.

Linux system administrators tend to be minimalists, installing only the bare minimum of packages required to have a machine running. However, LiveCycle, depending on the Linux flavour, might require additional packages to be installed.

cURL
libcurl.so is a shared object (so) or library required by Forms ES and Output ES to merge XML data with form templates. cURL is a command line tool for transferring files with URL syntax, supporting HTTP and HTTPS, along with other protocols. If this package is not installed, testing of form rendering with XML data merge using FormsIVS will fail.

IDN
libidn.so is the Internationalized Domain Name support library, usually needed in non-English locales.

Xorg-x11-tools (for RHEL4) (Xorg-x11-apps for RHEL5)
These packages are required so that the LiveCycle installer as well as the LiveCycle Configuration Manager (LCM) Graphical User Interfaces (GUIs) can function.

Compat-libstdc++
Compatibility standard C++ libraries is yet another package that might need to be installed.