Posts in Category "Installation"

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

Issue

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(GemfireCacheAdapter.java:164)
at com.adobe.livecycle.cache.adapter.GemfireCacheAdapter.createRootRegion(GemfireCacheAdapter.java:853)
at com.adobe.livecycle.cache.adapter.GemfireCacheAdapter.init(GemfireCacheAdapter.java:218)
at com.adobe.livecycle.cache.adapter.GemfireCacheAdapter.<init>(GemfireCacheAdapter.java:207)
at com.adobe.livecycle.cache.adapter.CacheAdapterFactory.getCache(CacheAdapterFactory.java:103)

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.

Reason

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

Gemfire version 6.5.1.17 was used for LC ES3 (10.0.2).  To address some known issues a new Gemfire version (6.5.1.35) 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.

Solution

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.

Workaround

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 GemFireVersion.properties 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: JBoss stopped logging in server.log

If you have installed LiveCycle in a JBoss application server the server activity will normally be logged in:

<JBOSS_HOME>\server\<profile>\log\server.log

If the JBoss log is no longer logging activity you should check the following:

1. Log4J

The jboss-log4j.xml file is located in <JBOSS_HOME>\server\lc_turnkey\conf and controls logging in JBoss.  If there is any problem with this file then logging may stop working.  You can download this file (jboss-log4j-working) from a fresh LiveCycle installation on JBoss and replace the original (make a backup first).  Restart JBoss after swapping the log4j file and logging should switch to the server1.log file.

2. User account

If you are starting JBoss using a Windows service ensure that the user account used for the service has administrative privileges.  See the installation documentation for further requirements such as disabling UAC on Windows.

reference: (183305796)

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

LiveCycle ES3: ReaderExtensionsService – PKI Intialization failed. Exception: com/rsa/jsafe/provider/JsafeJCE

Issue

If you have installed ADEP/LC ES3 (10.0.x) you may notice the following error in the server log when starting the application server:

2012-04-18 15:32:49,500 ERROR [com.adobe.livecycle.readerextensions.ReaderExtensionsService] (main) PKI Intialization failed. 
Exception: com/rsa/jsafe/provider/JsafeJCE
2012-04-18 15:32:49,515 ERROR [org.jboss.ejb.plugins.LogInterceptor] (main) RuntimeException in method: 
public abstract java.lang.Object com.adobe.idp.dsc.transaction.impl.ejb.adapter.EjbTransactionBMTAdapterLocal.doRequiresNew(
com.adobe.idp.dsc.transaction.TransactionDefinition,com.adobe.idp.dsc.transaction.TransactionCallback) 
throws com.adobe.idp.dsc.DSCException:ALC-DSC-099-000: com.adobe.idp.dsc.DSCRuntimeException:
java.lang.ClassNotFoundException: Class name com.rsa.jsafe.provider.JsafeJCE from package com.rsa.jsafe.provider not found.

Reason

This error can occur when the wrong JSAFE and CERTJ JAR files have been imported to your application server.

Solution

Review the installation/configuration documentation and ensure the correct JAR files have been copied to your application server.

For example:

http://help.adobe.com/en_US/enterpriseplatform/10.0/ClusterJBoss/WSf7e9d1e3f353177725b65b451306fc33289-8000.html

reference: (183158539)

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

LiveCycle ES2: LCMException[ALC-LCM-030-200]: Failed to deploy component

Issue

If you are installing and deploying patches for LiveCycle ES2 using the command line version of LiveCycle Configuration Manager (LCM) you may encounter an error similar to the following while deploying components:

com.adobe.livecycle.lcm.core.LCMException[ALC-LCM-030-200]: Failed to deploy component
 /opt/adobe/adobe_livecycle_es2/deploy/adobe-usermanager-dsc.jar.
         at com.adobe.livecycle.lcm.feature.deployment.DeployDSCs.deployDSCFiles(DeployDSCs.java:419)
         at com.adobe.livecycle.lcm.feature.deployment.DeployDSCs.deployDSCs(DeployDSCs.java:151)
         at com.adobe.livecycle.lcm.headless.HeadlessLCMImpl.deployDSCFilesLFS(HeadlessLCMImpl.java:285)
         at com.adobe.livecycle.lcm.cli.DeployLCComponentsCLI.executeCommandLineImpl(DeployLCComponentsCLI.java:96)
         at com.adobe.livecycle.lcm.cli.LCMCLI.execute(LCMCLI.java:298)
         at com.adobe.livecycle.lcm.cli.LCMCLI.main(LCMCLI.java:344)

and the LC logs may contain the following exception messages:

Component: com.adobe.PDFServices version: 9.0.0.2.20120202.1.312922 
introduced a new service, it should not be patched

….

java.lang.NoClassDefFoundError: com/adobe/idp/um/api/PreferenceManager

Reason

This problem occurs if the order of operations in LCM is incorrect.  For example, if you run the deploy components step (DSCs), before configuring and deploying the new EARs.  This can occur when using the command line LCM as you call each operation separately.  It can also occur using the UI LCM if you run the tool twice in succession and select to deploy components in the 1st run before deploying the EARs in the 2nd run.

Solution

You should re-run the LCM steps ensuring to configure and deploy the EARs first, before deploying the components.

 

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

LiveCycle ES2: UnsupportedClassVersionError: (oracle/jdbc/OracleDriver) bad major version at offset=6

Issue

If you are attempting to configure Adobe LiveCycle server using the LiveCycle Configuration Manager (LCM) with an Oracle database, you may encounter the following exception during the DB configuration step:

Caused by: java.lang.UnsupportedClassVersionError:
(oracle/jdbc/OracleDriver) bad major version at offset=6
 at java.lang.ClassLoader.defineClassImpl(Native Method)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:258)
 at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:151)
 at java.net.URLClassLoader.defineClass(URLClassLoader.java:589)
 at java.net.URLClassLoader.access$400(URLClassLoader.java:123)
 at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:1034)
 at java.security.AccessController.doPrivileged(AccessController.java:279)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:491)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:631)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:597)
 at java.lang.Class.forNameImpl(Native Method)
 at java.lang.Class.forName(Class.java:130)
 at com.adobe.livecycle.cdv.validator.DBValidator.validateDB(DBValidator.java:174)

Reason

This error can occur if you are not using the correct Oracle DB driver, or the correct Java JDK for your platform.

Solution

You should check the Oracle DB driver and JDK version required in the relevant platform matrix.  With LiveCycle ES2 for example the platform matrix is located here:

http://help.adobe.com/en_US/LiveCycle/9.5/supported_platforms.html

So if you were to install LiveCycle ES2 on AIX 5.3 with WebSphere 7, you should be using the 64-bit JDK 1.6 SR7 provided by WebSphere (WAS_HOME/AppServer/java), and the ojdbc6.jar Oracle driver.

Be sure to set the JAVA_HOME and PATH environment variables as instructed in http://help.adobe.com/en_US/livecycle/9.0/prepareinstallsingle.pdf

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

LiveCycle ES: NoSuchMethodError installing/uninstalling patches

Issue

If you are installing/uninstalling patches or service packs for LiveCycle ES you may encounter the following exception in the server log:

Caused by: javax.ejb.EJBException: Unexpected Error
java.lang.NoSuchMethodError: com.adobe.pof.omapi.POFQuery.addFilter(Ljava/lang/String;Ljava/lang/String;IJ)Lcom/adobe/pof/omapi/POFFilter;
    at com.adobe.idp.event.util.EventDBHelper.getNewAsynchEventIDs(EventDBHelper.java:5704)
    at com.adobe.idp.event.notification.NotificationManagerImpl$2.doInTransaction(NotificationManagerImpl.java:375)
    at com.adobe.idp.dsc.transaction.impl.ejb.adapter.EjbTransactionCMTAdapterBean.execute(EjbTransactionCMTAdapterBean.java:342)
    at com.adobe.idp.dsc.transaction.impl.ejb.adapter.EjbTransactionCMTAdapterBean.doRequiresNew(EjbTransactionCMTAdapterBean.java:284)
    at sun.reflect.GeneratedMethodAccessor231.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:592)
    at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
    at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:237)
    at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.in

This exception will usually occur following the EAR deployment.

Reason

When you install/uninstall patches for LiveCycle ES they will update files included in the EARs and also the DSC component files which are then deployed as services.  The versions of the EARs and components deployed must match, otherwise you will see this exception.  If the versions do not match, then the components may be referencing Java methods which were added/modified in the later patch, and therefore not available in the EARs or vice versa.

This exception will often occur directly after the updated EARs are deployed but the components have not yet been updated, as these are two separate steps in LCM.  Even after deploying the updated components the exception may still occur, as they are still loaded in the cache.

Solution

Ensure you have successfully completed deployment of the updated EARs and components.  If the error is still occurring, then restart your application server and perhaps even clean the application server temp files before restarting.  This should refresh all of the deployed services in the cache and the error should not occur.

reference: (182876692)

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

LiveCycle ES: how to uninstall a patch or service pack

Issue

If you have installed a patch or service pack for LiveCycle ES you may need to uninstall this at a later date, or you may have a requirement to document this process fully as part of your installation/configuration documentation.

This information is outlined in the readme file provided with each patch or service pack, and I will just expand on that giving some more detail here.  In this example I will discuss uninstalling LiveCycle ES Update 1 SP4 (8.2.1.4), to go back to LiveCycle ES Update 1 SP3 (8.2.1.3) on Windows.

Preparation

Before installing/uninstalling any patch you should take note of the current versions installed so you can verify your steps have been successful later.  Take a screenshot of the About screen, and the Service Management screen from the AdminUI.

AdminUI > About screen (note the Patch version “SP4″ and Service Pack version “8.1.5192.1.284202.47″, and the Patch level of each deployed component “SP4″):

AdminUI > Services > Applications and Services > Service Management screen (note the Component Versions “8.1.5192.1.284202.47″, “8.1.5193.1.279333.70″, etc…):

Before running through the uninstallation process it would advisable to make a backup of your existing configuration in case any unexpected problems should arise.  To do this, you should make a copy of the entire LiveCycle installation directory (excluding the MySQL folder if it exists within the LiveCycle directory).

You should also take note of the following configuration properties from AdminUI > Settings > Core System Settings > Configurations:

  • Location of temp directory
  • Global document storage root directory (Changing this value will result in data loss unless you also manually move the data)
  • Location of the Adobe Server Fonts directory
  • Location of the System Fonts directory

If you have LiveCycle Content Services ES installed, you should also have the location of the Content Services root directory which you entered during the original installation/configuration process.

Uninstallation

1. It is possible to leave your application server running for the moment, however you should stop your application server (JBoss, WebSphere, Weblogic) if possible.

2. Delete any files listed in <LiveCycle_HOME>\patch\SP4\backup_SP4\FilesAddedDuringServicePack_RemoveOrReplaceToRevert.txt from the <LiveCycle_HOME> directory.  These are new/updated files which were added with this service pack/patch.  To go back to a pre-SP4 state, we need to remove these files.

3. Copy all files under <LiveCycle_HOME>\patch\SP4\backup_SP4\ and paste them into their corresponding folder under the <LiveCycle_HOME> directory.  This will overwrite the files which were updated by SP4 and restore them back to the SP3 state.  This can include files in the configurationManager, deploy, LiveCycle_ES_SDK, and jboss folders.

4. Goto <LiveCycle_HOME>\licenses and edit each of the xxx.properties files.  You will have a .properties file for each component installed, so you will need to perform the 2 steps below for each .properties file.

i). Delete the last PatchID section from the bottom of each file (in this case the entire SP4 section highlighted):

ii). Change the PatchVersion value at the top of the file to match the last PatchID now at the bottom (in this case SP3, as we just deleted SP4):

5. As we have now restored all the files in the <LiveCycle_HOME> directory, and have a backup of the SP4 configuration, we can now delete the EAR files in the <LiveCycle_HOME>\configurationManager\export directory.

6. Run Configuration Manager (LCM) and select the LC components you wish to configure.

7. Select the following tasks on the task selection dialog:

  • Configure LiveCycle ES
  • Deploy LiveCycle ES EARs (optional, you can also deploy the EARs manually once they are configured in the export folder, before initializing the DB)
  • Initialize LiveCycle ES database
  • Deploy LiveCycle ES components
  • Validate LiveCycle ES component deployment

8. Follow all the dialogs and check the values of the local folders which you noted in the preparation tasks.

9. Once LCM has successfully completed deploying the EARs and components, you should check the version numbers again in the AdminUI to ensure they now show the original version numbers (in this case SP3).

AdminUI > About screen:

AdminUI > Services > Applications and Services > Service Management screen:

Note: if you see NoSuchMethodErrors in the server log, this would indicate that the DSC components do not match the version of the EARs deployed (e.g. the components are still SP4, whereas the EARs are SP3 or vice versa).  Ensure you have successfully completed the EAR and component deployment, and you may need to restart your application server and perhaps even clean the application server temp folders to resolve such exceptions that appear in the server log.

reference: (182873522)

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

LiveCycle ES2: ALC-LCM-030-300 Error while deploying LCA

Issue

If you are running LiveCycle Configuration Manager (LCM) and deploying the components to a WebSphere server you may receive an error when it attempts to deploy the LCAs.  If you check in the lcm.0.log you may see the following exceptions:

SEVERE, Thread-18, com.adobe.livecycle.lcm.feature.deployment.DeployLCAs,
 Error while deploying LCA /opt/adobe/adobe_livecycle_es2/deploy/adobe-livecycle-launchpad.lca.
 com.adobe.livecycle.lcm.core.LCMException[ALC-LCM-030-300]:
 Error while deploying LCA /opt/adobe/adobe_livecycle_es2/deploy/adobe-livecycle-launchpad.lca.
 at com.adobe.livecycle.lcm.feature.deployment.DeployLCAs.deployLCAFile(DeployLCAs.java:261)
 at com.adobe.livecycle.lcm.feature.deployment.DeployLCAs.deployLCAFiles(DeployLCAs.java:177)
 at com.adobe.livecycle.lcm.feature.deployment.DeployLCAs.deployLCA(DeployLCAs.java:146)
 at com.adobe.livecycle.lcm.feature.deployment.DeployDSCsTask$ActualTask.<init>(DeployDSCsTask.java:99)
 ...
 Caused by: ALC-DSC-005-000: com.adobe.idp.dsc.DSCNotSerializableException: Not serializable
 ...
 Caused by: ALC-DSC-003-000: com.adobe.idp.dsc.DSCInvocationException: Invocation error.
 ...
 Caused by: com.adobe.livecycle.design.client.DesigntimeServiceException: Error Removing the application :Invocation error.
 ...
SEVERE, Thread-18, com.adobe.livecycle.lcm.feature.deployment.DeployLCAs,
 Error while deploying LCA /opt/adobe/adobe_livecycle_es2/deploy/adobe-process-management-system.lca.
 ...
SEVERE, Thread-18, com.adobe.livecycle.lcm.feature.deployment.DeployLCAs,
 Error while deploying LCA /opt/adobe/adobe_livecycle_es2/deploy/adobe-guides.lca.
 ...
SEVERE, Thread-18, com.adobe.livecycle.lcm.feature.deployment.DeployLCAs,
 Error while deploying LCA /opt/adobe/adobe_livecycle_es2/deploy/adobe-mobile.lca.
 ...
SEVERE, Thread-18, com.adobe.livecycle.lcm.feature.deployment.DeployDSCsTask, Task failed

Reason

These errors can occur when the LiveCycle EAR files have not been deployed correctly to WebSphere.  If you have deployed the EAR files manually after they have been configured in LCM, then you have forgotten to enable the “Generate Default Bindings” option while deploying the EAR files.

Solution

When you deploy each EAR file ensure you select the option to “Generate Default Bindings” in the WebSphere console:

This is described in the documentation also for manually deploying the EAR files to WebSphere:

http://help.adobe.com/en_US/livecycle/9.0/install_websphere.pdf#page=123

reference: (182816166)

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

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 ES2: repeated ServiceNotFoundException in the server log

Description

 If you are running LiveCycle ES2 you may notice the following exception message in the server log:

2011-04-20 18:03:54,291 INFO [com.adobe.idp.dsc.workmanager.impl.ExecutableUnitWrapper] No class loader found for service: Events. Cause: com.adobe.idp.dsc.registry.ServiceNotFoundException: Service: Events not found.

Explanation

 This message on its own is benign, i.e. it does not indicate a problem with the LiveCycle server, and can therefore be ignored.  It is an INFO level message, and not an ERROR or WARN level message which indicates the priority.

If the message does occur as an ERROR or WARN level message with other exceptions, then this should not be ignored and you should analyse the other exceptions to find the root cause of the issue.

Additional information

The work manager in LiveCycle was looking for a service called “Events” in order to get its class loader to serialize/de-serialize objects (ExecutableUnit) whose definition is in that service.  When it couldn’t find the class loader for the Events service, LiveCycle will continue to use the default class loader.

reference: (182264454/2853085)

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

LiveCycle ES: java.lang.OutOfMemoryError deploying DSC components in LCM

Issue

 If you are deploying the DSC components using the LiveCycle Configuration Manager (LCM) on WebSphere (particularly WAS7), you may receive an error that not all components were successfully deployed.  In the server log you may see the following error:

JVMDUMP006I Processing dump event “systhrow”, detail “java/lang/OutOfMemoryError” – please wait.

Reason

The default memory settings for the EJB Deploy tool in IBM WebSphere are not enough for deploying the LiveCycle components, and/or the EAR files.

Solution

To fix this issue, edit %WAS_HOME%\deploytool\itp\ejbdeploy.bat (or ejbdeploy.sh in UNIX). Change -Xms256M -Xmx256M to -Xms1024M -Xmx1024M.  Then re-run LCM.

Note:  There is no need to re-start the appserver instance.

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

LiveCycle ES: ALC-TTN-011-031: Bootstrapping failed for platform component [DocumentServiceContainer] | clustered environments

Issue

 If you are attempting a clustered installation of LiveCycle ES, you may experience errors during the bootstrapping phase of LiveCycle Configuration Manager (LCM) with the following exception in the LCM log:

[5/25/11 8:09:12:768 EDT] 0000003f DSCBootstrapp E com.adobe.livecycle.bootstrap.bootstrappers.AbstractBoostrapper log ALC-TTN-011-031: 
Bootstrapping failed for platform component [DocumentServiceContainer]. The wrapped exception's message reads: See nested exception; nested exception is: 
java.lang.Exception: java.lang.NoClassDefFoundError: com.adobe.livecycle.cache.adapter.GemfireCacheAdapter (initialization failure)

[5/25/11 8:09:12:768 EDT] 0000003f DSCBootstrapp E com.adobe.livecycle.bootstrap.bootstrappers.AbstractBoostrapper log TRAS0014I: 
The following exception was logged com.adobe.livecycle.bootstrap.BootstrapException: ALC-TTN-011-031: 
Bootstrapping failed for platform component [DocumentServiceContainer]. The wrapped exception's message reads: See nested exception; nested exception is: 
java.lang.Exception: java.lang.NoClassDefFoundError: com.adobe.livecycle.cache.adapter.GemfireCacheAdapter (initialization failure)
 at com.adobe.livecycle.bootstrap.bootstrappers.DSCBootstrapper.bootstrap(DSCBootstrapper.java:73)
 at com.adobe.livecycle.bootstrap.framework.ManualBootstrapInvoker.invoke(ManualBootstrapInvoker.java:78)
 at com.adobe.livecycle.bootstrap.framework.BootstrapServlet.doGet(BootstrapServlet.java:156)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)

LCM may also display error message dialogs such as the following:

Reason

In a clustered environment, the cluster caching must be configured correctly and working before the database initialization can complete successfully.

Solution

The cluster caching should be configured using one of the options below, depending on whether you are using UDP or TCP caching:
A) UDP caching uses the following Java argument to set a port number: -Dadobe.cache.multicast-port=<port number>
The multicast port must be unique to the LiveCycle ES cluster (that is, the port must not be used by any other cluster on the same network). It is recommended that you configure the same <port number> on all nodes in the LiveCycle ES cluster.

B) TCP caching uses the following Java argument: -Dadobe.cache.cluster-locators=<IPaddress>[<port number>],<IPaddress><port number>]
Configure, as a comma-separated list, the locators for all nodes of the cluster. The value for <IPaddress> is the IP address of the computer running the locator, and the value for <portnumber> is any unused port between 1 and 65535 (the port must not be used by any other cluster on the same network). It is recommended that you configure the same <port number> for all locators.

Troubleshooting

Here are some further troubleshooting tips for LCM errors related to the DB initialization step:

  • ensure the DB privileges for the DB user match what is specified in the installation documentation
  • ensure sure the user that is starting the application server has R/W access to the GDS and LC TEMP directories (Bootstrap will fail if the permissions are incorrect)
  • it may be necessary to drop the DB and re-create it if there was an error the first time
  • if using WebSphere, test the DB connection from the WAS admin console
VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 9.0/10 (1 vote cast)

LiveCycle ES: EventPolicyException on IDPSchedulerService during server startup

Issue

 If you are running LiveCycle ES (8.x) you may notice the following exceptions in the server log when you restart the application server:

[05.05.11 10:40:43:809 CEST] 00000084 ExceptionCont W Scheduling subscription evaluation resulted in error. 
Reason: There is no active service configuration for service: IDPSchedulerService
[05.05.11 10:40:43:809 CEST] 00000084 EventManagerI E Event Data storage failed. 
Reason: com.adobe.idp.event.policy.EventPolicyException: There is no active service configuration for service: IDPSchedulerService
.....
Caused by: ALC-DSC-023-000: com.adobe.idp.dsc.registry.service.NoActiveServiceConfigurationException: 
There is no active service configuration for service: IDPSchedulerService

The same kind of exception can also refer to other services like EncryptionService, OutputService and so on, depending on the services deployed and used on your installation.  Something has gone wrong during server startup and these services have not finished loading successfully.  There can be many different causes for such behaviour, i.e. the app.server was somehow busy handling other requests or under load during LiveCycle start.

Solution

 Restart the application server again, paying attention not to send any requests or calls to the server if possible.

Troubleshooting

If there are other applications deployed on the same application server as LiveCycle, then try to stop/remove those applications to identify which one may be interrupting the LiveCycle startup.

reference: (182305661)

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

LiveCycle ES: duplicate events being received on JBoss clustered installation

Issue

 If you are using a JBoss clustered installation of LiveCycle ES2 to handle batches of events, you may notice that some events are received twice, (i.e. 10 events thrown, 12 events received).

Solution

 This can occur if the JBoss cluster is not configured correctly.  In the cluster settings (i.e. run.bat for JBoss) it is important to give each node in the cluster a unique server name using the “Adobeidp.serverName” parameter.  For example, Adobeidp.serverName=server1 for the first node in the cluster, and Adobeidp.serverName=server2 for the second node and so on…

Additional information

 When you give the two servers in a cluster the same name, you wind up with a workmanager on each server that has the same name. Work items get assigned to a specific workmanager, but since they both have the same name it becomes a race to see which one picks up the work item first. In some specific timing cases both will pick up the work item at the same time and process it, which is the reason for the duplication of events.

reference: (182264450)

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

LiveCycle ES2: errors after updating to WebSphere 6.1 Fixpack 35 (6.1.0.35)

Issue

 If you are running LiveCycle ES2 on WebSphere and you update to WAS FP35 (6.1.0.35) you may notice some random errors in the server logs such as:

com.adobe.livecycle.docconverter.client.ValidationException: ALC-CVT-S00-003: Error while validating PDF/A conformance of a document: docConverter.pdf
 at com.adobe.livecycle.docconverter.DocConverterServiceImpl.isPDFA(DocConverterServiceImpl.java:463)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:618)
...
Caused by: com.adobe.internal.pdfm.pdfa.PDFAServiceException: PDFM_I27002: PDF/A Validation was unable to release document 
"{SharedPDFMDocHandle name=docConverter.pdf ID=270667810 getStore={SharedStore name=docConverter.pdf ID=637281788 (faux clone of 1810918384) 
idp=<document state="passive" senderVersion="3" persistent="false" senderPersistent="false" passivated="true" senderPassivated="false" deserialized="true" 
senderHostId="127.0.0.1/4.241.117.208/4.241.117.207/4.241.117.214/4.241.117.234/4.241.117.233/4.241.117.232/4.241.117.236/4.241.117.227/4.241.117.226/
4.241.117.210/4.241.117.216/4.241.117.209/4.241.117.215/4.241.117.218/172.16.252.148/4.239.195.28/4.100.183.28" callbackId="0" senderCallbackId="16" 
callbackRef="com.adobe.idp._IDocumentCallbackStub:IOR:00bdbdbd0000002849444c3a636f6d2f61646f62652f6964702f49446f63756d656e7443616c6c6261636b3a312e30000000000
100000000000000c4000102bd000000194431303041455539313535382e443130302e696e7465726e00bd24550000002c4a4d42490000001071960b49000000000000000000000000000000000000
002400000008000000120000000000000007000000010000001400bdbdbd0501000100000000000101000000000049424d0a0000000800bd00011500000200000026000000020002bdbd49424d040
00000050005020102bdbdbd0000001f0000000400bd0003000000200000000400bd0001000000250000000400bd0003" isLocalizable="true" isTransactionBound="false" 
defaultDisposalTimeout="600" disposalTimeout="600" maxInlineSize="65536" defaultMaxInlineSize="65536" inlineSize="0" contentType="null" length="95543">
<cacheId/><localBackendId><DocumentFileID fileName="/usd/as91558a/work/was-v61/apps/jvmdms.a.1/temp/AdobeDocumentStorage/local/docm1302791768337/1925ec208e7deba285534660215ae481"/>
<localBackendId/><globalBackendId><DocumentFileID fileName="/usd/as91558a/work/was-v61/apps/jvmdms.a.1/native/adobe/jvmdms.a.1.as91558.1/DocumentStorage/docm1302792793931/d570dc3cf31fc6f368d4ee043ede67d5"/>
<globalBackendId/><senderLocalBackendId/><senderGlobalBackendId/><inline/><senderPullServantJndiName>adobe/idp/DocumentPullServant/adobews__957269328</senderPullServantJndiName>
<attributes/></document> pdfDoc=null sharedData=null} getPdfDoc=null getCounted=null refCount=0}".
    at com.adobe.internal.pdfm.pdfa.PDFAService.isPDFA(PDFAService.java:273)
    at com.adobe.internal.pdfm.pdfa.PDFAService.isPDFA(PDFAService.java:193)
    at com.adobe.livecycle.docconverter.DocConverterServiceImpl.isPDFA(DocConverterServiceImpl.java:461)
... 71 more
Caused by: com.adobe.internal.pdfm.NotAPDFException: PDFM_S00025: Document docConverter.pdf of type application/octet-stream is not a PDF.
    at com.adobe.livecycle.assembler.SharedPDFMDocHandle.open(SharedPDFMDocHandle.java:232)
    at com.adobe.internal.pdfm.PDFMDocHandle.acquire(PDFMDocHandle.java:608)
    at com.adobe.internal.pdfm.PDFMDocHandle.acquirePDF(PDFMDocHandle.java:662)
    at com.adobe.internal.pdfm.pdfa.PDFAService.isPDFA(PDFAService.java:217)
... 73 more

The errors that occur depend on what kind of processes and activities you are running in the LiveCycle server, so they could be very different to the above.  The cause of these errors is the WebSphere version and changes that were made to the JDK used by WebSphere.  With WAS FP35 (and probably FP33 and 37) the default behaviour of IgnoreMalformedInput has been set to false, resulting in this change in behaviour for the String constructor in the JDK, causing these issues in LiveCycle.

Solution

 Contact IBM to ensure you have the latest fixes which should contain the solution to this problem as outlined below.  The latest fixes should reset the default behaviour of IgnoreMalformedInput=true.

As an immediate workaround you can manually set the JVM parameter “-Dcom.ibm.IgnoreMalformedInput=true” in your WebSphere administration console.

Additional information

 Information from IBM related to the changes that cause this behaviour and the relevant workaround and fixes:

String constructor does not operate correctly with UTF-16 in Java SR12 FP1

This is a known issue and we had to make changes because of the behavior difference between IBM and OracleJVMs.  The change was to enable conformity with the Oracle JDK for malformed URLs.  To revert back to the original behavior you must add the following  parameter to the “Generic JVM Args” section in the WAS Admin console (instructions in the link below):

-Dcom.ibm.IgnoreMalformedInput=true

Where to set generic JVM arguments in WebSphere Application Server: http://www.ibm.com/support/docview.wss?rs=180&uid=swg21417365

For more details  on the issue please refer to the APAR- IZ80870  (link below).

IZ80870: REPLACING THE ILLEGAL UTF8 BYTE SEQUENCES WITH \UFFFD: http://www-01.ibm.com/support/docview.wss?uid=swg1IZ80870

Please note, this change went into SR 12 FP1, which is why the same behavior does not occur in the previous SDK releases.  Here is the SDK fix list confirming the above APAR went into SR 12 FP1:

http://www.ibm.com/developerworks/java/jdk/aix/j532/fixes.html#SR12FP1

reference: (182181050/2838202)

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