Avoka Blog: Adobe LiveCycle

June 16, 2008

LiveCycle directories – Global Storage/Temp, clustering, and more…

Filed under: LiveCycle, LiveCycle Administration, LiveCycle Architecture — htreisman @ 11:03 am

The information in this Blog is correct to the best of my knowledge – if you discover any errors, please post on the comments area.

Thanks to Pete Spencer of Adobe for his expertise.


  • You need to specify various directories when you configure LiveCycle using the Configuration Manager. These include:
    • Global Document Storage (GDS) Directory
    • Temporary Directory
    • Font Directories
  • The values you enter into Configuration Manager are stored within the LiveCycle ear file. The values in this ear file are only used during initializing (bootstrapping) the LiveCycle database – after this, they are no longer used, and the values from the database are used instead.
  • All of the directories must be specified from the perspective of the application server, NOT the perspective of the machine running Configuration Manager. In other words, these directories must exist on the application server. It’s therefore simplest if you actually run Configuration Manager on the target machine.
  • You can modify the directory names in the database using Adminui at any time, including after installation. Home > Settings > Core System Settings > Configurations. You must restart the server before your changes take effect. You MUST move files from the old GDS to the new GDS while the server is stopped. You do not need to reconfigure or redeploy your ear files.
  • There is only one directory location stored in the database, no matter how many instances you have in your cluster. In a clustered environment, you must set up your servers so that all of them have the same GDS, temp and font directory names. (There’s a way around this for the temp directory – see below.)

For example: if you’re running LiveCycle on different operating systems, you cannot set the System Font directory to c:\windows\fonts on one machine, and c:\winnt\fonts on a different machine. You will have to make the directory the same on all machines, even if this means copying files to matching directories.

Another example: You cannot set the Global Storage Directory to “C:\Adobe\Global” on one machine, and “\\machine1\c$\Adobe\Global” on another. You can use “\\machine1\c$\Adobe\Global” on both machines (although this would create a single point of failure).

  • Make sure that the user under which you run the Application Server has read/write access to the temp/GDS directories, and read access to the Font directories.
  • You can use the same LiveCycle ear files for installs onto multiple boxes (eg Dev, Test, Production), even if the actual directories on a second box don’t match those that you specified for the first box. You can deploy the LiveCycle ear files, run LiveCycle, and bootstrap the database. Then you can modify the directories using Adminui, and restart LiveCycle. Once you’ve done this, you can complete the configuration by installing components and samples, etc. (Note: We haven’t thoroughly tested this, and don’t know for sure that those directories in the LiveCycle ear file aren’t used for some other purpose – we recommend that you create separate LiveCycle ear files for each machine configuration.)

Font Directories

  • These can be shared, or each application server in a cluster can have its own copy on a local drive.
  • If you’re running Configuration Manager on one machine, and deploying to another, you must copy the LiveCycle fonts from the installation directory (usually C:\Adobe\LiveCycle8\fonts) to a location on the application server machine.
  • Under Windows, the system fonts are generally either in C:\windows\fonts or c:\winnt\fonts.

Global Document Storage Directory (GDS)

  • The GDS should be considered an extension to the database, and is part of the persistent state of the LiveCycle system. Don’t “clean up” the files in this directory.
  • You should back up the files in this directory simultaneously with the database. See my previous post on this topic.
  • The GDS must be a single directory that is shared between all instances of LiveCycle in a cluster. Usually this means setting up the GDS on a shared drive, or a Storage Area Network (SAN).
  • It must also be referred to by exactly the same pathname for all instances of LiveCycle.
  • If you change the location of the GDS, you must ALSO move all the files to the new location while the server is stopped.

Temporary directory

  • Each running instance of LiveCycle requires its own temporary directory. There are a number of ways of specifying the temporary directory:
  • If you specific a non-blank directory in Configuration Manager (which also means a non-blank directory in adminui), then LiveCycle will use this value.
  • If you specify a blank directory in Configuration Manager/Adminui, then LiveCycle will use the Java VM java.io.tmpdir system property.
  • The java.io.tmpdir property can be set in several ways:
    • You can specify it explicitly in the command line that you use to launch the Java VM that runs LiveCycle. For example, “java -Djava.io.tmpdir=C:\temp …”
    • If you do not specify it explicitly, Java will set this value based on operating system defaults (eg value of “TEMP” system variable)
  • If you are using vertical clustering, the members of the cluster will each need their own temp directory, but they are sharing the same physical drive. Therefore
    • Leave the temporary directory blank in Configuration Manager/Adminui.
    • Specify a different java.io.tmpdir Java system property for each instance of LiveCycle.


  1. OK, here are some scenarios I’d like to understand, because you know, once we go to production, we most likely will see these scenarios at some point. Let’s first make the assumption that it’s not probable to recover the GDS and the system tables back to the same point in time (hopefully that’s an acceptable assumption):

    Scenario 1:
    The Ford family, after having lost millions on the Detroit Lions 0-16 season this year, decides to modify their IRAs to be more conservative. The bank teller assists with completing the form but needs authorization from the product manager. The form is submitted but is in mid-process waiting on this authorization.

    The GDS tanks. Can only be recovered up to the previous night. The DB2 System tables are fine.
    What is lost? The form? The process state?
    How does the timid teller get the Ford family back on track?
    How does the live cycle admin get the system back on track?
    How to identify other accounts that were opened that day (forms) and are in mid-process?

    Scenario 2:
    Tom Illitch has made millions on his reliable Red Wings and opens 5 new CDs. Bank teller needs authorization, so again, the form is submitted but is in mid-process waiting on this authorization.

    The System tables tank. Can only be recovered up to last night’s backup. However, the GDS is fine.
    What is lost?
    How does the nail-biting teller get Tom Illitch back on track?
    How does the live cycle admin get the system back on track?
    How to identify other accounts that were opened that day (forms) and are in mid-process?

    Scenario 3:
    GM CEO Richard Wagoner wants to protect his millions in government bailout money by investing in a wealth management portfolio. 100 other financially well-off people follow his lead.
    There are now 101 forms mid-process in the livecycle system.

    The GDS Tanks and the System tables take a nose dive. Can only be recovered up to last night.

    How to identify all of the forms that were submitted in order to recover?

    Having these types of scenarios and what-to-do’s documented will go a long way towards people’s understanding of LC backup/recovery. Or at least it will for me.
    Thank You
    Elaine (obviously from Michigan 😉

    Comment by Elaine Schmitz — February 7, 2009 @ 5:03 am

    • Hi Elaine
      1, 2: It’s a backup. If you only have a partial backup, then you don’t have a backup. It would be the same if you only backed up half your database. If a disaster occurs while you don’t have a complete backup, you’re up smelly creek with no outboard 😦 This is the nature of disasters – recovery sometimes isn’t complete.
      3. There are a number of ways of doing this, all of which involved saving either the form or the data to some sort of secondary storage. We usually store the form data to a table, and if the disaster strikes, we dump a portion of that table and attempt a manual recovery.

      I hope this helps…

      Comment by htreisman — February 9, 2009 @ 8:31 am

  2. So, if the GDS does tank and the db does not and you are in a partial backup situation, is the only option to start with a clean slate in both (i.e. set up another db?)

    Comment by Scott — February 28, 2009 @ 5:37 am

    • Hi Scott
      You don’t have to start with a clean slate, but as far as I know, you do have to restore the most recent consistent backup of the GDS/database.
      This may be a more detailed question for Adobe – what exactly is broken, and is there any way of fixing it.
      I do know that Adobe are aware of some of these issues (it was raised at meet-the-team at MAX), and they are looking at addressing a lot of this in ES2.

      Comment by htreisman — February 28, 2009 @ 5:27 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog at WordPress.com.

%d bloggers like this: