Posts tagged "caching"

LiveCycle ES3 SP1: Gemfire errors in server log after installing patches on top of 10.0.2


If you are using TCP locators in a LiveCycle cluster with ES3 (10.0.2) and have installed a service pack or patches on top of this version, you may notice some errors in the server log similar to the following:

com.adobe.livecycle.cache.CacheRuntimeException: Error loading cache configuration
at com.adobe.livecycle.cache.adapter.GemfireCacheAdapter.getCacheContainer(
at com.adobe.livecycle.cache.adapter.GemfireCacheAdapter.createRootRegion(
at com.adobe.livecycle.cache.adapter.GemfireCacheAdapter.init(
at com.adobe.livecycle.cache.adapter.GemfireCacheAdapter.<init>(
at com.adobe.livecycle.cache.adapter.CacheAdapterFactory.getCache(

Caused by: com.gemstone.gemfire.SystemConnectException: Attempt to connect to distributed system timed out

If you have a UDP-based cluster caching mechanism, you are not affected by this issue.


This issue occurs when the Gemfire version on the server is different from the Gemfire version used by the TCP locators.  Gemfire.jar and are delivered in two different places in the LC installation – 1. Core EAR 2. /lib/caching directory.

Gemfire version was used for LC ES3 (10.0.2).  To address some known issues a new Gemfire version ( was used in later versions and patches.  This newer Gemfire version was used for the Core EAR, but unfortunately not included for updating the caching directory.

To verify the issue, compare the Gemfire version in the GFLocator.log file for your TCP Locator with the Gemfire version in the Gemfire logs for your application server at the following location:

  • JBoss: <adobe_temp_dir>/adobejb_<server_name>/caching/Gemfire.log
  • Weblogic: <adobe_temp_dir>/adobewl_<hostname>/caching/Gemfire.log
  • WebSphere: <adobe_temp_dir>/adobews_*/caching/Gemfire.log

You will find that Gemfire on the LiveCycle server has a higher version.


This issue has been addressed in SP2 and later patch versions.

Note: the patch installer will only update the default caching directory (<lc_install_dir>/lib/caching) on the machine where LC is installed.  If you are running LC on various machines, and/or use custom caching directories, you will need to update the 2 Gemfire files for your TCP locators manually.  All TCP locators need to be restarted before starting LC servers.


For existing patches you can use the following workaround to fix the issue on your LiveCycle installation.

  1. Stop the LiveCycle server(s).
  2. Stop the TCP Locator(s).
  3. Go to <LC_INSTALL_DIR>/deploy folder.
  4. Open adobe-core-<appserver_name>.ear.
  5. Go to TCP locator installation directory. Typically the default location is <LC_INSTALL_DIR>/lib/caching.
  6. gemfire.jar and can be found here.
  7. Replace the two files above in the TCP locator with the same files from the core ear.
  8. Repeat the replacement procedure (steps 5 – 7) for each TCP locator.
  9. Start TCP Locator(s).
  10. Start LiveCycle server(s) in the Cluster.

Verify the Gemfire versions in GFLocator.log and Gemfire.log files. You should see the same Gemfire version in both files.

reference: (183615151/3327651)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 7.7/10 (3 votes cast)

LiveCycle Forms7: how to disable client-side caching


 If you are using FormServer 7.1 you may want to disable client-side caching.  This will prevent previously entered values from appearing on a new form when you open it in a fresh browser instance.


The problem is that Acrobat/Reader is caching the form (along with its data). It does this based on the URL address (same URL = same form/data). Unfortunately, since this is a client setting there is no easy way to disable it.


Here are some suggestions to achieve this:

1) on the form (i.e. will be on a form by form basis):

add this code into the form:ready event –

var oDoc =; 

oDoc.nocache = true;

2) make the URL unique:

An easy way of doing this is to return a date/time stamp as an unused parameter in the URL. This can be easily added by either the JSP or the servlet. For example:


3)  Also consider setting the cache control headers in your response:

// Set content to expire far in the past. 
response.setHeader("Expires", "Thu, 1 Jan 1970 12:00:00 GMT"); 

// Set standard HTTP/1.1 no-cache headers. 
response.setHeader("Cache-Control", "no-store, no-cache, must-revalidate"); 

// Set special IE extended HTTP/1.1 no-cache headers (use addHeader). 
response.addHeader("Cache-Control", "post-check=0, pre-check=0"); 

// Set standard HTTP/1.0 no-cache header. 
response.setHeader("Pragma", "no-cache");


reference: (1-28022235)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)