Archive for July, 2011

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)

LiveCycle ES2: UserM:GENERIC_WARNING: errorCode:12817 errorCodeHEX:0x3211 The user [user] is marked as Obsolete

Issue

If you are accessing any LiveCycle services and have problems getting a response, you may notice the following warning in the server logs:

WARN  [com.adobe.idp.common.errors.exception.IDPLoggedException] (Thread-21) 
UserM:GENERIC_WARNING: [Thread Hashcode: 1859008299] 
com.adobe.idp.common.errors.exception.IDPLoggedException| [AuthenticationManagerBean] 
errorCode:12817 errorCodeHEX:0x3211 message:The user <user> is marked as Obsolete

If you enable DEBUG level logging you will see the following DEBUG information in the log:

=========== Authentication failure detail report ==================
Scheme Type : Username/Password 
UserId : user 
Current Thread : ajp-0.0.0.0-11148-2
Following users were identified as per received authentication data. Details are (UserId, domain, oid)
     - user, DefaultDom, 7C5E5622-96A9-102F-AE67-00000XXXXXXX 
Following are the response details from various authProviders.
1 - com.adobe.idp.um.provider.authentication.LDAPAuthProviderImpl
- Authentication Failed : Exception stacktraces are avialable at TRACE level 
Messages collected for this AuthProvider are provided below
    - LDAP authentication failed for user [user] in Domain [corp.domain]
        - Unprocessed Continuation Reference(s)
2 - com.adobe.idp.um.provider.authentication.LocalAuthProviderImpl
- Authentication Failed : Exception stacktraces are avialable at TRACE level 
Messages collected for this AuthProvider are provided below
    - The user user is marked as Obsolete
    - No local user found with UserId [user] in Domain [DefaultDOM]

These warnings in the log may also be accompanied by an Error 500 if you are attempting to call the LC services through a browser/web application.

Reason

This issue can occur when you are attempting to access the services with a user account that has been marked obsolete in the LiveCycle database.  This can occur if you have deleted this specific user from LDAP or from the local domain in LiveCycle.

If you have written applications depending on this user account then you will encounter the problem outlined above when running/calling those applications.

Solution

You could either re-create the user in your LDAP or local domain, or you can create a new user and then change your application to reference this new user rather than the obsolete user account.

reference: (183305926)

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