Allgemeine Fehlermeldungen

Es gibt viele verschiedene Thread-Typen, die jedoch grundsätzlich in zwei Kategorien unterteilt werden können: Java-Threads und native Threads. Alle in einer JVM ausgeführten Threads sind Java-Threads (Klasse java.lang.Thread innerhalb von Java). Der native Code (C++/C) erzeugt native Threads, die vom Betriebssystem geplant und verwaltet werden. Dies sind die Hauptunterschiede zwischen den beiden Typen:

• Java-Threads werden entweder vom LiveCycle-Code, vom Anwendungsserver oder von der JVM selbst erstellt und verwaltet.

• Betriebssystemtools (wie Systemmonitor oder Task-Manager) verfügen nur über Informationen zu nativen Threads.

Da das Betriebssystem Java-Threads nicht transparent machen kann, überwachen Sie beim Überwachen von Threads mit Betriebssystemtools wie Systemmonitor ausschließlich native Threads. Die einzige Möglichkeit, Details zu Java-Threads zu erfahren, ist das Ausführen eines Java-Thread-Dumps. Das Verfahren zum Ausgeben eines Java-Thread-Dumps hängt vom Anwendungsserver und der JVM ab. Informationen hierzu finden Sie in der Dokumentation des Herstellers.

Die Implementierung der JVM erfolgt in C/C++-Code und dieser JVM-Code ordnet Java-Threads nativen Threads zu. Die Zuordnung kann entweder 1:1 (1 Java-Thread zu 1 nativen Thread) oder n:1 (mehrere Java-Threads zu 1 nativen Thread) sein. Die Einzelheiten zur Funktionsweise dieser Zuordnung sind JVM-herstellerspezifisch, doch die 1:1-Zuordnung ist meist die Standardeinstellung. Dies bedeutet, dass jeder Java-Thread über einen entsprechenden nativen Thread verfügt. Die Anzahl der Java-Threads ist jedoch nicht begrenzt. Da aber die 1:1-Zuordnung die Regel ist und die Anzahl der nativen Threads begrenzt ist, stehen ggf. auch zu wenig Java-Threads zur Verfügung. Diese Begrenzung gilt pro Prozess (die JVM ist auch ein einzelner Prozess) und variiert je nach Betriebssystem. Sie können davon ausgehen, dass die Begrenzung sich im Tausenderbereich, aber unter 10.000 bewegt. Unabhängig von diesem Wert können mehrere Hundert Threads ein Leistungsproblem darstellen, da das Betriebssystem diese hohe Anzahl von Threads einplanen muss.

Ein weiteres gängiges Problem bei Threads ist die Arbeitsspeicherzuordnung. Wird ein neuer Java-Thread zugewiesen, ist für dessen Stapel eine feste Menge an Arbeitsspeicher erforderlich. Dieser Thread-Stapelspeicher ist ein Parameter (Option -Xss für die Sun™-JVM), dessen Standardeinstellung „~512 KB“ beträgt. Bei 1000 Threads sind dann allein für die Stapel des Threads 500 MB Arbeitsspeicher erforderlich. Dieser Arbeitsspeicher steht dann in Konkurrenz zu allen anderen Arbeitsspeicherzuordnungen, die in der JVM erfolgen, z. B. mit den Zuordnungen von LiveCycle , wodurch es zu Problemen bei der Zuordnung von Arbeitsspeicher kommt.

Wenn die JVM in der Praxis keinen Arbeitsspeicher zuordnen oder keine Threads erzeugen kann, wird an die aufrufende Funktion eine Ausnahme vom Typ Zu wenig Arbeitsspeicher zurückgegeben. Zusammen mit dieser Ausnahme werden eine Stapelablaufverfolgung und ein Grund für die Auslösung der Ausnahme zurückgegeben. Dieser Grund muss unbedingt beachtet werden, da er weitere Hinweise auf die mögliche Fehlerursache bietet.

Der folgende Code ist ein Beispiel für eine Meldung mit zwei Fehlern und den dazugehörigen Fehlercodes:

"unable to create new native thread: java.lang.OutOfMemoryError: unable to create new native thread java.lang.OutOfMemoryError: Java heap space"

Diese Fehler bedeuten, dass die JVM aus einem der folgenden Gründe keine weiteren Threads erzeugen konnte:

• Der prozessbezogene Thread-Grenzwert wurde erreicht.

• Der Thread-Stapel kann nicht zugeordnet werden.

Um die exakte Ursache zu bestimmen, müssen Sie einen Thread-Dump (auch Java-Dump genannt) durchführen. Ein Thread-Dump wird in der Regel in der Datei javacore.xxxx.txt in den Protokollverzeichnissen des Anwendungsservers abgelegt. Der Thread-Dump enthält sehr viele Informationen, doch Sie können die Anzahl der Threads rasch bestimmen, indem Sie die Vorkommen des Tokens TID: in der Liste zählen. Ein typischer Eintrag sieht so aus:

"Thread-1227" (TID:0x106948F0, sys_thread_t:0x78996DA0, state:R, native ID:0x191C) prio=5 
4XESTACKTRACE at java.net.SocketInputStream.socketRead0(Native Method) 
4XESTACKTRACE at java.net.SocketInputStream.read(SocketInputStream.java(Compiled Code)) 
4XESTACKTRACE at java.io.BufferedInputStream.fill(BufferedInputStream.java(Compiled Code)) 
4XESTACKTRACE at java.io.BufferedInputStream.read1(BufferedInputStream.java(Compiled Code)) 
4XESTACKTRACE at java.io.BufferedInputStream.read(BufferedInputStream.java(Compiled Code)) 
4XESTACKTRACE at com.sun.jndi.ldap.Connection.run(Connection.java(Compiled Code)) 
4XESTACKTRACE at java.lang.Thread.run(Thread.java:567)

Wenn Tausende von Threads vorhanden sind, gehen die Threads wahrscheinlich zur Neige. Entwickler können die offensichtlichen Ursachen ermitteln, indem die Stapelablaufverfolgungen dieser Threads untersucht werden.

Sind mehrere Hundert Threads vorhanden, ist der Grund für die Fehlermeldung java.lang.OutOfMemory nicht das Thread-Limit. Verkleinern Sie den Thread-Stapel (siehe die oben genannte Option -Xss), starten Sie LiveCycle erneut und prüfen Sie, ob das Problem behoben wurde.

Content Services (nicht mehr unterstützt) bietet verschiedene speicherinterne Caches, die die Leistung wesentlich verbessern, jedoch auch sehr viel Java-Heap-Speicher belegen. Es treten ggf. OutOfMemory-Ausnahmefehler auf, wenn Sie den Dokument Management-Dienst für Content Services auf Hardware ausführen, die nur die Mindestanforderungen an die Hardware erfüllt.

Sie können die Speicherbelegung steuern, indem Sie die JVM-Argumente -Dhibernate.cache.use_second_level_cache=false und -Dhibernate.cache.use_query_cache=false festlegen.

1. Überprüfen Sie die JNDI-Struktur auf dem LiveCycle-Anwendungsserver. Wird der verwendete Name in der Struktur angezeigt?

   • Wenn dies der Fall ist, konnte der Code höchstwahrscheinlich das InitialContext-Objekt, das für die Suche verwendet wurde, nicht ordnungsgemäß einrichten. Die Suche erfolgt dann in einer JNDI-Struktur, bei der es sich nicht um diejenige handelt, in der die Ressource aufgeführt ist. Informationen über die zu verwendenden Eigenschaftswerte finden Sie im Dokument Installieren und Bereitstellen von LiveCycle für Ihren Anwendungsserver.

   • Falls nein, fahren Sie mit Schritt 2 fort.

2. Wird die Ressource in der JNDI-Struktur unter einem anderen Namen als dem in der Suche angegebenen Namen aufgeführt?

   • Falls ja, verwenden Sie den falschen Suchnamen. Geben Sie den ordnungsgemäßen Namen an.

   • Falls nein, fahren Sie mit Schritt 3 fort.

3. Überprüfen Sie beim Systemstart die Protokolle des Anwendungsservers. Wenn der Anwendungsserver so konfiguriert wurde, dass diese Ressource verfügbar sein soll, aber ein Fehler auftritt, wird an dieser Stelle eine Ausnahme angezeigt. Liegt eine Ausnahme vor?

   • Falls ja, überprüfen Sie die Ausnahme und die Stapelablaufverfolgung. Wenn eine Ausnahme vom Typ NameNotFoundException (Name nicht gefunden) im Rahmen Ihrer Untersuchung der Serverprotokolle ein Symptom eines anderen Problems ist, wechseln Sie zu den Fehlerbehebungsschritten für dieses Problem.

   • Falls nein, fahren Sie mit Schritt 4 fort.

4. Wenn die Ressource nicht in der JNDI-Struktur aufgeführt ist und beim Start keine Ausnahme angezeigt wird, die erklärt, warum diese nicht zur Verfügung steht, ist der wahrscheinlichste Grund, dass der Anwendungsserver nicht ordnungsgemäß für die Bereitstellung dieser Ressource konfiguriert wurde. Prüfen Sie die Konfiguration des Anwendungsservers. Wurde er für die Bereitstellung dieser Ressource konfiguriert?

   • Falls nicht, finden Sie weitere Informationen dazu im Handbuch Installieren und Bereitstellen von LiveCycle für Ihren Anwendungsserver.

   • Falls ja, handelt es sich nicht um eines der gängigen Probleme, die als Ursache dieses Fehlers gelten. Wenden Sie sich an den Adobe Enterprise-Support.

(Bekanntes Problem) Wenn in Ihrer LiveCycle für JBoss-Installation ECM Connector für EMC Documentum enthalten ist, wird die folgende Fehlermeldung in den Serverprotokollen bei jedem Neustart des Servers angezeigt:

An org.jboss.logging.appender.FileAppender object is not assignable to an org.apache.log4j.Appender variable

Um zu verhindern, dass unnötige FEHLER- und WARNUNG-Protokollmeldungen von IBM FileNet erzeugt und in der Protokolldatei von JBoss Application Server angezeigt werden, nehmen Sie folgende Änderung an der Datei „log4j.xml“ vor, die sich im Ordner „[JBoss-Stammordner]/server/all/conf“ befindet.

1. Suchen Sie die Datei log4j.xml und öffnen Sie sie in einem Editor.

2. Fügen Sie im Abschnitt [Category] den folgenden Text hinzu:

        <category name="com.filenet"> 
            <priority value="FATAL"/> 
        </category>

1. Speichern und schließen Sie die Datei.

2. Starten Sie den Anwendungsserver neu.

Wenn folgende Fehlermeldung ausgegeben wird, liegt ein WebLogic-Zeitlimitfehler vor:

<Warning> <com.adobe.workflow.AWS> <ap-sun4> <Server_127> <[ACTIVE] ExecuteThread: '17' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-58E59A31956BB0D8F0AB> <> <1178316054656> <000000> <javax.ejb.TransactionRolledbackLocalException: EJB Exception: ; nested exception is: javax.ejb.TransactionRolledbackLocalException: EJB Exception: ; nested exception is: weblogic.transaction.internal.TimedOutException: Transaction timed out after 299 seconds 

Um diesen Fehler zu beheben, legen Sie für den WebLogic-JTA-Zeitlimitwert einen höheren Wert als 300 Sekunden fest. (Lesen Sie im Dokument Vorbereiten der LiveCycle-Installation „Das WebLogic Transaktionszeitlimit konfigurieren“.

Wenn folgende Fehlermeldung ausgegeben wird, liegt ein WebLogic-EAR-Bereitstellungsfehler vor:

    Could not start application adobe-livecycle-weblogic. 
    com.adobe.livecycle.cdv.CDVException[ALC-LCM-030-113]: Failed to deploy EAR.

Stellen Sie zum Beheben dieses Fehlers in der WebLogic Server-Verwaltungskonsole sicher, dass diese nicht gesperrt ist, d. h. die Schaltfläche „Lock & Edit“ ist nicht ausgewählt. Ist sie gesperrt, zeigt Configuration Manager an, dass der Bereitstellungsprozess zu 16 % abgeschlossen ist, und in WebLogic Server Administration Console wird die EAR-Datei als bereitgestellt, jedoch mit einem installierten Status angezeigt. Ist WebLogic Server Administration Console nicht gesperrt, kann Configuration Manager die EAR-Dateien bereitstellen.

Um dieses Problem zu beheben, stellen Sie sicher, dass die WebLogic Server-Verwaltungskonsole nicht gesperrt ist, und stellen Sie die EAR-Dateien erneut bereit.

Wenn folgende Fehlermeldung ausgegeben wird, liegt ein WebLogic-EAR-Bereitstellungsfehler (Solaris) vor:

    java.lang.OutOfMemoryError: PermGen space

Um diesen Fehler zu beheben, erhöhen Sie den MaxPermSize von 256 auf 512. Sie können diesen Wert über die WebLogic Server Administration Console ändern.

besteht das bekannte Problem, dass bei der Ausführung von WebLogic Server unter Windows Lösungskomponenten von LiveCycle ES nicht bereitgestellt werden, da die Zeitlimiteinstellung von 5 Sekunden zu kurz ist. Sie müssen diese Einstellungen folgendermaßen manuell konfigurieren:

• Wechseln Sie zu [Anwendungsserver-Domäne] und öffnen Sie die Datei „startWeblogic.cmd“ in einem Editor.

• Fügen Sie folgenden Parameter hinzu:

        -Dweblogic.client.socket.ConnectTimeout = <timeout value>

Wenn der LiveCycle-Prozess einen E-Mail-Endpunkt verwendet, erhalten Sie beim Aufrufen des E-Mail-Endpunkts möglicherweise eine ähnliche Fehlermeldung wie die folgende.

SECJ0305I: The role-based authorization check failed for naming-authz operation NameServer:bind_java_object. The user UNAUTHENTICATED (unique ID: unauthenticated) was not granted any of the following required roles: CosNamingCreate, CosNamingDelete, CosNamingWrite.

Diese Fehlermeldung tritt aufgrund von fehlenden Berechtigungen für die CORBA Naming Service Groups in WebSphere auf.

Führen Sie zur Behebung dieses Problems folgende Schritte durch:

1. Wählen Sie in WebSphere Administration Console Environment > Naming > CORBA Naming service groups.

2. Fügen Sie die folgenden Berechtigungen hinzu:

   • Cos Naming Write

   • Cos Naming Delete

   • Cos Naming Create

3. Starten Sie den WebSphere-Anwendungsserver erneut.

Bei einer WebSphere-Cluster-Bereitstellung werden möglicherweise mehrere Einträge von Fehlerprotokollen ähnlich dem Folgenden angezeigt:

org.hibernate.event.def.AbstractFlushingEventListener performExecutions Could not synchronize database state with session 
org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.alfresco.repo.domain.hibernate.NodeImpl#10] 
at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1769)at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2412) 
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2312) 
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2612)

Diese Protokolle wirken sich nicht auf die Funktionalität aus. Um diese Protokolle zu unterdrücken, müssen Sie mithilfe von WebSphere Administration Console die Protokollierungsstufen ändern. Ändern der Protokollierungsstufen

1. Melden Sie sich bei der WebSphere Administrative Console an.

2. Klicken Sie auf Troubleshooting > Logs and Trace.

3. Klicken Sie im rechten Fenster auf den Namen des Anwendungsservers.

4. Klicken Sie auf Change Log Detail Levels.

5. Erweitern Sie in der Konfigurationsregisterkarte den Eintrag All components > org.hibernate.event.* > org.hibernate.event.def.*.

6. Klicken Sie auf org.hibernate.event.def.AbstractFlushingEventListener. Ein Popupmenü wird angezeigt.

7. Klicken Sie im Popupmenü auf Message and Trace Levels > Fatal.

8. Klicken Sie auf OK und dann auf „Save directly to the master configuration“.

In diesem Abschnitt wird erläutert, wie Sie eine fehlgeschlagene Bereitstellung korrigieren, wenn bei der Bereitstellung der Datei „adobe-livecycle-websphere.ear“ die folgende Fehlermeldung angezeigt wird:

Could not deploy adobe-livecycle-websphere.ear. com.adobe.livecycle.cdv.CDVException[ALC-LCM-030-112]: Failed to deploy EAR. Could not deploy adobe-livecycle-websphere.ear.

Sie können die WebSphere-Protokollierungsstufe ändern, um Warnmeldungen in der Datei „SystemOut.log“ zu vermeiden, die mit der nicht mehr verwendeten direkten JNDI-Lookup zusammenhängen.

Um die Warnmeldung J2CA0294W in „SystemOut.log“ zu unterdrücken, ändern Sie die Protokollierungsstufe in *=info:com.ibm.ejs.j2c.ConnectionFactoryBuilderImpl=severe.

Wenn Sie vermeiden möchten, dass bei der WebSphere-Installation mehrere unnötige Protokollnachrichten aufgenommen werden, können Sie die Protokollierungsstufe auf „Warnung“ erhöhen, damit Meldungen mit niedrigerer Stufe nicht protokolliert werden.

1. Melden Sie sich über „http://[Hostname]:9060/admin“ bei der Verwaltungskonsole von Websphere an.

2. Klicken Sie in der Navigationsstruktur auf Troubleshooting und klicken Sie anschließend auf Logs and Trace.

3. Klicken Sie im rechten Fenster auf den Namen des Anwendungsservers und anschließend auf Change Log Detail Levels.

4. Wählen Sie Runtime und geben Sie org.apache.xml.security.* ein.

5. Klicken Sie auf Message And Trace Levels und anschließend auf Warning.

6. Aktivieren Sie das Kontrollkästchen Save runtime changes to configuration.

7. Klicken Sie auf OK.

Ihr WebSphere-Anwendungsserver meldet möglicherweise Ausnahmen, die den nachfolgend beschriebenen Ausnahmemeldungen ähneln.

         Could not connect to Inbox. Error message: com.ibm.jsse2.util.h: 
            No trusted certificate found; nested exception is: 
                javax.net.ssl.SSLHandshakeException: 
        com.ibm.jsse2.util.h: No trusted certificate found

        [5/28/08 13:15:30:283 CDT] 00000025 SystemOut     O 
        CWPKI0022E: SSL HANDSHAKE FAILURE:  A signer with SubjectDN 
        "CN=imap.gmail.com, O=Google Inc, L=Mountain View, ST=California, C=US" 
        was sent from target host:port "null:null". The signer may need to be 
        added to local trust store "D:/servers/websphere6.1/profiles/AppSrv01 
        /config/cells/MN-TOBIKONode01Cell/nodes/MN-TOBIKONode01/trust.p12" 
        located in SSL configuration alias "NodeDefaultSSLSettings" loaded from 
        SSL configuration file "security.xml".  The extended error message from 
        the SSL handshake exception is: "No trusted certificate found". 
        [5/28/08 13:15:30:283 CDT] 00000025 SystemOut     O  
        [5/28/08 13:15:30:283 CDT] 00000025 ExceptionUtil E    
        CNTR0020E: EJB threw an unexpected (non-declared) exception during 
        invocation of method "doSupports" on bean "BeanId(adobe-core-websphere 
        #adobe-dscf.jar#EjbTransactionCMTAdapter, null)". Exception data: 
        java.lang.RuntimeException: Could not connect to Inbox. Error message: 
        com.ibm.jsse2.util.h: No trusted certificate found; 
            nested exception is: 
                javax.net.ssl.SSLHandshakeException:  
        com.ibm.jsse2.util.h: No trusted certificate found

Beim Bootstrapping von User Manager-Komponenten für den WebSphere-Anwendungsserver wird nach dem Start der Anwendung die folgende Ausnahmefehlermeldung nur einmal angezeigt:

00000043 javaURLContex E   NMSV0310E: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component. This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. Exception stack trace: 
javax.naming.ConfigurationException [Root exception is javax.naming.NameNotFoundException: Name comp/env/ejb not found in context "java:".]

Sie können diesen Fehler einfach ignorieren.

Wenn ein DSC aus einer Transaktion heraus aufgerufen wird, die von einer anderen Anwendung gestartet wurde und auf derselben Instanz von WebSphere bereitgestellt wurde wie LiveCycle , schlägt der DSC-Aufruf mit der folgenden Fehlermeldung fehl:

LocalException E   CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method "getObjectType" on bean

Dieser Fehler tritt unter WebSphere nur dann auf, wenn die Datei adobe-utilities.jar verwendet wird und es sich bei Platform.UTIL.getTransactionManager() um den Benutzer handelt, der den Transaktionsmanager startet.

Dieses Problem lässt sich beheben, wenn Sie die Datei adobe-utilities.jar nicht zum Starten des Transaktionsmanagers verwenden. Verwenden Sie stattdessen den folgenden Code zum Erstellen von UserTransaction:

InitialContext initialContext = new InitialContext(); 
UserTransaction ut = (UserTransaction)initialContext.lookup("java:comp/UserTransaction"); 
ut.begin();