Tipps zur Fehlerbehebung

Tipps zur Fehlerbehebung in Liberty Profile.

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 Trace. 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.

Ausführliche Informationen zur Java™-API-Dokumentation für die einzelnen APIs von Liberty Profile finden Sie im Information Center im Abschnitt Programmierschnittstellen (APIs). Die Java-API-Dokumentation ist außerdem als eigenständige .zip-Datei in einem der Javadoc-Unterverzeichnisse des Verzeichnisses ${wlp.install.dir}/dev verfügbar.

Für verteilte PlattformenNähere Informationen zu den bekannten Einschränkungen bei Verwendung von Liberty Profile finden Sie in den folgenden Abschnitten:

Für IBM i-PlattformenEinzelheiten zu den bekannten Einschränkungen, die bei der Verwendung von Liberty Profile gelten, finden Sie unter Bekannte Probleme und Einschränkungen für die Laufzeitumgebung.

Prüfen Sie, ob die Version der JDKs unterstützt wird

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 6 oder höher kompatibel sind und einen aktuellen Service-Level haben. Nähere Informationen hierzu finden Sie unter Unterstützte Java-Mindestversionen.

Anmerkung: Ein Deadlock kann auftreten, wenn Oracle-basierte JVMs mit Java Version 6 verwendet werden. Wenn Sie eine entsprechende JVM oder ein entsprechendes JDK verwenden, können Sie mithilfe der folgenden Einstellungen den Deadlock verhindern:
  • Aktivieren Sie die folgende VM-Option: -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass
  • Definieren Sie die folgende Equinox-Konfigurationsoption, um das Equinox-Framework so einzustellen, dass die Sperrung von Klassennamen beim Laden von Klassen verwendet wird: -Dosgi.classloader.lock=classname
Sie können diese Optionen in einer Java-Eigenschaftendatei, wie z. B. jvm.options, beim Starten des Liberty-Servers festlegen.

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 Sitzungssicherheit.

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. Das Token ist jedoch abgelaufen, der Benutzer ist nicht authentifiziert und es 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, setzen Sie <%@ page session="false" %>.

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 im Liberty-Profil konfigurieren.
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 der Rolle Ihrer Anwendung das 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 im Liberty-Profil 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 im Liberty-Profil konfigurieren.
Single Sign-on (SSO) funktioniert nicht
Wenn SSO nicht funktioniert, vergewissern Sie sich, dass die verschiedenen Liberty Profile-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 für das Liberty-Profil 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 Full Profile ab. In Full Profile werden immer alle Klassen geladen, unabhängig davon, ob die Sicherheit aktiviert ist oder nicht.
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 in 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"%>
Liberty-Repository[8.5.5.4 oder höher]java.lang.annotation.AnnotationFormatError: java.lang.IllegalArgumentException:Wrong type at constant pool index at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:87)
Liberty-Repository[8.5.5.4 oder höher]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 Profile-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 Sie den Unterzeichner des LDAP-Servers in Ihren Truststore kopieren.
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. Mit der LDAP-Konfiguration können Sie die Eigenschaft reuseConnection=false hinzufügen oder die Eigenschaft 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 kann wegen einer fehlenden SSL-Konfiguration oder wegen eines Fehlers in der Definition der SSL-Konfiguration nicht verfügbar sein. Ü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 dem Liberty-Profil sichern.
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 des Feldes sslEnabled "true", aber es ist kein Wert für das Feld 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 das Feld sslRef angeben. Wenn Sie eine SSL-Minimalkonfiguration wie die folgende verwenden:
<ltkeyStore id="defaultKeyStore" location="key.jks"
password="mypassword" />
sollte das Feld sslRef auf defaultSSLConfig gesetzt werden.

Bei einer angepassten SSL-Konfiguration sollte der Name dieser Konfiguration in dem Feld sslRef angegeben werden.

Wenn Sie ein JDK von WebSphere Application Server verwenden, kann der folgende Fehler angezeigt werden, 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 von Liberty Profile nicht 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 Profile-Umgebung anpassen.

Fehlerbehebung für CORBA/IIOP

In diesem Abschnitt sind verschiedene gängige CORBA-Probleme und entsprechende Lösungen beschrieben.

Wenn Sie ein JDK von WebSphere Application Server verwenden, kann der folgende Fehler angezeigt werden, 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 von Liberty Profile nicht unterstützt werden. Sie können dieses Problem beheben, indem Sie die Datei orb.properties aus dem SDK so bearbeiten, dass diese Interceptors nicht verwendet werden. Diese Datei befindet sich gewöhnlich im WebSphere-Verzeichnis <JAVA-AUSGANGSVERZEICHNIS>/jre/lib, obwohl Sie sie möglicherweise mit einer Kopie aus dem Verzeichnis <BENUTZERAUSGANGSVERZEICHNIS> des Benutzers überschrieben haben. 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äufig auftretenden Probleme mit der Protokollierung und Traceerstellung beschrieben.

java.util.logging -- Programmierschnittstelle für Java-Protokollierung
Liberty Profile 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 Profile-Server die java.util.logging-Protokollierungsstufen in Übereinstimmung mit dem Attribut traceSpecification des Konfigurationselements für die Protokollierung verwaltet, sollten Sie die Methode Logger.setLevel nicht verwenden.
Für verteilte PlattformenFür IBM i-Plattformen

Fixpacks und vorläufige Fixes auf eine Archivinstallation anwenden

Wenn Sie die Laufzeitumgebung Ihre Liberty Profile-Instanz über eine Archivdatei und nicht mithilfe von Installation Manager installiert haben, müssen Sie spezielle Maßnahmen ergreifen, wenn Sie Serviceaktualisierungen anwenden. Weitere Informationen finden Sie unter Fixpack auf eine Java-Archivinstallation des Liberty-Profils anwenden und Vorläufigen Fix auf Liberty Profile-Archivinstallation anwenden.

Fehlerbehebung für die Leistung

In diesem Abschnitt sind einige häufig auftretenden Leistungsprobleme und auswählbare Lösungen beschrieben.

Hohe CPU-Belastung durch den Anwendungsmonitor

Dieser Fehler kann auftreten, wenn Ihr Anwendungsmonitor viele Dateien im Verzeichnis apps/ enthählt und zu oft Abfragen durchführt.

Sie können einige Punkte ändern, um dieses Problem zu beheben.

  1. Erhöhen Sie den Wert des Attributs pollingRate.
  2. Aktualisieren Sie die Datei server.xml so, dass ein Element applicationMonitor mit updateTrigger ohne den Status polled enthalten ist.
    server.xml
    <applicationMonitor updateTrigger="mbean" /> 
  3. Verringern Sie die Anzahl der Dateien im Verzeichnis apps/.

Weitere Informationen zum Element applicationMonitor finden Sie unter Dynamische Aktualisierungen steuern.


Symbol das den Typ des Artikels anzeigt. Referenzartikel

Nutzungsbedingungen für Information Center | Feedback


Symbol für Zeitmarke Letzte Aktualisierung: 25.08.2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=rwlp_trouble
Dateiname: rwlp_trouble.html