How to Ensure that TCP Locators are Using Correct Version of Gemfire Used by LiveCycle ES2 Cluster

LiveCycle uses Gemfire technology provided by GemStone systems (now VMware) for maintaining the cluster cache. LiveCycle can be configured to use either multicast (UDP) based caching mechanism or TCP caching mechanism using TCP locators.

TCP locators are recommended for production clusters due to the inherent reliability of the TCP protocol.

The TCP locator runs in a separate JVM process and LiveCycle servers are configured to know about TCP locators using specific JVM arguments. While starting up TCP locator(s), you specify the gemfire.jar file to be used by the TCP locator(s). By default TCP locator writes log messages to GFLocator.log file – another JVM argument you specify when you start TCP locator.

LiveCycle is typically deployed to a J2EE application server. When you install and configure LiveCycle, various EAR files get created, depending on which solution components you install. In the case of JBoss, one of the files you would see is adobe-livecycle-jboss.ear

adobe-livecycle-jboss.ear file also contains a gemfire.jar file; which is loaded by the JVM when application server starts up.
Another log file called Gemfire.log file gets created under \\Gemfire.log.

It’s important that versions of gemfire.jar file used by adobe-livecycle-jboss.ear and TCP locator(s) match; for successful cluster setup.
You can verify this by looking at GFLocator.log and Gemfire.log files described above.

Here are log snippets for an environment, where these source revisions do “not” match.

GFLocator.log snippet –

Java version: 6.0.1 build 24822 04/28/2009 15:48:45 PDT javac 1.5.0_17
Source revision: 24822

Gemfire.log snippet –

Java version: build 30795 03/11/2011 19:11:36 PST javac 1.5.0_17
Source revision: 30795

In this case, LiveCycle servers were not able to establish communication with TCP locator; and cluster was not working.
Jboss server.log showed messages like –

2011-07-14 01:30:22,426 ERROR [STDERR] javax.ejb.EJBException: Unexpected Error
java.lang.NoClassDefFoundError: Could not initialize class com.adobe.livecycle.cache.adapter.GemfireCacheAdapter
at com.adobe.livecycle.cache.adapter.CacheAdapterFactory.getCache(
at com.adobe.pof.POFUtil.getPOFDataDictionaryCache(

In order to resolve such situation, extract Gemfire.jar file from adobe-livecycle-jboss.ear (Using WinZip); and replace the version of Gemfire.jar used by TCP locator with extracted copy.
Backup of existing Gemfire.jar should be taken prior to replacement.

Sequence to restart cluster:

Stop LiveCycle servers (i.e. application server nodes where LiveCycle is deployed),
Stop tcp locator(s),
Start tcp locator(s) and
Start LiveCycle servers.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 10.0/10 (1 vote cast)
How to Ensure that TCP Locators are Using Correct Version of Gemfire Used by LiveCycle ES2 Cluster, 10.0 out of 10 based on 1 rating

About Santosh Tatke

Santosh Tatke is a Sr. Support Architect at Adobe Systems. He specializes in ADEP (formerly LiveCycle) technology stack and works closely with customers, solution consultants and partners to troubleshoot, analyze and resolve technical challenges during POC, implementation, deployment or upgrade. He is a Certified LiveCycle ES2.5 Process Management Expert.
This entry was posted in Adobe LiveCycle ES2 (9.0.x), General Interest and tagged , , , , . Bookmark the permalink.

4 Responses to How to Ensure that TCP Locators are Using Correct Version of Gemfire Used by LiveCycle ES2 Cluster

  1. welding rods says:

    I see something really interesting about your site so I saved to my bookmarks .

  2. Santosh Tatke says:

    Thanks for your feedback.

  3. Aditya says:

    How is it possible to run start and stop locators as a windows service. I tried using java service and couldn’t run stop-locator.

    Can you help or suggest alternative options.


    • Santosh Tatke says:

      On ES2, TCP locator as a windows service was not tested hence not certified.
      However, we’ve heard of some customers successfully using Java Service Wrapper, to configure TCP locator as windows service.

      There is another commercial software called fireDaemon which has worked great for a customer.