Posts tagged "gds"

LiveCycle ES2: Unexpected exception. Failed to create directory: \\<cluster>\GDS

Issue

If you have configured the WebSphere node agents to start as Windows services instead of using the batch files in your cluster you may experience the following behaviour:

  • in AdminUI > Services > Applications and Services > Application Management, you may receive an ALC-DSC-033-000 error
  • in AdminUI > Services > Applications and Services > Service Management, you will see many services marked Inactive, and you cannot stop/start them

You will also notice the following errors in the SystemOut.log on the individual cluster nodes when starting the servers:

E com.adobe.idp.dsc.registry.service.impl.ServiceStoreImpl createServiceConfigurationFromBOI
    COULD NOT PROCESS SERVICE: Process Management (system)/Queue Sharing VERSION: 1.0 MARKING AS INACTIVE
E com.adobe.idp.dsc.registry.service.impl.ServiceStoreImpl createServiceConfigurationFromBOI TRAS0014I:
    The following exception was logged java.lang.ClassNotFoundException: server.startup : 1Class name
    com.adobe.idp.workflow.dsc.descriptor.WorkflowDSCDescriptor from package com.adobe.idp.workflow.dsc.descriptor not found.
....
W com.adobe.idp.dsc.registry.service.impl.ServiceRegistryImpl getHeadActiveConfiguration
    Head active ServiceConfiguration for service: Process Management (system)/Queue Sharing version: 1.0 is not active as expected.
    The service was probably Marked INACTIVE due to an error loading the service.  Please look at the logs to see if this service was Marked INACTIVE.
...

The SystemOut.log will also contain the following error:

E com.adobe.idp.DocumentFileBackend getTimeSkewDelta DOCS001: Unexpected exception. Failed to create directory: \\es2cluster\GDS.
E com.adobe.idp.Document passivate DOCS001: Unexpected exception. While re-passivating a document for inline data resizing..
E com.adobe.idp.Document passivate TRAS0014I: The following exception was logged com.adobe.idp.DocumentError:
Failed to create directory: \\es2cluster\GDS
    at com.adobe.idp.DocumentFileBackend.getTimeSkewDelta(DocumentFileBackend.java:113)
    at com.adobe.idp.DocumentFileBackend.<init>(DocumentFileBackend.java:86)
    at com.adobe.idp.Document.getGlobalBackend(Document.java:3153)
    at com.adobe.idp.Document.writeToGlobalBackend(Document.java:2977)
    at com.adobe.idp.Document.doInputStream(Document.java:1698)
    at com.adobe.idp.Document.passivateInitData(Document.java:1457)
    at com.adobe.idp.Document.passivate(Document.java:1235)
    at com.adobe.idp.Document.passivateGlobally(Document.java:1205)
    at com.adobe.idp.dsc.management.impl.ArchiveStoreImpl.createNewArchive(ArchiveStoreImpl.java:636)
    at com.adobe.idp.dsc.management.impl.ArchiveStoreImpl._getArchive(ArchiveStoreImpl.java:438)

Reason

The Windows services that you have created do not have the correct privileges for accessing the LiveCycle GDS directory which is required for the proper operation of the LiveCycle server.

Solution

Open the Services view from the Control Panel in Windows.
Select the WAS NodeAgent service and goto properties > LogOn > Log on as > This account.
Browse for an Administrator account with sufficient privileges to access the GDS share.
Restart the NodeAgent.
Then restart the cluster from the WAS ND admin console.

Additional Information

To create the nodeagent as a Windows service instead of using the batch files:

1. Change to the \bin directory where WebSphere is installed, for example:

C:\Program Files\IBM\WebSphere\AppServer\bin

2. Run the following command:

wasservice -add ctgNode01_nodeagent
          -servername nodeagent
          -profilePath “C:\Program Files\IBM\WebSphere\AppServer\profiles\ctgAppSrv01″
          -wasHome “C:\Program Files\IBM\WebSphere\AppServer”
          -logFile “C:\Program Files\IBM\WebSphere\AppServer\profiles\ctgAppSrv01\logs\nodeagent\startNode.log”
          -logRoot “C:\Program Files\IBM\WebSphere\AppServer\ctgAppSrv01\logs\nodeagent”
          -restart true
          -startType automatic

You can do this for each cluster node.  Now when you restart Windows, the nodeagent on each cluster node will start automatically.

reference: (1911394)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 9.0/10 (1 vote cast)

LiveCycle ES: explanation of GDS directories

Introduction:

The global document storage (GDS) in LiveCycle ES is a directory used to store long-lived files such as PDF files used within a process or DSC deployment archives. Long-lived files are a critical part of the overall state of the LiveCycle ES environment. If some or all long-lived documents are lost or corrupted, the LiveCycle ES server may become unstable. Input documents for asynchronous job invocation are also stored in the GDS and must be available in order to process requests. Therefore, it is important that the GDS is stored on the redundant array of independent disks (RAID) and backed up regularly.

In general, it is not recommended to make any manual changes in the GDS directory as doing so can cause issues in your LiveCycle server leaving it in a unstable state.  This information is provided as an explanation of the directories within the GDS only, and should not be seen as a guide to making changes.

Directories:

The GDS can contain the following sub-folders:

1. audit –  This folder is used to store ‘Record and Playback’ data when recording is activated through Workbench.  ‘Record and Playback’ can be turned on/off at the orchestration (process) level.  If you turn it on for a particular process, it will save data in the /audit folder for every invocation of the process.

Running load testing on processes with recording turned on is therefore not recommended as this can fill up your hard disk.  You can purge the audit folder without consequences (apart from losing your process recordings).  It is best to purge it by using Workbench to delete process recordings.

2. backup – This folder is used to store data related to using LC backup mode.  The folder is managed by LC and should not be modified manually.

3. docmXXX… folders – These folders contain data and files related to long-lived processes.  Do not manually modify the docm folders otherwise the GDS may get out-of-sync with the DB and you will have to restore from a backup.

Once the process instances are completed or terminated, you can clean them using the purge utility in the SDK, if it is Ok for your organization to clean archived process data.  Once the completed/terminated process instances are purged using the purge utility, the related docm folders will also be cleaned by LC.  This can be useful to control the disk usage of the LC server.

4. removeOn.XXX… folders – These folders contain data related to the running services in LC.  They are managed by LC and cleaned automatically after document disposal timeout

5. sessionInvocation-adobews__XXX… – These folders are created by LC when performing document operations when the LC7 compatibility layer is installed.  The remaining empty folders can be cleaned up manually even when the LC server is running without breaking any dependencies.  This is important on some platforms like AIX where there is a kernal limit (~32,000) on the number of sub-folders in a folder.  There is a patch available for LiveCycle ES2 to prevent these folders being created when the LC7 compatibility layer is installed.  Contact enterprise support if you require this patch.

6. sessionJobManager-XXX – These folders are created by LC when using watched folders to perform document operations.  They are managed by LC and should not be modified manually.

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