Tipps zur Fehlerbehebung
Tipps zur Fehlerbehebung in Liberty.
Zur Unterstützung beim Ermitteln und Beheben von Fehlern stellt das Produkt eine einheitliche Protokollierungskomponente bereit. Nähere Informationen hierzu finden Sie unter Protokollierung und Traceerstellung. Sie können auch das Befehlstool IBM® Support Assistant Data Collector (ISADC) im Verzeichnis ${wlp.install.dir}/bin verwenden, um Diagnosedateien wie Protokolldateien und Konfigurationsdateien schnell zu erfassen und Traces auszuführen.
Wenn Sie eine Ausnahmenachricht empfangen, finden Sie unter Nachrichten Informationen zu dieser Nachricht.
Die ausführliche Java™-API-Dokumentation für jede Liberty-API finden Sie im Abschnitt Programmierschnittstellen (APIs) im online verfügbaren IBM Knowledge Center und darüber hinaus als separate .zip-Datei in einem der Javadoc-Unterverzeichnisse des Verzeichnisses ${wlp.install.dir}/dev.

Einzelheiten zu den bekannten Einschränkungen, die
bei der Verwendung von Liberty gelten, finden Sie unter Bekannte Probleme und Einschränkungen für die Laufzeitumgebung.
- Fehlerbehebung für JDKs
- Fehlerbehebung für die Sicherheit
- Fehlerbehebung für LDAP
- Fehlerbehebung für SSL
- Fehlerbehebung für CORBA/IIOP
- Fehlerbehebung für die Protokollierung und Traceerstellung
Fixpacks und vorläufige Fixes auf eine Archivinstallation anwenden
- Fehlerbehebung für die Leistung
- Fehlerbehebung für Verbünde
- Fehlerbehebung für SAML
- Fehlerbehebung für die REST-API-Erkennung
Prüfen Sie, ob die JDKs eine unterstützte Version haben
Wenn Fehler auftreten, für die keine einfache Erklärung zu finden ist, prüfen Sie, ob die JDKs, die Sie verwenden, mit Java Version 7 oder höher kompatibel sind und einen aktuellen Service-Level haben. Nähere Informationen hierzu finden Sie unter Unterstützte Java-Mindestversionen.
Fehlerbehebung für die Sicherheit
In diesem Abschnitt werden einige häufige Sicherheitsprobleme und auswählbare Lösungen beschrieben.
- SESN0008E: Ein als anonym authentifizierter Benutzer hat versucht, auf eine Sitzung zuzugreifen, deren Eigner user:LdapRegistry/cn=steven,o=myCompany,c=US ist.
- Dieser Fehler tritt auf, wenn ein nicht authentifizierter Benutzer versucht, auf eine von einem authentifizierten Benutzer erstellte Sitzung zuzugreifen. Die Sitzungssicherheit, die standardmäßig aktiviert ist, verhindert den unbefugten Zugriff auf die Sitzungen. Nur der Benutzer, der eine Sitzung erstellt hat, kann auf die Sitzung zugreifen. Weitere Informationen finden Sie unter session security.
Dieser Fehler kann auftreten, wenn Sie eine JSP (z. B. login.jsp) für Ihre formularbasierte Anmeldung verwenden und das vom Browser gesendete SSO-Token abgelaufen ist. Da das SSO-Token abgelaufen ist, wird der Benutzer aufgefordert, die Anmeldung über die Seite login.jsp, die für die formularbasierte Anmeldung konfiguriert ist, zu wiederholen. Die JSP-Seite versucht standardmäßig, eine Sitzung abzurufen. Diese Sitzung wurde ursprünglich von dem Benutzer erstellt, dessen Token abgelaufen ist. Da das Token ist abgelaufen und der Benutzer nicht authentifiziert ist, werden werden keine Berechtigungsnachweise beim Zugriff auf diese Sitzung bereitgestellt. Deshalb tritt dieser Fehler auf.
Sie können diesen Fehler vermeiden, indem Sie den Browser, der eine neue Sitzung startet, erneut starten oder die Datei login.jsp so konfigurieren, dass standardmäßig keine Sitzung erstellt wird. Wenn Sie sich für die Aktualisierung der Datei login.jsp entscheiden, legen Sie <%@ page session="false" %> fest.
- CWWKS9104A: Die Berechtigung für den Benutzer {0} ist beim Aufruf von {1} in {2} fehlgeschlagen. Dem Benutzer wurde kein Zugriff auf die erforderlichen Rollen erteilt: {3}.
- Dieser Fehler tritt auf, wenn Sie für die Rollen, die die Anwendung erfordert, nicht berechtigt sind. Stellen Sie sicher, dass der Benutzer oder die Gruppe, zu der der Benutzer gehört, mindestens einer der Rollen zugeordnet ist, die in der Fehlernachricht genannt sind. Eine Benutzer/Rolle-Zuordnung, die in der Datei ibm-application-bnd.xmi/xml definiert ist, hat Vorrang vor einer Zuordnung, die in der Datei server.xml definiert ist. Überprüfen Sie beide Ressourcen, um sicherzustellen, dass die korrekte Zuordnung definiert ist. Weitere Informationen hierzu finden Sie unter Berechtigung für Anwendungen in Liberty konfigurieren.
- CWWKS9104A: Die Berechtigung für den Benutzer {0} ist fehlgeschlagen.
- Dieser Fehler kann auftreten, wenn Sie application und webApplication für dasselbe Kontextstammverzeichnis angeben. Kommt es zu einem Konflikt, wird die neueste definierte Konfiguration ignoriert und dies führt zu einem unerwarteten Fehler, wie z. B. CWWKS9104A.
- Es ist nicht möglich, zwei Anwendungen mit dem Namen {0} zu starten. Die Folge sind ein nicht erwartetes Sicherheitsverhalten und Fehlernachrichten wie beispielsweise CWWKS9104A.
- Dieser Fehler tritt auf, wenn Sie Ihre Anwendung sowohl in der Datei server.xml mit dem Element application als auch im Ordner dropins angeben.
Deshalb wird versucht die Anwendung zweimal zu installieren
und die Sicherheitskonfiguration in der Datei server.xml
wird aktiv oder nicht. Entfernen Sie die Anwendung aus dem Ordner dropins
und kopieren Sie die Anwendung in ein anderes Verzeichnis,
um den Fehler zu beheben. Wenn Sie die Anwendung im Ordner dropins belassen,
müssen Sie die Anwendungsüberwachung inaktivieren, indem Sie Folgendes
in der Datei server.xml festlegen:
<applicationMonitor dropinsEnabled="false"/>
- Ein nicht authentifizierter Benutzer konnte auf mein Servlet oder meine JSP zugreifen
- Ein Benutzer mit dem Principal UNAUTHENTICATED (oder
der nicht authentifizierte SAF-Benutzer unter z/OS)
wird erstellt, wenn die Authentifizierung fehlschlägt oder wenn Ihr Servlet
oder Ihre JSP nicht geschützt ist. Ein nicht authentifizierter Benutzer kann auf Ihr Servlet oder Ihre JSP zugreifen,
wenn Sie keine Integritätsbedingungen für die Sicherheit definieren oder wenn Sie die für Ihre Anwendung erforderliche Rolle dem Sondersubjekt EVERYONE zuordnen. Überprüfen Sie
die Benutzer/Rolle-Zuordnungen in den Dateien ibm-application-bnd.xmi/xml und server.xml. Gehen Sie wie folgt vor:
- Wenn Ihr Servlet oder Ihre JSP nicht geschützt ist, fügen Sie dem Implementierungsdeskriptor Ihrer Anwendung Integritätsbedingungen für die Sicherheit hinzu. Nähere Informationen hierzu finden Sie unter Authentifizierung.
- Wenn Sie nicht möchten, dass nicht authentifizierte Benutzer auf Ihre Anwendung zugreifen, entfernen Sie das Sondersubjekt EVERYONE aus der Zuordnung für diese Rolle. Weitere Informationen hierzu finden Sie unter Berechtigung für Anwendungen in Liberty konfigurieren.
- Wenn ein bestimmter Benutzer nicht für Ihr Servlet oder Ihre JSP berechtigt werden kann, prüfen Sie, wer dieser Rolle zugeordnet ist, indem Sie die Dateien ibm-application-bnd.xmi/xml und server.xml untersuchen. Sie können eine Rolle einem Benutzer, einer Gruppe oder einem Sondersubjekt zuordnen. Wenn Ihre Rolle dem Sondersubjekt EVERYONE zugeordnet ist, wird jedem Benutzer der Zugriff gewährt. Wenn Ihre Rolle dem Sondersubjekt ALL_AUTHENTICATED zugeordnet ist, wird jedem authentifizierten Benutzer der Zugriff gewährt. Entfernen Sie diese Sondersubjekte, wenn Sie den Zugriff auf Ihr Servlet bzw. Ihre JSP weiter einschränken möchten. Prüfen Sie abschließend, zu welcher Gruppe der Benutzer gehört. Obwohl der Benutzer möglicherweise keinen expliziten Zugriff hat, ist seine Gruppe möglicherweise der Rolle zugeordnet. In diesem Fall entfernen Sie den Benutzer aus der berechtigten Gruppe oder die Gruppe aus der Rollenzuordnung. Weitere Informationen hierzu finden Sie unter Berechtigung für Anwendungen in Liberty konfigurieren.
- Single Sign-on (SSO) funktioniert nicht
- Wenn SSO nicht funktioniert, vergewissern Sie sich, dass die verschiedenen Liberty-Server, die dieselben LTPA-Schlüssel, dasselbe Kennwort und dasselbe ssoCookieName-Attribut des Elements webAppSecurity verwenden, auch dieselbe UTC-Zeit und dieselbe Benutzerregistry verwenden. Wenn das Token abgelaufen ist oder das Cookie über einen Web-Browser gesendet wird, nachdem die Benutzerregistry auf inkonsistente Weise geändert wurde (z. B. Änderung des Realms oder Entfernen des Benutzers, der vom Cookie dargestellt wird) schlägt SSO fehl und der Benutzer wird aufgefordert, die Berechtigungsnachweisinformationen erneut einzugeben. Weitere Informationen hierzu finden Sie unter SSO-Konfiguration mit LTPA-Cookies in Liberty anpassen.
- Debugging öffentlicher Sicherheits-APIs
- WSSecurityHelper und RegistryHelper werden geladen, selbst wenn die Sicherheit nicht aktiviert ist, z. B, wenn keine Sicherheitsfunktion (appSecurity-1.0, appSecurity-2.0 oder zosSecurity-1.0) angegeben ist. Wenn die Sicherheit nicht aktiviert ist, geben die Methoden WSSecurityHelper.isServerSecurityEnabled() und WSSecurityHelper.isGlobalSecurityEnabled() beide "false" zurück und die Methode RegistryHelper.getUserRegistry() gibt null zurück.
Andere öffentliche Sicherheits-API-Klassen werden unter Umständen nicht geladen, wenn die Sicherheit nicht aktiviert ist. Wenn Sie versuchen, auf diese Klassen zuzugreifen und eine Methode in der Klasse aufrufen, kann eine Ausnahme des Typs java.lang.NoClassDefFoundError eintreten.
Um Ausnahmen des Typs java.lang.NoClassDefFoundError zu vermeiden, müssen Sie zuerst prüfen, ob die Sicherheit aktiviert ist, indem Sie die Klasse WSSecurityHelper.isServerSecurityEnabled() oder WSSecurityHelper.isGlobalSecurityEnabled() aufrufen. Rufen Sie weitere öffentliche Sicherheits-API-Klassen nur dann auf, wenn die Sicherheit aktiviert ist. Beispiele für diese Codierungstechnik finden Sie unter Öffentliche Sicherheits-APIs.
- Anmerkung: Dieses Verhalten weicht von dem in WebSphere Application Server Traditional ab. In WebSphere Application Server Traditional werden immer alle Klassen geladen, unabhängig davon, ob die Sicherheit aktiviert ist.
- Benutzer mit Unicode-Zeichen können nicht authentifiziert werden
- Um Benutzer authentifizieren zu können, deren Namen Unicode-Zeichen enthalten, müssen Sie den vom Liberty-Server verwendeten Zeichencodierungstyp UTF-8 festlegen, indem Sie die folgende JVM-Option dem Serverstartbefehl hinzufügen:
-Dclient.encoding.override=UTF-8
Außerdem müssen Sie charset und pageEncoding auf Ihrer Anmeldeseite angeben. Nachfolgend sehen Sie ein Beispiel für die Angabe dieser Parameter auf einer JSP-Anmeldeseite:<%@page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
- java.lang.annotation.AnnotationFormatError: java.lang.IllegalArgumentException:Wrong type at constant pool index at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:87)
- Dieser Fehler kann auftreten, wenn ein OpenID Connect- oder OAuth-Provider
einen Datenbankspeicher für die Clientregistrierung mit einer JDK 7-Version verwendet.
Sie können dieses Problem vermeiden, indem Sie ein Upgrade auf JDK Version 7.1 durchführen.
Fehlerbehebung für LDAP
In diesem Abschnitt werden einige häufige LDAP-Probleme und auswählbare Lösungen beschrieben.
- FFDC1015I: An FFDC Incident has been created: javax.naming.ServiceUnavailableException: myldapserver.mycompany.com:636; socket closed com.ibm.ws.security.registry.ldap.internal.LdapRegistry 298
- Diese Nachricht in der Datei messages.log zeigt an, dass der konfigurierte LDAP-Server nicht erreicht werden kann. Überprüfen Sie Ihren LDAP-Server, um sicherzustellen, dass er aktiv ist und dass seine IP-Adresse über den Liberty-Server erreichbar ist.
- The javax.naming.CommunicationException: simple bind failed: myldapserver.mycompany.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.g: PKIX path building failed: java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target]
- Wenn Sie SSL in Ihrem LDAP-Server aktivieren, ohne den Unterzeichner des LDAP-Servers in den Truststore zu kopieren, der im Element LDAPSSLSettings referenziert wird, schlägt eine Verbindung zum LDAP-Server mit einem SSL-Handshakefehler fehl. Stellen Sie sicher, dass der Unterzeichner des LDAP-Servers in Ihren Truststore kopiert wird.
- The javax.naming.CommunicationException: myldapserver.mycompany.com:389 [Root exception is java.net.BindException: Address already in use: connect]
- Diese Nachricht kann in den FFDC-Protokollen angezeigt werden und zeigt an, dass die verwendbaren Sockets auf dem lokalen Server aufgebraucht sind, was zu einem Fehler beim Herstellen der Verbindung zum LDAP-Server führt. Vergewissern Sie sich, dass das Socket nicht verwendet wird und versuchen Sie es erneut.
- CWWKS1100A: Die Authentifizierung für die Benutzer-ID xxxxx war nicht erfolgreich. Es wurde eine ungültige Benutzer-ID und/oder ein ungültiges Kennwort angegeben.
- Diese FFDC-Ausnahme kann im Server auftreten, obwohl der in der Nachricht erwähnte Benutzer auf dem LDAP-Server mit hoher Belastung ein gültiger Benutzer ist. In der LDAP-Konfiguration können Sie die Eigenschaft reuseConnection=false hinzufügen oder diese mit den Entwicklertools inaktivieren. Legen Sie für diese Eigenschaft den Standardwert true fest, um dieses Problem zu beheben.
Fehlerbehebung für SSL
In diesem Abschnitt werden einige allgemeine SSL-Probleme und auswählbare Lösungen beschrieben.
- CWWKS9105E: Der SSL-Port für automatische Umleitung konnte nicht bestimmt werden.
- Dieser Fehler tritt auf, wenn Sie versuchen, auf eine Anwendung zuzugreifen, die an einen SSL-Port umgeleitet wird, und der SSL-Port nicht verfügbar ist. Der Port ist möglicherweise wegen einer fehlenden SSL-Konfiguration oder wegen eines Fehlers in der Definition der SSL-Konfiguration nicht verfügbar. Überprüfen Sie die SSL-Konfiguration in der Datei server.xml, um sicherzustellen, dass sie vorhanden und korrekt ist. Weitere Informationen hierzu finden Sie unter Kommunikation mit Liberty schützen.
- FFDC1015I: An FFDC Incident has been created: "java.lang.IllegalArgumentException: Unknown, incomplete configuration: missing id field com.ibm.ws.config.internal.cm.ManagedServiceFactoryTracker aSyncReadNupdate. Exception thrown while trying to read configuration and update ManagedServiceFactory. Exception = java.lang.IllegalArgumentException: Unknown, incomplete configuration: missing id field" at ffdc_12.04.18_16.09.42.0.log
- Dieser Fehler tritt auf, wenn ein Element keystore ohne ein Feld "ID" in der Konfiguration enthalten ist. Wenn Sie eine SSL-Minimalkonfiguration verwenden, setzen Sie das Feld "ID" auf defaultKeyStore.
- Wenn Sie eine LDAP-Benutzerregistry mit sslEnabled verwenden und keinen sslRef-Wert angeben, kann eine Ausnahme ausgelöst werden.
- In der folgenden Beispielkonfiguration ist der Wert von sslEnabled
"true", aber es ist kein Wert für sslRef angegeben:
<ltldapRegistry id="ldap" realm="SampleLdapIDSRealm" host="ccwin12.austin.ibm.com" port="636" ignoreCase="true" baseDN="o=ibm,c=us" bindDN="cn=root" bindPassword="rootpwd" ldapType="IBM Tivoli Directory Server" idsFilters="ibm_dir_server" sslEnabled="true" searchTimeout="8m" />
Sie müssen einen Wert für sslRef angeben. Wenn Sie eine SSL-Minimalkonfiguration wie
verwenden, muss sslRef auf defaultSSLConfig gesetzt werden.<ltkeyStore id="defaultKeyStore" location="key.jks" password="mypassword" />
Bei einer angepassten SSL-Konfiguration muss der Name dieser Konfiguration in sslRef angegeben werden.
- Wird ein JDK von WebSphere Application Server verwendet, wird möglicherweise der folgende Fehler angezeigt, wenn SSL für Ihren Liberty-Server aktiviert ist.
java.net.SocketException: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory at javax.net.ssl.DefaultSSLSocketFactory.a(SSLSocketFactory.java:11) at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:6) at com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:161) at com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:36) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1184) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:390) at com.ibm.net.ssl.www2.protocol.https.b.getResponseCode(b.java:75) at com.ibm.ws.jmx.connector.client.rest.internal.RESTMBeanServerConnection.loadJMXServerInfo(RESTMBeanServerConnection.java:142) at com.ibm.ws.jmx.connector.client.rest.internal.RESTMBeanServerConnection.<init>(RESTMBeanServerConnection.java:114) at com.ibm.ws.jmx.connector.client.rest.internal.Connector.connect(Connector.java:315) at com.ibm.ws.jmx.connector.client.rest.internal.Connector.connect(Connector.java:103)
Dieser Fehler tritt auf, weil die SSL-Socket-Factorys von WebSphere Application Server nicht von Liberty unterstützt werden. Sie können dieses Problem mit den folgenden Schritten beheben:- Erstellen Sie eine Textdatei, z. B. my.java.security, mit den folgenden beiden leeren Einträgen:
ssl.SocketFactory.provider= ssl.ServerSocketFactory.provider=
- Erstellen Sie eine Datei jvm.options für Ihren Liberty-Server.
- Fügen Sie Ihrer Datei jvm.options die folgende Eigenschaft hinzu, die den vollständigen Pfad zu Ihrer
soeben erstellten Textdatei enthält.
-Djava.security.properties=vollständiger_Pfad_zu/my.java.security
- Um die Wiederverwendbarkeit der Datei zu verbessern, können Sie die Datei
my.java.security in Ihrem Serververzeichnis speichern. Daraufhin können Sie einen relativen Pfad wie den folgenden
verwenden:
-Djava.security.properties=./my.java.security
Weitere Informationen finden Sie unter Liberty-Umgebung anpassen.
- Erstellen Sie eine Textdatei, z. B. my.java.security, mit den folgenden beiden leeren Einträgen:
Fehlerbehebung für CORBA/IIOP
In diesem Abschnitt sind verschiedene häufige CORBA-Probleme und entsprechende Lösungen beschrieben.
- Wird ein JDK von WebSphere Application Server verwendet, wird möglicherweise der folgende Fehler angezeigt, wenn Ihre Anwendung die CORBA/IIOP-Kommunikation verwendet.
15:21:58.096 com.ibm.rmi.pi.InterceptorManager runPreInit:178 Init Process ORBRas [default] java.lang.ClassNotFoundException: com.ibm.ISecurityLocalObjectBaseL13Impl.CSIClientRI at com.ibm.CORBA.iiop.UtilDelegateImpl.loadClass(UtilDelegateImpl.java:685) at javax.rmi.CORBA.Util.loadClass(Util.java:246) at com.ibm.rmi.pi.InterceptorManager.runPreInit(InterceptorManager.java:172) at com.ibm.rmi.corba.ORB.initializeInterceptors(ORB.java:664) at com.ibm.CORBA.iiop.ORB.initializeInterceptors(ORB.java:1084) at com.ibm.rmi.corba.ORB.orbParameters(ORB.java:1359) at com.ibm.rmi.corba.ORB.set_parameters(ORB.java:1271) at com.ibm.CORBA.iiop.ORB.set_parameters(ORB.java:1694) at org.omg.CORBA.ORB.init(ORB.java:371) ...
Dieser Fehler tritt auf, weil die ORB-Interceptors (Object Request Broker) von WebSphere Application Server nicht von Liberty unterstützt werden. Sie können dieses Problem beheben, indem Sie die Datei orb.properties aus dem JDK so bearbeiten, dass diese Interceptors nicht verwendet werden. Diese Datei befindet sich gewöhnlich im WebSphere-Verzeichnis <JAVA_HOME>/jre/lib, obwohl sie möglicherweise mit einer Kopie aus dem Verzeichnis <USER_HOME> des Benutzers überschrieben wurde. Das folgende Beispiel zeigt die Zeilen in der Datei orb.properties, die auf Kommentar gesetzt werden müssen:
# WS-Interceptors #org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.Transaction.JTS.TxInterceptorInitializer #org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ejs.ras.RasContextSupport #org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ISecurityLocalObjectBaseL13Impl.ClientRIWrapper #org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.activity.remote.cos.ActivityServiceClientInterceptor #org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ISecurityLocalObjectBaseL13Impl.CSIClientRI #org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.debug.olt.ivbtrjrt.OLT_RI #org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.wlm.client.WLMClientInitializer # WS-ORB- & Plug-in-Eigenschaften #com.ibm.ws.orb.transport.ConnectionInterceptorName=com.ibm.ISecurityLocalObjectBaseL13Impl.SecurityConnectionInterceptor
Fehlerbehebung für die Protokollierung und Traceerstellung
In diesem Abschnitt sind einige häufige Probleme mit der Protokollierung und Traceerstellung beschrieben.
- java.util.logging -- Programmierschnittstelle für Java-Protokollierung
- Liberty unterstützt die Verwendung der Datei logging.properties für die Konfiguration von java.util.logging nicht. Verwenden Sie Java-Code beispielsweise in einer implementierten Anwendung oder in einem implementierten Benutzerfeature, um Handler, Filter oder Formatierungsprogramme für java.util.logging zu erstellen und hinzuzufügen.
- Da der Liberty-Server die java.util.logging-Protokollierungsstufen in Übereinstimmung mit dem Attribut traceSpecification des Konfigurationselements für die Protokollierung verwaltet, müssen Sie die Methode Logger.setLevel nicht verwenden.


Fixpacks und vorläufige Fixes auf eine Archivinstallation anwenden
Wenn Sie Ihre Liberty-Laufzeitumgebung über eine Archivdatei und nicht mithilfe von Installation Manager installiert haben, müssen Sie spezielle Maßnahmen bei der Anwendung von Serviceaktualisierungen ergreifen. Weitere Informationen finden Sie unter Fixpack auf eine Java-Archivinstallation von Liberty anwenden und Vorläufigen Fix auf Liberty-Archivinstallation anwenden.
Fehlerbehebung für die Leistung
In diesem Abschnitt sind einige häufige Leistungsprobleme und auswählbare Lösungen beschrieben.
- Hohe CPU-Belastung durch den Anwendungsmonitor
Dieser Fehler kann auftreten, wenn im Verzeichnis apps/ Ihres Anwendungsmonitor viele Dateien enthalten sind und der Monitor häufig Abfragen durchführt.
Sie können einige Punkte ändern, um dieses Problem zu beheben.
- Erhöhen Sie den Wert des Attributs pollingRate im Element applicationMonitor.
- Aktualisieren Sie die Datei server.xml so, dass
ein Element applicationMonitor mit
updateTrigger ohne den Status
polled enthalten ist.
server.xml <applicationMonitor updateTrigger="mbean" />
- Verringern Sie die Anzahl der Dateien im Verzeichnis apps/.
Weitere Informationen zum Element applicationMonitor finden Sie unter Dynamische Aktualisierungen steuern.
Fehlerbehebung für Verbünde
In diesem Abschnitt werden ein Problem mit Verbünden und die entsprechende Lösung beschrieben.
- java.lang.IllegalArgumentException: CWWKX0219E: Die MBean 'WebSphere:feature=collectiveController,type=CollectiveRepository,name=CollectiveRepository' hat keine Operation mit dem Namen 'retrieveMemberRootCertificate'.
- Ein Server mit dem Feature collectiveMember-1.0 (Member) kann
sich nicht bei einem Server mit dem Feature collectiveController-1.0 (Controller), der eine ältere Version von Liberty hat, registrieren.
Ein Member mit dieser Betaversion von Liberty kann sich beispielsweise nicht bei einem Controller mit der Version
8.5.5.2 von Liberty registrieren.
Bei der Standardprotokollierung wird dieses Problem als First-Failure Data Capture (FFDC) in den FFDC-Protokollen des Members berichtet.
Zur Behebung des Problems müssen Sie den Controller auf die Liberty-Version des Members oder eine höhere Version aktualisieren.
Fehlerbehebung für SAML
In diesem Abschnitt werden ein Problem mit SAML und die entsprechende Lösung beschrieben.
- java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 0
- Diese Ausnahme kann eintreten, wenn über eine nicht vom Service-Provider (SP) angeforderte Anforderung mehrere Anmeldeversuche getätigt werden, ohne das IdP-Token (Identitätsprovider) zu entfernen.
- Um diese Ausnahme zu verhindern, fügen Sie den Eintrag <httpSession invalidateOnUnauthorizedSessionRequestException="true" /> in der entsprechenden nicht angeforderten Datei server.xml hinzu.
- java.lang.IllegalStateException: CWWKS0010E: Beim Abrufen des Caller-Principals wurde festgestellt, dass ein Caller-Subjekt mehrere Principals des Typs WSPrincipal hat. Es ist nur ein einziger WSPrincipal pro Subjekt zulässig. Die Namen der WSPrincipals sind {0}
- Diese Ausnahme kann eintreten, wenn sich ein SAML-Benutzer zuvor direkt an einer lokalen Benutzerregistry angemeldet hat. Um dieses Problem zu vermeiden, darf sich ein SAML-Benutzer nicht direkt an einer lokalen Benutzerregistry anmelden.
Fehlerbehebung für die REST-API-Erkennung
Wenn die IBM REST API Documentation Explorer-Auswahl "Try it out" über Fernzugriff aufgerufen wurde und mit einem Antwortcode von 0 fehlschlägt, stellen Sie sicher, dass der vollständig qualifizierte Hostname oder die IP-Adresse an den IBM REST API Discovery Explorer an den Curl- und Anforderungs-URL zurückgegeben wird, der zur GET-, PUT-, POST- oder DELETE-Operation gehört. Wenn sich der vollständig qualifzierte Hostname oder die IP-Adresse nicht im Curl- und Anforderungs-URL befindet, führen Sie die folgenden Aktionen aus:
- Fügen Sie das Variablenelement der Datei server.xml hinzu und geben Sie den vollständig qualifizierten Hostnamen an. Im Folgenden sehen Sie ein Beispiel für das Hinzufügen des Variablenelements, das den vollständig qualifizierten Hostnamen in der Datei server.xml angibt.
<httpEndpoint host="*" httpPort="9080" httpsPort="9443" id="defaultHttpEndpoint"/> <variable name="defaultHostName" value="developer.rtp.raleigh.ibm.com"/>
Geben Sie den vollständigen Computernamen für Ihr Betriebssystem als vollständig qualifizierten Hostname an.
- Vergewissern Sie sich, dass der vollständig qualifizierte Hostname im Curl- und Anforderungs-URL zurückgegeben wird, der zu den GET-, PUT-, POST- oder DELETE-Operationen gehört. Weitere Informationen finden Sie unter Standardhostnamen für einen Liberty-Server festlegen sowie in der Produktdokumentation von IBM InfoSphere Information Server Version 11.3.1 im Abschnitt zur Netzkonfiguration.