test

Sun Java System Application Server Enterprise Edition 8.2 - Versionshinweise

Kapitel 3 Bekannte Probleme und Beschränkungen

In diesem Kapitel werden bekannte Probleme und die zugehörigen Abhilfemaßnahmen für die Software Sun Java System Application Server Enterprise Edition 8.2 erläutert. Wenn für ein Problem keine spezielle Plattform angegeben ist, betrifft es alle Plattformen. Diese Informationen sind in die folgenden Abschnitte unterteilt:

Administration

In diesem Abschnitt werden bekannte Verwaltungsprobleme sowie ihre Lösungen beschrieben.

Das Skript package-appclient funktioniert nicht, wenn domain1 nicht vorhanden ist. (Nr. 6171458)

In $INSTALL/lib/package-appclient.xml ist standardmäßig ein Hardcode-Wert für die Variable AS_ACC_CONFIG für domain1 festgelegt, auf den durch asenv.conf verwiesen wird. Wenn domain1 gelöscht und eine neue Domäne erstellt wird, wird die Variable AS_ACC_CONFIG nicht entsprechend der neuen Domäne aktualisiert, sodass die Ausführung des Skripts package-appclient fehlschlägt.

Lösung

Gehen Sie folgendermaßen vor:

Durch die Installation des Load Balancing-Plugin wird ein bestehendes Plugin überschrieben. (Nr. 6172977)

Wenn Sie das Load Balancing-Plugin für eine Installation von Application Server installieren, bei der bereits ein Load Balancer-Plugin installiert ist (z. B. aus 7.1EE) ersetzt das Plugin aus 8.2EE automatisch das bestehende Load Balancer-Plugin, selbst wenn eine neue Serverinstanz für die Ausführung des Plugins erstellt wurde.

Die Plugin-Dateien werden standardmäßig unter Installationsverzeichnis /plugins/lbplugin installiert, was bedeutet, dass mit jeder Application Server -Installation jeweils nur eine einzige Version eines Plugins verwendet werden kann. Beachten Sie: Das Konsoleninstallationsprogramm zeigt eine Meldung, dass eine Deinstallation durchgeführt wird, diese Meldung ist jedoch leicht zu übersehen.

Lösung

Dieses Problem tritt nicht bei allen Benutzern auf. Wenn das Problem bei Ihnen auftritt, müssen Sie die alte Installation von Application Server entfernen und eine Neuinstallation durchführen. (Führen Sie keine Aufrüstungsinstallation durch.)

Mehrere Änderungen im Skript asadmin in JES3 Application Server 8.2 im Vergleich zu JES2 AS7 (Nr. 6189433, 6189436)

Am Befehl "asadmin" in Application Server 8.2 wurden gegenüber Application Server 7.x mehrere Änderungen vorgenommen. Beispielsweise lautet in 7.x der Befehl zum Starten einer Serverinstanz:


asadmin start-instance

In 8.2 lautet der entsprechende Befehl:


asadmin start-domain --user admin domain1

In den folgenden Dokumenten finden Sie umfassende Informationen zur aktuellen Syntax für den Befehl asadmin:

Standardports in Application Server geändert (Nr. 6198555)

Bei der Aufrüstung auf JES5/Application Server 8.2 ausgehend von JES2/Application Server 7. x können Inkompatibilitäten oder Fehler auftreten, da sich die Standardports geändert haben.

Eine Auflistung aller in Application Server 8.2 verwendeten Standard-Ports finden Sie unter Weitere Anforderungen weiter oben in diesen Hinweisen.

Gesicherte Domäne kann nicht unter einem anderen Namen wiederhergestellt werden. (Nr. 6196993)

Das Spiegeln einer Domäne innerhalb einer Application Server-Installation ist mit den Befehlen backup-domain und restore-domain nicht möglich, da die Domäne nicht unter einem anderen Namen wiederhergestellt werden kann, auch wenn der Befehl asadmin restore-domain eine Option für das Umbenennen von Domänen zur Verfügung stellt. Die gesicherte Domäne kann zwar umbenannt werden, die Ausführung der umbenannten Domäne schlägt jedoch fehl, da die Einträge in der Konfiguration der Domäne nicht geändert wurden und startserv und stopserv den ursprünglichen Domänennamen in den Pfadangaben verwenden.

Lösung

Der vom Befehl restore-domain verwendete Domänenname muss mit dem ursprünglichen, vom Befehl backup-domain verwendeten Domänennamen übereinstimmen. Die Befehle backup-domain und restore-domain in Application Server 8.2 funktionieren nur für die Sicherung und Wiederherstellung derselben Domäne auf demselben Computer.

Das Starten von Application Server mit einem zusätzlichen JMX-Agenten wird nicht unterstützt. (Nr. 6200011)

J2SE 1.4.x, 5.0 oder höher können auf Application Server konfiguriert werden. In J2SE 5.0 ermöglicht eine plattformeigene Funktion das Starten eines JMX-Agenten. Um diese Funktion zu aktivieren, setzen Sie die entsprechenden Systemeigenschaften für den Serverstart fest.

Zu den möglichen Werten gehören:

name="com.sun.management.jmxremote" value="true"
name="com.sun.management.jmxremote.port" value="9999"
name="com.sun.management.jmxremote.authenticate" value="false"
name="com.sun.management.jmxremote.ssl" value="false"

Nachdem Sie die JMX-Eigenschaften konfiguriert und den Server gestartet haben, wird ein neuer jmx-connector -Server in der VM von Application Server gestartet. Dieser Vorgang hat unerwünschte Auswirkungen auf die Verwaltungsfunktionen, sodass die Benutzeroberfläche und Befehlszeilenschnittstelle von Application Server nicht einwandfrei arbeiten. Dieses Problem wird durch Konflikte zwischen dem integriertenjmx-connector-Server und dem neuen jmx-connector-Server verursacht.

Lösung

Wenn Sie jconsole (oder einen anderen JMX-kompatiblen Client) verwenden, können Sie den standardmäßig beim Start von Application Server gestarteten JMX Connector Server wiederverwenden.

Wird der Server gestartet, wird eine Zeile ähnlich der unten dargestellten Zeile auf dem Server angezeigt.Protokoll. Sie können eine Verbindung zum dort angegebenen JMXServiceURL herstellen und dieselben Management-/Konfigurationsoperationen durchführen, nachdem Sie die Anmeldeinformationen erfolgreich angegeben haben, beispielsweise:

[#|2004-11-24T17:49:08.203-0800|INFO|sun-appserver-ee8.1|javax.enterprise.
system.tools.admin|_ThreadID=10;|ADM1501: Here is the JMXServiceURL for the 
JMXConnectorServer: [service:jmx:rmi:///jndi/rmi://hostname:8686/management/
rmi-jmx-connector]. This is where the remote administrative clients should 
connect using the JSR 160 JMX Connectors.|#]

Weitere Informationen finden Sie im Sun Java System Application Server 8.2 Administration Guide.

Unter UNIX sind Berechtigungen für das Ausführen der Start -und Stopp-Skripts von Application Server zu restriktiv.

Wenn Sie als Benutzer "A" angemeldet sind und den Befehl asadmin restore-domain ausführen, wird in den Skripts die Berechtigung 744 (rwxr--r--) festgelegt. Wenn Sie anschließend als Benutzer "B" angemeldet sind, können Sie keine Domäne starten oder beenden (selbst wenn Benutzer "B" Root ist), da die Skripts nur noch von Benutzer "A" ausgeführt werden können.

Lösung

Ändern Sie die Berechtigungen in den Skripts: 


chmod 755 appserv/domains/domain-name/bin/*

Load Balancer-Konfigurationsdatei kann nicht mit dem Endpunkt-URL eines Webservice erstellt werden. (Nr. 6236544, 6275436)

Beim Einrichten der Lastenausgleichskonfiguration mit einer Anwendung, die über ein EJB-Modul verfügt und einen Webservice-URL exportiert, befindet sich das Kontext-Stammverzeichnis (root) für den Webservice nicht in der resultierenden Datei loadbalancer.xml.

Lösung

  1. Bearbeiten Sie die Datei loadbalancer.xml wie folgt, um das fehlende Webmodul hinzuzufügen:


    <web-module context-root="context-root-name"
disable-timeout-in-minutes="30" enabled="true"/>

  2. Ersetzen Sie den Wert context-root-name mit dem Kontext-Rootnamen des Webservice, der als EJB offengelegt wurde.

Java Home-Einstellung in der Konfiguration bleibt ohne Wirkung. (Nr. 6240672)

Application Server-Domänen/-Server verwenden nicht das JDK, auf das das Attribut java-home des Elements java-config der zugehörigen Konfiguration verweist.

Lösung

Das von den Application Server-Prozessen für alle Domänen in einer bestimmten Serverinstallation verwendete JDK wird in der Datei appserver-installation-dir /config/asenv.conf festgelegt. Die Eigenschaft AS_JAVA in dieser Datei bestimmt das verwendete JDK und wird zum Installationszeitpunkt festgelegt. Wenn nach Abschluss der Installation ein anderes JDK von den Application Server-Prozessen verwendet werden soll, kann dieser Wert so geändert werden, dass er auf ein anderes JDK verweist. Beachten Sie, dass alle Domänen in dieser Installation von dieser Änderung betroffen sind.

Hinweis –

Manuelle Änderungen an der Datei asenv.conf werden nicht auf ihre Gültigkeit überprüft. Daher sollte bei ihrer Änderung mit besonderer Sorgfalt vorgegangen werden. Die Mindestanforderungen an die JDK-Version bei der Bearbeitung des Werts für AS_JAVA finden Sie in der Produktdokumentation.

Application Server-Neustart unter Verwendung von sun-appserv-admin führt zu einem LoginException-Fehler. (Nr. 6288893)

Dieses Problem wird durch einen falschen Wert für %CONFIG_HOME% verursacht.

Lösung

  1. Benennen Sie die bestehende Datei in asant.bak um.

  2. Kopieren Sie die Datei asant.template in <as_install> /lib/install/templates/ee (für die SE/EE-Version) in das <as_install>/bin/-Verzeichnis und benennen Sie die Datei in asant um.

  3. Bearbeiten Sie das gerade kopierte <as_install> /bin/asant-Skript, wobei Sie das %CONFIG_HOME%-Token durch <as_install>/config ersetzen.

  4. Falls manuelle Änderungen an der ursprünglichen asant.bak-Datei vorgenommen wurden, führen Sie diese in das neue asant-Skript zusammen.

Die Datei .asadmintruststore wird nicht in der Application Server-Dokumentation beschrieben. (Nr. 6315957)

Falls diese Datei nicht im home-Verzeichnis des Serveradministrators vorhanden ist, können schwerwiegende Fehler beim Upgrade bestimmter, auf dem Server gehosteter Anwendungen auftreten.

Lösung

Domäne startet nicht, wenn das create-domain-Masterpasswort Sonderzeichen enthält. (Nr. 6345947)

Domäne startet nicht, wenn das Masterpasswort der Domäne ein Prozentzeichen (%) enthält.

Lösung

Das Masterpasswort der Domäne sollte kein Prozentzeichen enthalten (%). Dies gilt beim Erstellen einer neuen Domäne bzw. beim Ändern des Masterpassworts einer bestehenden Domäne.

Die Änderungen an der Load Balancer-Konfiguration in magnus.conf und obj.conf werden überschrieben (Nr. 6394181)

Nach dem Erstellen eines sicheren http-listener und der Installation von lbplugin werden die Dateien magnus.conf und obj.conf unter webserver_instance_dir/config bearbeitet und die Inhalte von lbplugin werden entfernt.

Das Installationsprogramm bearbeitet die Konfigurationsdateien magnus.conf und obj.conf in Application Server im Rahmen der Installation des Load Balancer-Plugins. Wenn Sie sich bei der Application Server-Administratorkonsole anmelden und versuchen, die Instanzenkonfiguration für die Instanz zu ändern, auf der der Load Balancer installiert wurde, gibt Application Server eine Warnmeldung aus, die besagt, dass eine manuelle Bearbeitung in der Konfiguration gefunden wurde. Diese Warnung bezieht sich jedoch in Wirklichkeit auf die vom Installationsprogramm vorgenommenen Änderungen.

Lösung

Vergewissern Sie sich, dass die vom Installationsprogramm vorgenommenen Änderungen nicht überschrieben wurden.

Apache und Lastenausgleich-Plugin

In diesem Abschnitt werden bekannte Probleme des Apache Webservers und des Lastenausgleich-Plugins sowie zugehörige Lösungen erläutert.

Der High Availability Administration Guide enthält falsche Anweisungen zur Verwendung von openssl mit Apache. (Nr. 6306784)

Führen Sie beim Kompilieren und Erstellen von openssl folgende Befehle aus:


cd openssl-0.9.7e
config
make

Außerdem variiert bei Apache 1.3 der Verzeichnisname der mod_ssl-Quelle je nach verwendeter Apache-Version. Beispielsweise lautet bei Apache 1.3.33 der Name mod_ssl-2.8.22-1.3.33.

Im High-Availability Administration Guide sind keine Anweisungen zur Verwendung eines Zertifikats für Apache 2.0 enthalten. (Nr. 6307976)

Zum Ausführen der Apache-Sicherheit müssen Sie ein Zertifikat verwenden. Anweisungen, wie Sie von einer Zertifizierungsstelle ein Zertifikat erhalten, finden Sie in den Informationen über Zertifikate unter modssl FAQ.

Apache Web Server muss als Root gestartet werden. (Nr. 6308021)

Wenn Ihr Anwendungsserver unter Solaris unter Root installiert wurde, müssen Sie Apache Web Server als Root starten. Java Enterprise System-Installationen werden als Root installiert. Für Apache 2.0 gilt Folgendes: Nach dem Start als Root kann Apache umgeschaltet und als ein anderer von Ihnen festgelegter Benutzer ausgeführt werden. Diesen Benutzer legen Sie in der Datei /conf/httpd.conf fest. Zum Start als Root müssen Sie auf vielen Systemen die Datei httpd.conf bearbeiten, um die korrekte Gruppe anzugeben. Ersetzen Sie folgende Zeile:


Group #-1

durch


Group nobody

Weitere Informationen zur Benutzer-/Gruppenverwendung finden Sie in der Datei httpd.conf.

Zusatz zu den Anweisungen für die Verwendung von openssl mit Apache Web Server 2.0 unter Solaris. (Nr. 6308043)

Nach Installation von Apache 2.0 und des Lastenausgleich-Plugins bearbeiten Sie ssl.conf und sll-std.conf wie folgt:

Ersetzen Sie folgende Zeile:

<VirtualHost _default_:9191>

durch

<VirtualHost machine_name:9191>

Dabei ist machine_name der Name Ihres Computers und 9191 die Sicherheits-Portnummer.

Anwendungsclient

In diesem Abschnitt werden bekannte Probleme des Anwendungsclients sowie ihre Lösungen beschrieben.

JAR-Bibliothek im Archiv des Anwendungsclients überschreibt die MANIFEST-Datei. (Nr. 6193556)

Wenn die Client-JAR eine JAR-Datei der obersten Ebene enthält (hier reporter.jar) und Sie die Client-JAR bereitstellen, überschreibt die MANIFEST-Datei dieser JAR die MANIFEST-Datei der Client-JAR.

Lösung

Zu diesem Zeitpunkt steht keine Lösung zur Verfügung.

Technologien für dynamische Inhalte, wie beispielsweise CGI-bin und SHTML-Funktionen, werden nicht unterstützt. (Nr. 6373043)

Technologien für dynamische Inhalte, wie beispielsweise CGI-bin und SHTML, werden nicht mehr unterstützt.

Lösung

Verwenden Sie stattdessen JSP- und Webservice-Technologien.

Im Lieferumfang enthaltene Sun JDBC-Treiber

In diesem Abschnitt werden bekannte Probleme der im Lieferumfang enthaltenen Sun JDBC-Treiber sowie ihre Lösungen beschrieben.

Anwendungen, die die TRANSACTION_SERIALIZABLE-Isolationsebene zusammen mit dem im Paket enthaltenen Sun-Treiber für Microsoft SQL Server verwenden, reagieren nicht, wenn eine vorbereitete Aktualisierungsanweisung verwendet wird und zwei Transaktionen parallel ausgeführt werden und eine der Transaktionen rückgängig gemacht wird. (Nr. 6165970)

Um die Isolationsebene für eine Verbindung wie gewünscht setzen zu können, muss das entsprechende Verbindungspool auf derselben Isolationsebene erstellt werden. Einzelheiten zur Konfiguration von Verbindungspools finden Sie unter Sun Java System Application Server Enterprise Edition 8.2 Administration Guide .

PreparedStatement-Fehler. (Nr. 6170432)

Beschreibung 1

Wenn eine Anwendung mehr als 3000 PreparedStatement-Objekte in einer Transaktion generiert, kann folgender DB2-Fehler auftreten:

[sunm][DB2 JDBC Driver] No more available statements. Erstellen Sie Ihr Paket mit einem höheren dynamicSections-Wert neu.

Lösung 1

Fügen Sie die folgenden Eigenschaften zur Verbindungspooldefinition hinzu, damit der Treiber DB2-Pakete mit einem größeren dynamischen Abschnittswert neu bindet:

createDefaultPackage=true replacePackage=true dynamicSections=1000

Einzelheiten zur Konfiguration von Verbindungspools finden Sie unter Sun Java System Application Server Enterprise Edition 8.2 Administration Guide .

Beschreibung 2

Im Zusammenhang mit dem oben erwähnten PrepardStatement-Fehler kann folgender Fehler auftreten:

[sunm][DB2 JDBC Driver][DB2]Virtueller Speicher oder Datenbankressource steht nicht zur Verfügung.

Lösung 2

Erhöhen Sie den Wert des Konfigurationsparameters APPLHEAPSZ des DB2-Servers. Ein geeigneter Wert ist 4096.

Beschreibung 3

Isolationsebene TRANSACTION_SERIALIZABLE Wenn eine Anwendung die Isolationsebene TRANSACTION_SERIALIZABLE und einen der oben genannten Parameter verwendet, kann die Anwendung beim Verbindungsaufbau abstürzen.

Lösung 3

Um die Isolationsebene für eine Verbindung wie gewünscht setzen zu können, muss das entsprechende Verbindungspool auf derselben Isolationsebene erstellt werden. Anweisungen finden Sie im Sun Java System Application Server Enterprise Edition 8.2 Administration Guide .

Probleme beim Setzen der Isolationsebene bei mitgeliefertem Sun-Treiber für Sybase Adaptive Server. (Nr. 6189199)

Lösung

Zu diesem Zeitpunkt steht keine Lösung zur Verfügung.

Unter Solaris 10 und Enterprise Linux 3.0 lässt der im Sun-Paket enthaltene Oracle JDBC-Treiber keine Verbindungserstellung zu. (Nr. 6247468)

Setzen Sie die folgende Eigenschaft im JDBC-Verbindungspool, wenn Sie die SUN JDBC-Oracle-Datenquelle verwenden (com.sunsql.jdbcx.oracle.OracleDataSource):

<property name="serverType" value="dedicated"/>

Der Wert der Eigenschaft hängt davon ab, wie der Listener des Oracle-Servers konfiguriert ist. Wenn er im Modus "shared" konfiguriert ist, muss der obige Wert zu "dedicated" geändert werden.

Konnektoren

In diesem Abschnitt werden bekannte Probleme der J2EE-Konnektorenarchitektur und die zugehörigen Lösungen beschrieben.

Nach dem Neustart einer DAS-Instanz kann die Bereitstellung des Konnektormoduls nicht aufgehoben werden, wenn die Option "cascade" auf "false" gesetzt ist. (Nr. 6188343)

Dieses Problem tritt auf, wenn ein eigenständiges oder eingebettetes Konnektormodul in DAS und in Konnektor-Verbindungspools bereitgestellt ist und Ressourcen für das bereitgestellte Modul erstellt werden. Nach dem Neustart der DAS-Instanz schlägt die Aufhebung der Bereitstellung im Konnektormodul fehl, wenn cascade auf false gesetzt ist. Folgender Ausnahmefehler tritt auf:

[#|2004-10-31T19:52:23.049-0800|INFO|sun-appserver-ee8.1|javax.enterprise.system .core|_ThreadID=14;|CORE5023: Fehler beim Entladen der Anwendung [foo]|#].

Lösung

Setzen Sie die cascade-Option auf true, um nach dem Neustart der DAS-Instanz die Bereitstellung der eigenständigen und eingebetteten Konnektoren aufheben zu können.

JMS create-jms-resource; CLI legt die Standardwerte nicht korrekt fest (Nr. 6294018)

Da Sie die minimale und maximale Poolgröße nicht angeben können, wenn Sie mit dem Befehl asadmin create-jms-resource über die Befehlszeile eine neue JMS-Ressource erstellen, sollte der Befehl asadmin die Ressource unter Verwendung der Standardwerte für die Poolgröße (Minimum 8, Maximum 32) erstellen. Dies ist jedoch nicht der Fall. Stattdessen führt die Erstellungen der Ressource über die Befehlszeile zu einer standardmäßigen minimalen bzw. maximalen Poolgröße von 1 bzw. 250.

Lösung

Bearbeiten Sie nach der Erstellunge einer JMS-Ressource über die Befehlszeile die Werte für die minimale und maximale Poolgröße mithilfe der Verwaltungskonsole.

Dokumentation

In diesem Abschnitt werden die bekannten Probleme mit der Dokumentation sowie ihre Lösungen beschrieben.

Javadoc-Inkonsistenzen. (verschiedene Fehlernummern)

Die Javadoc verschiedener AMX-Schnittstellen und -Methoden fehlen oder sind nicht korrekt:

Gebündeltes ANT führt zu java.lang.NoClassDefFoundError . (Nr. 6265624)

Der folgende Ausnahmefehler tritt im Thread "main" auf: java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher.

Lösung

Die Verwendung der Paket-ANT für Funktionen außerhalb von Application Server wird nicht empfohlen.

Dokumentation für Protokollieroptionen inkorrekt (Nr. 6463965)

Im Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide stehen fälschlicherweise folgende Angaben zu Protokolloptionen:

Die Administrations-GUI bietet die folgenden beiden Protokollieroptionen:

  • Option 1 – Protokollierung von stdout ( System.out.print)-Inhalten im Ereignisprotokoll

  • Option 2 – Protokollierung von stderr ( System.err.print)-Inhalten im Ereignisprotokoll

Diese Protokolloptionen sind in Application Server Enterprise Edition 8.2 nicht mehr verfügbar.

In Konflikt stehende Informationen zur HTTP-Dateicache-Funktion in Application Server 8.2 (Nr. 6474799)

In der Application Server Enterprise Edition 8.2-Dokumentation wird eine HTTP-Dateicache-Funktion besprochen. Und zwar unter HTTP File Cache in Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide . Diese Funktion wurde jedoch nicht in Application Server Enterprise Edition 8.2 aufgenommen. Beachten Sie, dass diese Funktion in Application Server 9.0 erneut eingeführt wurde.

Die Dokumentation zur Herstellung einer physischen Verbindung von einer umschlossenen Verbindung ist nicht mehr korrekt (ID 6486123)

Aufgrund anderer Fehler (vermutlich 6295215) ist der im Abschnitt Obtaining a Physical Connection from a Wrapped Connection in Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide, Kapitel Kapitel 11, Using the JDBC API for Database Access in Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide angegebene Code nicht korrekt. Insbesondere sollte die folgende Zeile:


Connection drivercon = ds.getConnection(con);

nun wie folgt lauten:


Connection drivercon = ((com.sun.gjc.spi.DataSource)ds).getConnection(con);

Hochverfügbarkeit

In diesem Abschnitt werden bekannte Probleme mit der Hochverfügbarkeits-Datenbank (HADB) und zugehörige Lösungen erläutert.

HADB-Konfiguration in zweifachen Netzwerken. (Keine Fehlernummer)

Unter Solaris SPARC ist eine HADB-Konfiguration für zwei Netzwerke in zwei Teilnetzen problemlos möglich. Auf Solaris x86- und Linux-Plattformen führen jedoch Betriebssystem- bzw. Netzwerktreiberprobleme dazu, dass eine doppelte Netzwerkkonfiguration nicht immer einwandfrei ausgeführt wird. Dadurch entstehen folgende HADB-Probleme:

Die Erstellung der HADB-Datenbank schlägt fehl. (Keine Fehlernummer)

Die Erstellung einer neuen Datenbank kann fehlschlagen und folgenden Fehler ausgeben, der besagt, dass zu wenig gemeinsame Speichersegmente verfügbar sind:

HADB-E-21054: Systemressource nicht verfügbar: HADB-S-05512: Anhängen des gemeinsamen Speichersegments mit Schlüssel "xxxxx" fehlgeschlagen, OS-Status=24 OS-Fehlermeldung: Zu viele Dateien geöffnet.

Lösung

Stellen Sie sicher, dass der gemeinsame Speicher konfiguriert wurde und die Konfiguration funktioniert. Prüfen Sie insbesondere unter Solaris 8 die Datei /etc/system und stellen Sie sicher, dass der Wert der Variable shmsys:shminfo_shmseg mindestens die sechsfache Anzahl der Knoten pro Host beträgt.

Gemeinsam verwendete Arbeitsspeichersegmente gesperrt und können nicht ausgelagert werden. (Nr. 5052548)

HADB 4.3-0.16 und höher ist für die Verwendung von beim Erstellen und Anfügen von gemeinsam verwendeten Arbeitsspeichersegmenten konfiguriert (verwendet das Flag SHM_SHARE_MMU ). Die Verwendung dieses Flag hat als wesentliche Wirkung, dass die gemeinsam verwendeten Arbeitsspeichersegmente im physischen Speicher gesperrt werden und nicht ausgelagert werden können. Die kann bei Installationen auf weniger leistungsstarken Computern schnell zu Problemen führen.

Wenn also einem Entwickler ein Computer mit 512 MB Arbeitsspeicher und einem recht großen Auslagerungbereich bei Verwendung von Application Server7.0 EE zur Verfügung steht, und 7.1 EE oder höher installiert wird, treten Probleme bei der Konfiguration des Standardclusters clsetup auf. Dieses erstellt zwei HADB-Knoten, jeweils mit einer devicesize von 512, was dazu führt, dass nicht genügend physischer RAM zur Verfügung steht, um den gemeinsamen Speicher zu unterstützen, die beide Knoten benötigen.

Lösung

Stellen Sie sicher, dass Sie über Arbeitsspeicher im empfohlenen Umfang verfügen, wenn Sie Application Server und HADB auf demselben Rechner installieren. Weitere Informationen finden Sie unter HADB-Anforderungen und unterstützte Plattformen.

hadbm set prüft Ressourcenverfügbarkeit nicht (Festplatte und Arbeitsspeicher). (Nr. 5091280)

Das Verwaltungssystem prüft beim Erstellen von Datenbanken und beim Hinzufügen von Knoten die Ressourcenverfügbarkeit. Die Verfügbarkeit der Ressourcen wird jedoch nicht geprüft, wenn mit hadbm set die Puffergröße des Geräts oder des Hauptspeichers geändert wird.

Lösung

Stellen Sie sicher, dass auf allen Hosts genügend freier Festplatten-/Arbeitsspeicher zur Verfügung steht, bevor Sie die Konfigurationsattribute devicesize bzw. buffersize erhöhen.

Heterogene Pfade für packagepath nicht unterstützt. (Nr. 5091349)

Es ist nicht möglich, ein und dasselbe Software-Paket unter demselben Namen in verschiedenen Pfaden auf unterschiedlichen Hosts zu registrieren, zum Beispiel:


hadbm registerpackage test --packagepath=/var/install1 --hosts europa11
Paket erfolgreich registriert.
hadbm registerpackage test --packagepath=/var/install2 --hosts europa12
hadbm:Fehler 22171: Ein Software-Paket wurde bereits unter dem Paketnamen test registriert.

Lösung

HADB unterstützt keine heterogenen Pfade für Knoten eines Datenbank-Clusters. Stellen Sie sicher, dass das Installationsverzeichnis des HADB-Servers (--packagepath) auf allen teilnehmenden Hosts identisch ist.

createdomain schlägt möglicherweise fehl. (Nr. 6173886, 6253132)

Wenn der Management-Agent auf einem Host mit mehreren Netzwerkschnittstellen ausgeführt wird, kann der Befehl createdomain fehlschlagen, wenn sich nicht alle Netzwerkschnittstellen im selben Teilnetz befinden:


hadbm:Fehler 22020: Die Management-Agents konnten keine
Domäne herstellen. Prüfen Sie, ob die Hosts mit UDP Multicast kommunizieren können.

Die Management-Agenten verwenden (falls nicht anders konfiguriert) die "erste" Schnittstelle für UDP-Multicasts (die "erste" gemäß Definition durch das Ergebnis von java.net.NetworkInterface.getNetworkInterfaces() ).

Lösung

Die beste Lösung besteht darin, dem Management-Agenten vorzuschreiben, welches Teilnetz er verwenden soll (setzen Sie ma.server.mainternal.interfaces in der Konfigurationsdatei, z. B. ma.server.mainternal.interfaces=10.11.100.0). Alternativ kann der Router zwischen den Teilnetzen so konfiguriert werden, dass er Multicast-Pakete weiterleitet (der Management-Agent verwendet die Multicast-Adresse 228.8.8.8).

Bevor Sie einen Versuch mit einer neuen Konfiguration der Management-Agenten unternehmen, müssen Sie eventuell die Management-Agent-Repository bereinigen. Beenden Sie alle Agenten in der Domäne und löschen Sie alle Dateien und Verzeichnisse im Repository-Verzeichnis (wird durch repository.dr.path in der Konfigurationsdatei des Management-Agenten identifiziert). Dies muss auf allen Hosts durchgeführt werden, bevor die Agenten mit einer neuen Konfigurationsdatei erneut gestartet werden.

Verzeichnisse müssen nach dem Löschen einer HADB-Instanz bereinigt werden. (Nr. 6190878)

Nach dem Löschen einer HADB-Instanz schlagen spätere Versuche, neue Instanzen mit dem Befehl configure-ha-cluster zu erstellen, fehl. Das Problem besteht darin, dass alte Verzeichnisse aus der ursprünglichen HADB-Instanz in ha_install_dir/rep/* und ha_install_dir/config/hadb/instance_name übrig bleiben.

Lösung

Achten Sie darauf, diese Verzeichnisse nach dem Löschen einer HADB-Instanz ebenfalls zu löschen.

Starten, Anhalten oder Neukonfiguration von HADB schlagen fehl oder führen dazu, dass das System nicht mehr reagiert. (Nr. 6230792, 6230415)

Unter Solaris 10 Opteron kann das Starten, Stoppen und erneute Konfigurieren der HADB mit dem Befehl hadbm fehlschlagen oder das System nicht mehr reagieren, wobei einer der folgenden Fehler ausgegeben wird:


hadbm:Fehler 22009: Der ausgegebene Befehl erzielte in den letzten 
300 Sekunden keinen Fortschritt.
HADB-E-21070: Der Vorgang konnte innerhalb des Zeitlimits nicht abgeschlossen werden, 
wurde jedoch nicht abgebrochen und wird eventuell zu einem späteren Zeitpunkt abgeschlossen.

Dies tritt u. U. auf, wenn es Unstimmigkeiten hinsichtlich des Lesens/Schreibens in eine Datei (nomandevice) gibt, die vom Prozess clu_noman_srv verwendet wird. Dieses Problem kann erkannt werden, indem in den HADB-Protokolldateien nach den folgenden Meldungen gesucht wird:


n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Untergeordneter Prozess noman3 
733 reagiert nicht.
n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Keine Reaktion von ihm in 
104.537454 Sek.
n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Untergeordneter Prozess noman3 
733 wurde nicht gestartet.

Lösung

Die folgende Problemlösung wurde noch nicht verifiziert, da das Problem noch nicht manuell reproduziert wurde. Jedoch sollte durch Ausführung dieses Befehls für den betroffenen Knoten das Problem gelöst werden.


hadbm restartnode --level=clear nodeno dbname

Beachten Sie, dass alle Geräte für den Knoten neu initialisiert werden. Eventuell müssen Sie den Knoten stoppen, bevor Sie ihn neu initialisieren.

Der Management-Agent wird mit dem Ausnahmefehler "IPV6_MULTICAST_IF fehlgeschlagen" beendet. (Nr. 6232140)

Beim Start auf einem Host, auf dem Solaris 8 ausgeführt wird und verschiedene NIC-Karten installiert sind, kann es passieren, dass bei Vorhandensein einer Mischung von Karten mit aktiviertem IPv6 und IPv4 der Management-Agent beendet wird und der Ausnahmefehler "IPV6_MULTICAST_IF fehlgeschlagen" auftritt."

Lösung

Legen Sie die Umgebungsvariable JAVA_OPTIONS auf -Djava.net.preferIPv4Stack=true fest; zum Beispiel: 


export JAVA_OPTIONS="-Djava.net.preferIPv4Stack=true"

Alternativ verwenden Sie Solaris 9 oder höher. Dort tritt dieses Problem nicht auf.

clu_trans_srv kann nicht unterbrochen werden. (Nr. 6249685)

In der 64-Bit-Version von Red Hat Enterprise Linux 3.0 gibt es einen Bug, der dazu führt, dass der Prozess clu_trans_srv in einem Modus endet, der nicht unterbrochen werden kann, wenn asynchrones I/O ausgeführt wird. Das bedeutet, dass der Befehl kill -9 nicht funktioniert und das Betriebssystem neu gebootet werden muss.

Lösung

Verwenden Sie eine 32-Bit-Version von Red Hat Enterprise Linux 3.0.

hadbm unterstützt keine Passwörter, die Großbuchstaben enthalten. Nr. 6262824)

Großbuchstaben in Passwörtern werden in Kleinbuchstaben umgewandelt, wenn das Passwort in hadb gespeichert wird.

Lösung

Verwenden Sie keine Passwörter, die Großbuchstaben enthalten.

Beim Downgrading von HADB-Version 4.4.2.5 auf HADB-Version 4.4.1.7 schlägt M-A mit verschiedenen Fehlercodes fehl. (Nr. 6265419)

Beim Downgrading auf eine vorherige HADB-Version kann der Management-Agent mit verschiedenen Fehlercodes fehlschlagen.

Lösung

Es ist zwar möglich, einen Downgrade der HADB-Datenbank auszuführen, jedoch kann kein Downgrade für den Management-Agent ausgeführt werden, wenn Änderungen an den Repository-Objekten vorgenommen wurden. Nach einem Downgrade müssen Sie weiter den Management-Agent von der letzten HADB-Version verwenden.

Installation/Deinstallation und symlink-Beibehaltung. (Nr. 6271063)

Hinsichtlich der Installation/Deinstallation des HADB c-Pakets (Solaris: SUNWhadbc, Linux: sun-hadb-c) Version <m.n.u-p> wird symlink /opt/SUNWhadb/<m> niemals angefasst, sobald sie existiert. Daher ist es möglich, dass eine verwaiste symlink vorhanden ist.

Lösung

Löschen Sie symlink vor der Installation oder nach der Deinstallation; es sei denn, die Datei wird verwendet.

Management-Agenten in globalen und lokalen Zonen können stören. (Nr. 6273681)

Unter Solaris 10 wird durch Stoppen eines Management-Agenten mittels Verwendung des ma-initd-Skripts in einer globalen Zone der Management-Agent in der lokalen Zone ebenfalls angehalten.

Lösung

Installieren Sie den Management-Agent nicht sowohl in der globalen als auch der lokalen Zone.

hadbm/ma sollte eine bessere Fehlermeldung ausgeben, wenn ein Sitzungsobjekt die Zeitsperre überschritten hat und bei M-A gelöscht wurde. (Nr. 6275103)

Mitunter kann es durch einen Ressourcenkonflikt auf dem Server dazu kommen, dass der Management-Client getrennt wird. Bei der erneuten Verbindungsherstellung wird u. U. eine irreführende Fehlermeldung "hadbm:Fehler 22184: Zum Herstellen der Verbindung mit dem Management-Agenten ist ein Passwort erforderlich" zurückgegeben.

Lösung

Prüfen Sie, ob ein Ressourcenproblem auf dem Server vorliegt, ergreifen Sie geeignete Maßnahmen (z. B. fügen Sie weitere Ressourcen hinzu) und führen Sie den Vorgang erneut aus.

Nicht-Root-Benutzer können HADB nicht verwalten. (Nr. 6275319)

Die Installation mit Java Enterprise System (als Root) gibt von Root verschiedenen Benutzern keine Benutzerrechte zum Verwalten von HADB.

Lösung

Melden Sie sich immer als Root an, um HADB zu verwalten.

Der Management-Agent sollte keine besonderen Schnittstellen verwenden. (Nr. 6293912)

Schnittstellen für besondere Zwecke mit IP-Adressen wie 0.0.0.0 sollten nicht als gültige Schnittstellen registriert werden, die für HADB-Knoten im Management-Agenten verwendet werden. Die Registrierung solcher Schnittstellen kann zu Problemen führen, wenn an diesen Schnittstellen HADB-Knoten eingerichtet werden, indem ein Benutzer einen hadbm create-Befehl mithilfe von Hostnamen anstelle von IP-Adressen aufruft. Die Knoten können dann nicht kommunizieren und führen dazu, dass der create-Befehl hängt.

Lösung

Wenn Sie hadbm create auf Hosts mit mehreren Schnittstellen verwenden, müssen Sie immer die IP-Adressen angeben, die ausdrücklich die DDN-Notation verwenden.

Reassemblierungsfehler unter Windows. (Nr. 6291562)

Auf der Windows-Plattform kann es bei bestimmten Konfigurationen zu einer großen Anzahl von Reassemblierungsfehlern im Betriebssystem kommen. Das Problem trat bei Konfigurationen von mehr als zwanzig Knoten auf, als mehrere Tabellenscans (select *) gleichzeitig ausgeführt wurden. Symptome können sein, dass die Transaktionen häufig abbrechen, die Reparatur oder Wiederherstellung lange Zeit in Anspruch nehmen kann und es zu häufigen Zeitüberschreitungen an verschiedenen Stellen im System kommt.

Lösung

Um das Problem zu beheben, kann die Windows-Registrierungsvariable HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters auf einen Wert festgelegt werden, der höher ist als der Standardwert 100. Es wird empfohlen, diesen Wert auf 0x1000 (4096) zu erhöhen. Weitere Informationen finden Sie unter. Artikel 811003 der Microsoft-Supportseiten.

Bei der Ausführung von hadbm start <DB-Name> wird ein Teil des eingegebenen Passworts unmaskiert angezeigt. (Nr. 6303581, 6346059, 6307497)

Wenn ein Rechner stark ausgelastet ist, kann es vorkommen, dass der Maskierungsmechanismus versagt, und einige Zeichen des eingegebenen Passworts sichtbar sind. Dies stellt ein gewisses Sicherheitsrisiko dar und das Passwort sollte stets maskiert sein.

Lösung

Legen Sie die Passwörter in eigenen Passwortdateien ab (die normalerweise seit Application Server 8.1 empfohlene Methode) und beziehen Sie sich darauf mit den Optionen --adminpassword bzw. --dbpasswordfile.

Zugriff auf JES5 HADB bei Installation in globaler Zone von lokalen Sparse-Zonen aus nicht möglich (Nr. 6460979)

Wenn Application Server in einer globalen Solaris-Zone unter /usr/SUNWappserver installiert wird, ist die mit dieser Instanz von Application Server installierte HADB-Komponente nicht in lokalen Sparse-Zonen verfügbar.

Das Problem besteht darin, dass HADB unter /opt/SUNWhadb in der globalen Zone installiert wird, dieses Verzeichnis von lokalen Sparse-Zonen aus jedoch nicht lesbar ist. Leider kann das HADB-Bündel in JES5 nicht an einen anderen Ort verlagert werden.

Lösung

Da die HADB-Komponente von Application Server nicht verlagert werden kann, muss sie in jeder lokalen Sparse-Zone aus, von der aus auf HADB zugegriffen werden soll, separat installiert werden.

Installation

In diesem Abschnitt werden die bekannten Installationsprobleme sowie ihre Lösungen beschrieben.

Unter manchen Linux-Systemen reagiert das System bei der Fertigstellung der Installation nach Klicken auf die Schaltfläche "Fertig stellen" nicht mehr. (Nr. 5009728)

Dieses Problem wurde unter verschiedenen Linux-Systemen festgestellt. Am häufigsten kommt das Problem auf Java Desktop System 2 vor. Es wurde jedoch auch bei Distributionen von Linux Red Hat beobachtet.

Nachdem Sie im letzten Fenster des Installationsprogramms auf die Schaltfläche "Fertig stellen" geklickt haben, schlägt der Versuch des Installationsprogramms fehl, die Seite Info bzw. die Seite zur Produktregistrierung im Browser anzuzeigen. Das Programm reagiert nicht mehr und zeigt keine Befehlseingabeaufforderung an.

Lösung

Beenden Sie den Installer durch Drücken von Strg+C im Terminalfenster, in dem der Installer gestartet wurde. Danach wird manchmal ein Browser-Fenster mit einer Produktinfo-Seite oder einer Registrierungsseite angezeigt. Sollte diese Seite nicht angezeigt werden, starten Sie den Browser und geben den folgenden URL ein, um die Infoseite anzuzeigen:


file://Installationsverzeichnis/docs-ee/about.html

Wenn Sie auch noch die Installationsoption zum Registrieren des Produkts gewählt haben, folgen Sie dem Link der Registrierungsseite, der sich auf der Produktinfo-Seite befindet.

Unter Windows muss bei der Installation das imq -Verzeichnis erstellt werden.

Unter Windows schlägt der Message Queue-Boker unmittelbar nach der Installation von Application Server Enterprise Edition beim Starten fehl. Es wird eine Meldung angezeigt, die darauf hinweist, dass das Verzeichnis drive:\as\domains\domain1\imq nicht existiert.

Beachten Sie, dass das Problem nicht auftritt, wenn der Broker nach dem Start von domain1 gestartet wird. In diesem Fall wird das Verzeichnis nach dem Start des Brokers von Application Server erstellt.

Lösung

  1. Erstellen Sie var_home_dir_location, bevor Sie den Broker erstellen.


    $imqbrokerd -varhome var_home_dir_location

    Beispiel:


    $imqbrokerd -varhome D:\as\domains\domain1\imq

Application Server kann auf RHLAS 3.0 und RHLAS 4.0 nicht ohne compat-libstdc++ eingerichtet werden. (ID 6396102)

Die Installation von Application Server Enterprise Edition 8.2 auf einem Red Hat Linux Advanced Server (RHLAS) 3.0- oder 4.0-System schlägt fehl, wenn die Bibliothek compat-libstdc++ nicht bereits auf dem System installiert ist. Application Server macht die Bibliothek compat-libstdc++ auf RHLAS-Systemen erforderlich. Diese Bibliothek ist jedoch nicht standardmäßig installiert. Beachten Sie, dass dieses Problem nur bei RHLAS-Systemen auftritt.

Lösung

Laden Sie das compat-libstdc++-RPM von http://rpm.pbone.net/index.php3/stat/4/idpl/843376/com/compat-libstdc++-7.3-2.96.118.i386.rpm.html herunter und installieren Sie es, bevor Sie die Application Server-Software installieren.

lbplugin (libpassthrough.so ) kann nicht verwendet werden, wenn der Server im 64-Bit-Modus ausgeführt wird (Nr. 6480952)

Bei Ausführung von Application Server Enterprise Edition 8.2 mit Web Server 7.0 im 64-Bit-Modus, scheitert der Versuch, eine 64-Bit-Version des Load Balancer-Plugins auszuführen mit folgender Fehlermeldung:


failure: CORE2253: Error running Init function load-modules: dlopen 
of /export/home/mareks/opt/webserver7/plugins/lbplugin/bin/libpassthrough.so 
failed (ld.so.1: webservd: fatal: /export/home/mareks/opt/webserver7/plugins/
lbplugin/bin/libpassthrough.so: wrong ELF class: ELFCLASS32)
failure: server initialization failed

Das Problem besteht darin, dass es kein 64-Bit-Version des Load Balancer-Plugins für Application Server Enterprise Edition 8.2 gibt und die 64-Bit-Version von Web Server 64-Bit-Plugins erfordert.

Mithilfe des folgenden Befehls können Sie ermitteln, ob Web Server im 64- oder im 32-Bit-Modus ausgeführt wird:


wadm get-config-prop --user=admin --config=xxx --password-file=xxx platform

Lösung

Für Application Server Enterprise Edition 8.2 ist keine 64-Bit-Version des Load Balancer-Plugins geplant. Als Problemumgehung können Sie entweder die Reverse-Proxy-Funktion von Web Server 7.0 verwenden oder Web Server 7.0 für die Ausführung im 32-Bit-Modus konfigurieren. Anweisungen finden Sie in der Web Server-Dokumentation.

Ausführung von asant deploy nicht möglich "Die eingegebene Zeile ist zu lang" (Windows 2000) (Nr. 6485174)

Bei Installation von Application Server 8.2 am Standardspeicherort unter Windows 2000 wird bei der Ausführung von asant deploy folgende Fehlermeldung ausgegeben: 


$ C:/Sun/JavaES5/appserver/bin/asant deploy
Die eingegebene Zeile ist zu lang.
Syntaxfehler.

Das Problem besteht darin, dass Befehlszeilen in Windows 2000 nicht länger sein dürfen als 1000 Zeichen. Je nach der von Ihnen verwendeten Systemkonfiguration kann die standardmäßige ANT_OPTS-Umgebung dazu führen, dass die asant deploy-Befehlszeile zu lang ist. Dieses Problem tritt nur unter Windows 2000 auf.

Lösung

Installieren Sie Application Server unter Windows 2000 in einem sehr kurzen Verzeichnispfad, beispielsweise C:\JES5_AS).

Die Dokumentation zur Herstellung einer physischen Verbindung von einer umschlossenen Verbindung ist nicht mehr korrekt (ID 6486123)

Aufgrund anderer Fehler (vermutlich 6295215) ist der im Abschnitt Obtaining a Physical Connection from a Wrapped Connection in Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide, Kapitel Kapitel 11, Using the JDBC API for Database Access in Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide angegebene Code nicht korrekt. Insbesondere sollte die folgende Zeile:


Connection drivercon = ds.getConnection(con);

nun wie folgt lauten:


Connection drivercon = ((com.sun.gjc.spi.DataSource)ds).getConnection(con);

J2EE Tutorial

Zum Ausführen von J2EE 1.4 Tutorial auf Sun Java System Application Server Enterprise Edition 8.2 führen Sie folgende Schritte aus:

Lifecycle-Verwaltung

In diesem Abschnitt werden die bekannten Probleme der Lifecycle-Verwaltung sowie ihre Lösungen beschrieben.

Nachdem die ejb-timer-service-Eigenschaft minimum-delivery-interval auf 9000 gesetzt wurde, führt ein Versuch, die ejb-timer-service-Eigenschaft redelivery-interval-in-mills auf 7000 zu setzen, dazu, dass der Befehl set fehlschlägt und folgende Fehlermeldung ausgegeben wird: (Nr. 6193449)

[echo] Doing admin task set
[exec] [Attribute(id=redelivery-interval-internal-in-millis) : Redelivery-
Interval (7,000) should be greater than or equal to Minimum-delivery-
interval-in-millis (9,000)]
[exec] CLI137 Command set failed.

Lösung

Verwenden Sie für diese Eigenschaften folgende Standardwerte:

minimum-delivery-interval(default)=7000
redelivery-interval-in-millis(default)=5000

Die Verwendung anderer Werte verursacht einen Fehler.

Protokollierung

In diesem Abschnitt werden die bekannten Protokollierungsprobleme sowie ihre Lösungen beschrieben.

Festlegen einer Debug-Anweisung für access.failure führt dazu, dass das System beim Start von Application Server nicht mehr reagiert. (Nr. 6180095)

Das Setzen der Option java.security.debug für JVM verursacht einen Deadlock in der Server-Startinstanz. Das Problem tritt beispielsweise auf, wenn Sie für domain.xml die Option wie folgt gesetzt haben:

<jvm-options\>-Djava.security.debug=access,failure</jvm-options\>

Lösung

Zu diesem Zeitpunkt steht keine Lösung zur Verfügung. Verwenden Sie diese Option nicht.

Geänderter Protokollspeicherort/Instanzspeicherort für JES3 Application Server. (Nr. 6189409)

Die Standardspeicherorte für Protokollierung und Serverinstanz haben sich in Sun Java System 8.2 im Vergleich zu 7.x geändert.

Weitere Informationen finden Sie im Sun Java System Application Server Enterprise Edition 8.2 Administration Guide oder im Sun Java System Application Server Enterprise Edition 8.2 Upgrade and Migration Guide .

Message Queue

In diesem Abschnitt werden die bekannten Message Queue-Probleme sowie ihre Lösungen beschrieben.

JMS-Verbindung wird in bestimmten, Timing-abhängigen Fällen nicht erfolgreich hergestellt. (Nr. 6173308, 6189645, 6198481, 6199510, 6208728)

Fehler beim erneuten Verbindungsaufbau in Timing-abhängigen Szenarien können durch verschiedene Probleme verursacht werden.

Lösung

Es gibt folgende Problemlösungen:

Das Verhalten des asynchronen Meldungs-Listener in appclient hat sich zwischen 8.0 und 8.1 Update 2 geändert. (Nr. 6198465)

Wenn der einzige Live-Thread im app-client-Container der asynchrone Meldungs-Listener ist, bleibt die übrige appclient-Virtual-Machine als Dämon bestehen. Dieses Verhalten ist eine Regression für alte Anwendungen, die asynchrone Empfänge in ACC ausführen. Dieses Problem beeinträchtigt Anwendungsclients, die einen JMS Message-Listener setzen und den Haupt-Thread beenden.

Lösung

Beenden Sie den Haupt-Thread nicht. Warten Sie, bis der Meldungs-Listener den Haupt-Thread benachrichtigt hat, bevor Sie den Haupt-Thread beenden.

Überwachung

In diesem Abschnitt werden die bekannten Überwachungsprobleme sowie ihre Lösungen beschrieben.

Überwachungsebene von Konnektor-Dienst und Konnektor-Verbindungspool kann nicht geändert werden. (Nr. 6089026)

Wenn Sie auf der Seite zur Festlegung der Überwachungsebene die Protokollierungsebene von Konnektor-Dienst oder Konnektor-Verbindungspool auf NIEDRIG oder HOCH ändern und anschließend speichern, werden beide in der Datei domain.xml für die Domäne nicht geändert. Wenn Sie jedoch die Überwachungsebene des JMS-Dienstes auf NIEDRIG oder HOCH setzen und speichern, werden die Werte für Konnektor-Dienst und Konnektor-Verbindungspool ebenfalls zur gleichen Zeit geändert. Dieses Problem tritt bei der Ausführung der entsprechenden Befehle über die Befehlszeile nicht auf.

Lösung

Ändern Sie die Überwachungesebenen ausschließlich mithilfe des JMS-Dienstes auf der Seite für die Überwachungsebene.

Einige Überwachungsstatistiken des HTTP-Service beinhalten keine nützlichen Informationen und sollten daher ignoriert werden. (Nr. 6174518)

Beim Anzeigen der Überwachungsstatistiken einiger Elemente des HTTP-Service stimmen einige der angezeigten Werte nicht mit den aktuellen Werten überein oder sind immer 0. Insbesondere enthalten die folgenden Statistiken des HTTP-Service keine Informationen bezüglich Application Server und sollten daher ignoriert werden:

MBean zur Überwachung eines nicht bereitgestellten EJB-Moduls wird nicht entfernt, obwohl alle Statistiken unter diesem Überwachungsnamen verschoben wurden. (Nr. 6191092)

Beispiel:


EJBModuleMonitorMap().size() = 1  eventhough ejb module is 
undeployed EJBModuleMonitor().getName() = sqe_ejb_s1_01

Dies gilt sowohl für EJB-Module als auch für EJB-Anwendungen. Die leere überwachende MBean ist sowohl im Programm (MBean API) als auch im Ergebnis des Befehls asadmin list/get weiterhin vorhanden.

Diagnose


asadmin list -m "server.applications" zeigt folgenden Output:
server.applications.MEjbApp
server.applications.__ejb_container_timer_app
server.applications.adminapp
server.applications.admingui
server.applications.com_sun_web_ui
server.applications._export_install_nov-11_domains_domain1_applications
_j2ee-modules_sqe_ejb_s1_01

Prüfen Sie folgende Statistiken:


bin/asadmin list -m "server.applications._export_install_nov-11_domains
_domain1_applications_j2ee-modules_sqe_ejb_s1_01"
server.applications._export_install_nov-11_domains_domain1_applications_
j2ee-modules_sqe_ejb_s1_01.SQEMessage
server.applications._export_install_nov-11_domains_domain1_applications_
j2ee-modules_sqe_ejb_s1_01.TheGreeter

Nachdem die Bereitstellung aufgehoben wurde:


_export_install_nov-11_domains_domain1_applications_j2ee-modules_sqe_
ejb_s1_01

Wenn Sie einen list-Befehl ausführen, werden folgende Anwendungen nach wie vor angezeigt:


asadmin list -m "server.applications"
server.applications.MEjbApp
server.applications.__ejb_container_timer_app
server.applications._export_install_nov-11_domains_domain1_applications_
j2ee-modules_sqe_ejb_s1_01
server.applications.adminapp
server.applications.admingui
server.applications.com_sun_web_ui

Die folgenden Überwachungsstatistiken sind nicht enthalten:


asadmin list -m "server.applications._export_install_nov-11_domains_
domain1_applications_j2ee-modules_sqe_ejb_s1_01"
Nothing to list at server.applications.-export-install-nov-11-domains-
domain1-applications-j2ee-modules-sqe-ejb-s1-01.

Verwenden Sie das Platzhalterzeichen "*", um die gültigen Namen abzurufen, die mit einer Zeichenkette beginnen. Um beispielsweise alle überwachbaren Einheiten aufzulisten, die mit Server beginnen, verwenden Sie die Zeichenfolge list "server.*".

Lösung

Dies ist kein ernsthaftes Problem. Die Bereitstellung des Moduls kann sicher und problemlos aufgehoben werden. Die Mbean zur Root-Überwachung wurde nicht entfernt, sondern ist leer.

PointBase

In diesem Abschnitt werden die bekannten PointBase-Probleme und ihre Lösungen beschrieben.

Das Setzen der Isolationsebenen in einem Verbindungspool für eine Anwendung löst Ausnahmefehler in PointBase aus. (Nr. 6184797)

Für einen JDBC-Verbindungspool, der auf eine PointBase-Datenbankinstallation zeigt, gilt Folgendes: Wenn das Poolattribut transaction-isolation-level auf einen anderen Wert als den Standardwert (Connection.TRANSACTION_READ_COMMITTED) gesetzt wird, tritt ein Ausnahmefehler auf. Wenn jedoch dieser Parameter auf Nicht-Standardwerte für Pools gesetzt wird, die auf andere Datenbanken zeigen, tritt kein Ausnahmefehler auf.

Lösung

Vermeiden Sie die Verwendung des Attributs transaction-isolation-level für einen JDBC-Verbindungspool, der auf eine PointBase-Datenbankinstallation zeigen soll.

PointBase gibt einen Ausnahmefehler aus, wenn Netzwerkserver-Treiber und eingebettete Treiber zusammen verwendet werden. (Nr. 6204925)

Die Paket-PointBase gibt manchmal einen Ausnahmefehler aus, wenn der Netzwerkserver-Treiber und der eingebettete Treiber gleichzeitig verwendet werden.

Lösung

Verwenden Sie entweder den eingebetteten Treiber oder den Netzwerktreiber. Verwenden Sie nicht beide Treiber.

Upgrade-Probleme mit Überschreiben der PointBase-Standarddatenbank. (Nr. 6264969, 6275448)

Beim Upgrade auf Application Server Enterprise Edition 8.2 überschreibt der Patch der Update-Version die standardmäßige Pointbase-Datenbank.

Lösung

Erstellen Sie alle vor dem Upgrade existierenden Schemata neu oder geben Sie diese erneut ein. Wenn Sie Anwendungen mit CMP-Beans über die Option "generate table" bereitgestellt haben, müssen Sie die Bereitstellung der Anwendung aufheben oder die Anwendung erneut bereitstellen, damit die Tabellen erneut generiert werden.

Beispiele

In diesem Abschnitt werden die bekannten Probleme zum Beispielcode der Application Server 8.2-Software und ihre Lösungen beschrieben.

Unter Windows reagiert setup-one-machine-cluster nicht mehr, funktioniert aber unter Solaris; für mqfailover muss Strg+C gedrückt werden, um den Prozess abzubrechen. Dieser muss anschließend erneut ausgeführt werden. (Nr. 6195092)

In install_dir\samples\ee-samples\failover\apps\mqfailover\docs\index.html, wenn Sie folgende Befehle ausführen:

Wenn Sie für ein anderes EE-Beispiel bereits asant setup-one-machine-cluster-without-ha oder asant setup-one-machine-cluster-with-ha ausgeführt haben, führen Sie asant configure-mq aus. Führen Sie anderenfalls asant setup-one-machine-cluster-and-configure-mq aus. Die Meldung zeigt an, dass der Befehl erfolgreich ausgeführt wurde:


start_nodeagent: [echo] Starten des Knoten-Agenten cluster1-nodeagent 
[exec] Befehl start-node-agent erfolgreich ausgeführt.

Das System bleibt jedoch hängen und reagiert nicht mehr.

Lösung

Zu diesem Zeitpunkt steht keine Lösung zur Verfügung. Dieses Problem beeinträchtigt auf ähnliche Weise alle Enterprise Edition-Beispiele, die dieses ant-Ziel unter Windows verwenden. Zur Problemlösung drücken Sie Strg+C, um den nicht mehr reagierenden Prozess zu beenden, und führen Sie ihn dann erneut aus.

In der Dokumentation fehlt in den asadmin-Bereitstellungsanweisungen der ausdrückliche Hinweis, dass JMS-Ressourcen vor der Ausführung von MQ Failover Sample Application erstellt werden müssen. (Nr. 6198003)

Folgender Fehler wird ausgegeben:


/opt/SUNWappserver/domains/domain1/config/sun-acc.xml -name 
MQFailoverTestClient -textauth -user j2ee -password j2ee
Nov 18, 2004 10:50:17 PM com.sun.enterprise.naming.NamingManagerImpl 
bindObjects
SEVERE: NAM0006: JMS-Zielobjekt nicht gefunden: jms/durable/TopicA
Nov 18, 2004 10:50:18 PM com.sun.enterprise.naming.NamingManagerImpl 
bindObjects
SEVERE: javax.naming.NameNotFoundException
javax.naming.NameNotFoundException

In der Dokumentation wird nicht ausdrücklich erwähnt, dass bei einer manuellen Bereitstellung mit den Befehlen asadmin deploy JMS-Ressourcen manuell erstellt und die vorgegebenen ant-Ziele für das Bereitstellen derselben Software verwendet werden müssen.

Lösung

Verwenden Sie für das Skript build.xml das Ziel asant-Bereitstellung. Das Skript erstellt die für die Ausführung der Anwendung erforderlichen JMS-Ressourcen.

Unter Linux wird bei der Zertifikaterstellung von Beispielen in webservices/security ein Laufzeitfehler angezeigt. (Nr. 6198239)

Wenn Sie das Beispiel install_dir/samples/webservices/security sample (basicSSl) unter Linux bereitstellen, wird das Zertifikat nicht erstellt und ein Fehler ausgegeben, der etwa dem Folgenden entspricht:


generate_certs: [echo] ***Export des Zertifikats von der NSS-Datenbank 
[exec] Ergebnis: 1 [echo] ***Erzeugen eines Java-Schlüsselspeichers anhand 
des generierten Zertifikats [exec] Keytool-Fehler: java.lang.Exception: Input kein
X.509-Zertifikat [exec] Ergebnis: 1 [echo] ***Erzeugen eines Java-
Vertrauensspeichers anhand des generierten Zertifikats [exec] Keytool-Fehler: 
java.lang. Ausnahmefehler: Input kein X.509-Zertifikat [exec] Ergebnis: 1
.
.
.
generate_certs: [echo] ***Export des Serverzertifikats von der NSS-Datenbank in 
eine PKCS12-Zertifikatdatei [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/
libnss3.so: Version `NSS_3.9' nicht gefunden (von /opt/sun/appserver/lib/
pk12util gefordert) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: 
Version `NSS_3.6' nicht gefunden (von /opt/sun/appserver/lib/pk12util gefordert) 
[exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: Version 
`NSS_3.7' nicht gefunden (von /opt/sun/appserver/lib/pk12util gefordert) [exec] 
Ergebnis: 1

Das Problem besteht darin, dass sich NSS-Bibliotheken bei Linux-Installationen in anderen Pfaden befinden als bei Solaris-Installationen. Bei der Bereitstellung unter Linux müssen Sie sicherstellen, dass LD_LIBRARY_PATH auf die richtigen NSS-Bibliotheken verweist. Setzen Sie die Variable LD_LIBRARY_PATH entweder in Ihrer Umgebung oder im Shell-Wrapper-Skript Installationsverzeichnis/bin/asant.

Lösung

Gehen Sie folgendermaßen vor:

Beispieldokumente fehlen nach Aufrüstung von 8.0 Platform Edition auf 8.2 Enterprise Edition

Nach der Aktualisierung von Application Server Platform Edition 8.0 auf Application Server Enterprise Edition 8.2 erhalten Sie möglicherweise beim Versuch, auf die Beispielseiten zuzugreifen, die Fehlermeldung HTTP 404 (Datei nicht gefunden).

Lösung

Kopieren Sie die Beispieldokumente aus den 8.0-Domänen in die 8.2-Domänen.

Beispiele scheitern während der Laufzeit bei Ausführung in einer lokalen Sparse-Zone. (Nr. 6460970)

Wenn Application Server Enterprise Edition 8.2 in einer globalen Solaris-Zone installiert ist und anschließend eine Application Server-Domäne in einer lokalen Sparse-Zone installiert wird, stoßen Sie möglicherweise auf Probleme bei der Ausführung der Beispielanwendungen, wenn die Dateiberechtigungen für die Domäne in der Sparse-Zone während des Bereitstellungsprozesses nicht offen genug sind.

Lösung

Stellen Sie während des Bereitstellungsprozesses sicher, dass Application Server die Client-JAR-Datei, xmsClient.jar, abrufen und an den Speicherort für Beispieldateien (/usr/SUNWappserver/appserver/samples/webservices/security/ejb/apps/xms/xmsClient.jar ) kopieren kann. Dies erfolgt normalerweise automatisch über die Beispielsequenz. Der Vorgang scheitert jedoch, wenn die Berechtigungen unter xmsClient.jar nicht offen sind.

Sicherheit

In diesem Abschnitt werden die bekannten Probleme und ihre Lösungen von Sicherheitsfunktionen in Application Server, Webanwendungen sowie Zertifikaten beschrieben.

Fehler beim Ausführen von WebServiceSecurity-Anwendungen bei Enterprise Edition mit J2SE 5.0. (Nr. 6183318)

WebServiceSecurity-Anwendungen können aus folgendem Grund nicht mit J2SE 5.0 ausgeführt werden:

Das J2SE-Team hat "CR 6190389: Add support for the RSA-PKCS1 and RSA-OAEP wrap/unwrap mechanisms" für die Behebung dieses Fehlers bereitgestellt.

Lösung

Verwenden Sie J2SE 1.4.2 mit einem anderen JCE-Provider (und nicht mit dem enthaltenen Standard-Provider). Beachten Sie, dass bei dieser Konfiguration kein Software-Beschleuniger unterstützt wird.

SSL-Beendigung funktioniert nicht. (Nr. 6269102)

Wenn Load Balancer (Hardware) für die SSL-Beendigung konfiguriert ist, ändert Application Server das Protokoll während der Umleitung von https zu http.

Lösung

Fügen Sie zwischen dem Hardware-Lastausgleich und Application Server einen Software-Lastausgleich hinzu.

Aufrüsten

In diesem Abschnitt werden die bekannten Probleme beim Aufrüsten sowie ihre Lösungen beschrieben.

Domänen, die in einem anderen custom-path Installationsverzeichnis als /domains erstellt werden, werden beim Aufrüsten von Application Server Enterprise Edition 8 auf Application Server Enterprise Edition 8.2 nicht direkt aktualisiert (Nr. 6165528).

Wenn Sie das Programm zum Aufrüsten ausführen und dabei das Installationsverzeichnis als Quellverzeichnis für die Installation angeben, werden beim Aufrüsten nur die Domänen aktualisiert, die sich im Verzeichnis Installationsverzeichnis /domains befinden. Für in anderen Pfaden erstellte Domänen wird kein Upgrade durchgeführt.

Lösung

Kopieren Sie alle Domänenverzeichnisse aus den jeweiligen Speicherorten in das Verzeichnis Installationsverzeichnis/ /domains, bevor Sie den Prozess zum Aufrüsten ausführen.

Das Installationsprogramm, das "Upgrade in place" ausführt, kann das Aufrüstungstool auf einigen Linux-Systemen nach dem Klicken auf die Schaltfläche "Start Upgrade Wizard" nicht starten. (6207337)

Dieses Problem ist unter verschiedenen Linux-Systemen aufgetreten und wurde am häufigsten unter Java Desktop System 2 beobachtet. Von dem Problem sind jedoch auch RedHat-Versionen betroffen.

Wenn Sie auf der letzten Seite des Installationsprogramms auf die Schaltfläche "Start Upgrade Tool" klicken, wird das Aufrüstungstool nicht gestartet und der Aufrüstungsvorgang nicht abgeschlossen. Das Aufrüstungstool reagiert nicht mehr und gibt keine Eingabeaufforderung aus.

Lösung

Dieses Problem tritt nicht auf, wenn das In-Place-Upgrade im Befehlszeilen-Installationsmodus ausgeführt wird.

ProcedureSo verwenden Sie den Befehlszeilen-Installationsmodus:

  1. Wenn Sie das In-Place-Upgrade im Benutzeroberflächenmodus ausführen und dieses Problem auftritt, beenden Sie das Installationsprogramm, indem Sie in dem Terminal-Fenster, von dem aus das Installationsprogramm gestartet wurde, STRG+C drücken.

  2. Starten Sie das Upgrade-Tool vom Terminal-Fenster aus, indem Sie folgenden Befehl eingeben: 


    Installationsverzeichnis/bin/asupgrade --source Installationsverzeichnis/domains --target Installationsverzeichnisr 
--adminuser adminuser--adminpassword adminpassword --masterpassword changeit

    Die Werte für Administrator und Administratorpasswort müssen mit den Werten übereinstimmen, die in der aufzurüstenden Installation verwendet werden.

  3. Wenn das Upgrade-Tool den Upgrade-Prozess beendet hat, können Sie auch den Browser starten und den folgenden URL eingeben, um die Infoseite anzuzeigen:

    file://Installationsverzeichnis/docs/about.html

    Wenn Sie auch noch die Installationsoption zum Registrieren des Produkts gewählt haben, folgen Sie dem Link der Registrierungsseite, der sich auf der Produktinfo-Seite befindet.

Das selbst signierte Zertifikat wird während und nach einem Upgrade von 8.0 Platform Edition (PE) zu 8.1 Enterprise Edition (EE) UR2 nicht als vertrauenswürdig erkannt. (Nr. 6296105)

Entfernen Sie die folgenden Einträge aus der Zieldatei domain.xml (nach dem Upgrade) und starten Sie den Server neu:

<jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}
/config/keystore.jks</jvm-options>-
<jvm-options>Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}
/config/cacerts.jks</jvm-options>

Portkonflikt nach Aufrüstung von Application Server von JES2 auf JES5

Bei der Aktualisierung von Application Server 7.x auf 8.2 tritt möglicherweise ein Portkonflikt zwischen der alten und neuen Installation auf, höchstwahrscheinlich mit den Standardports 8080 und 8181.

Lösung

Ändern Sie die in Application Server 8.2 verwendeten Ports zur Auflösung des Portkonflikts.

Als Beispielskript verwendete Derby-Datenbank wird am falschen Speicherort erstellt. (Nr. 6377804)

Dieser Fehler weist zwei Aspekte auf:

  1. Wenn die Setup-Skripts der Beispielanwendung, die die Derby-Datenbank verwenden, ausgeführt werden, wird die Derby-Datenbank unter dem aktuellen Verzeichnis oder unter <install_root>/bin erstellt.

  2. Das Ant-Beispielscript für build erstellt die Datei password.txt, mit der die Admin-Passwort-Datei unter dem aktuellen Verzeichnis gespeichert wird. Diese ist jedoch in Nicht-Root-Szenarios und Szenarios mit Sparse-Zones nicht beschreibbar.

Lösung

  1. Speicherort der Derby-Datenbank – Verwenden Sie die Option --dbhome mit dem Befehl start-database, um die Datenbank mit dem für --dbhome angegebenen Wert zu erstellen. Die asadmin-Befehlssyntax für start-database lautet beispielsweise wie folgt:


    start-database [--dbhost 0.0.0.0] [--dbport 1527] [--dbhome db_directory] [--echo=false] 
[--verbose=false]

  2. Speicherort der Datei password.txt – Naturgemäß sollte das Beispielverzeichnis beschreibbar sein, da alle Build-Befehle die Erstellungen der Datei password.txt in diesem Verzeichnis beinhalten. Achten Sie darauf, dass eine Arbeitskopie der Beispiele an einem beschreibbaren Speicherort installiert wird.

LoginException während Aufrüstung von 8.0UR1PE auf 8.2EE; Aufrüstungsvorgang wird abgebrochen (Nr. 6445419)

Dieses Problem tritt auf, wenn die Aufrüstungsinstallation unter Verwendung anderer Administrator-Anmeldeinformationen als der Standarddaten ausgeführt wird.

Lösung

Bei Durchführung einer Side-by-Side-Aufrüstung unter Verwendung des dateibasierten Installationsprogramms für 8.xPE auf 8.2EE müssen Sie folgende Administrator-Anmeldeinformationen für die neue Instanz von Application Server verwenden:

Nach der Durchführung der Aufrüstung können Sie diese Passwörter nach Bedarf ändern.

Das Aufrüstungstools erkennt bestehende, aber ungültige Verzeichniseingaben für das Quellverzeichnisfeld nicht (Nr. 6460122)

Das Aufrüstungstool erkennt eine bestehende, aber ungültige Verzeichniseingaben für das Quellverzeichnisfeld nicht und vermittelt den Eindruck, dass die Verzeichniskonfiguration korrekt ist.

Es wäre zu erwarten, dass eine Meldung der Art "Verzeichnis ungültig" angezeigt wird, wenn ein falscher Pfad für das Quellverzeichnis eingegeben wird. Ein Meldung über ein ungültiges Verzeichnis wird korrekterweise angezeigt, wenn als Quellverzeichnis /opt/SUNWappserverEE81UR2/ eingegeben wird. Wenn jedoch /opt/SUNWappserverEE81UR2/domains eingegeben wird, fährt das Tool ohne Warnung mit dem Aufrüstungsprozess fort, auch wenn der Pfad ungültig ist. Dieses Problem ähnelt dem unter Nr. 6440710 beschriebenen Problem, mit der Ausnahme, dass das Verhalten je nach Eingabewert abweicht.

Lösung

Bei der Aufrüstung von Application Server 7 oder 8.x auf Application Server 8.2 muss zunächst ein Seeding des Quellverzeichnisses mit dem in der Dokumentation empfohlenen Wert durchgeführt werden: Domänen-Root für In-Place- und Domänenverzeichnis für Side-By-Side-Aufrüstungen.

Admin-Benutzer/-Passwort-Name sollte ungültig sein bei Semikolon (;) (Nr. 6473341)

Die Application Server Enterprise Edition 8.2-Installation lässt keine Sonderzeichen im Namen des Admin-Benutzers zu. Die Domänenerstellung schlägt fehl, wenn Sonderzeichen verwendet werden. Beachten Sie jedoch, dass das Admin-Passwort Sonderzeichen enthalten darf.

Lösung

Vergewissern Sie sich bei der Aufrüstung von Application Server 7 auf Application Server 8.2, dass der Name des Admin-Benutzers keine Sonderzeichen enthält.

Webcontainer

In diesem Abschnitt werden die bekannten Probleme mit Webcontainern sowie ihre Lösungen beschrieben.

Wird unter Windows eine Anwendung mit --precompilejsp=true bereitgestellt, können JAR-Dateien der Anwendung gesperrt werden, sodass das Aufheben der Bereitstellung oder eine neue Bereitstellung zu einem späteren Zeitpunkt nicht möglich ist. (Nr 5004315)

Wenn Sie beim Bereitstellen einer Anwendung unter Windows eine Vorkompilierung der JSPs anfordern, funktionieren spätere Versuche zum Aufheben der Bereitstellung dieser Anwendung oder zum erneuten Bereitstellen der Anwendung (oder einer anderen Anwendung mit derselben Modul-ID) nicht wie erwartet. Das Problem liegt darin begründet, dass durch die JSP-Vorkompilierung JAR-Dateien in Ihrer Anwendung geöffnet, jedoch nicht wieder geschlossen werden, und Windows verhindert, dass zur Aufhebung der Bereitstellung diese Dateien gelöscht oder zur erneuten Bereitstellung diese Dateien überschrieben werden.

Beachten Sie, dass das Aufheben der Bereitstellung erfolgreich durchgeführt wird, bis die Anwendung aus Application Server logisch entfernt wird. Außerdem gibt das asadmin-Programm keine Fehlermeldung aus, obwohl das Anwendungsverzeichnis und die gesperrten JAR-Dateien auf dem Server weiterhin vorhanden sind. Die Protokolldatei des Servers enthält jedoch Fehlermeldungen, die Sie über den fehlgeschlagenen Löschvorgang der Dateien und des Verzeichnisses der Anwendung informieren.

Die Versuche zum erneuten Bereitstellen der Anwendung nach der Aufhebung der Bereitstellung schlagen fehl, da der Server versucht, die vorhandenen Dateien und Verzeichnisse zu entfernen, was ebenfalls nicht möglich ist. Dieser Fehler tritt beispielsweise auf, wenn Sie versuchen, eine Anwendung mit der Modul-ID der ursprünglich bereitgestellten Anwendung bereitzustellen, da der Server die Modul-ID für die Auswahl eines Verzeichnisses für das Speichern der Dateien der Anwendung verwendet.

Aus demselben Grund schlägt auch der Versuch fehl, die Anwendung erneut bereitzustellen, ohne dass die Bereitstellung zuvor aufgehoben wurde.

Diagnose

Wenn Sie die Anwendung erneut bereitstellen möchten oder die Anwendung bereitstellen möchten, nachdem Sie die Bereitstellung der Anwendung zuvor aufgehoben haben, gibt das asadmin-Programm eine Fehlermeldung aus, die etwa der folgenden Meldung entspricht:


Beim Ausführen des Befehls ist ein Ausnahmefehler aufgetreten. 
Die Ausnahmemeldung lautet: CLI171 Bereitstellung des Befehls 
fehlgeschlagen: Bereitstellung der Anwendung in der Domäne 
fehlgeschlagen; Bereitstellung nicht möglich. Modulverzeichnis ist gesperrt 
und kann nicht gelöscht werden.

Lösung

Wenn Sie bei der Bereitstellung einer Anwendung --precompilejsps=false (die Standardeinstellung) festlegen, tritt dieses Problem nicht auf. Beachten Sie, dass beim ersten Aufruf der Anwendung die JSP-Kompilierung ausgelöst wird, sodass die Antwortzeit für den ersten Aufruf länger ist als für folgende Aufrufe.

Beachten Sie weiterhin, dass Sie im Falle einer Vorkompilierung den Server stoppen und erneut starten müssen, bevor Sie die Bereitstellung der Anwendung aufheben oder die Anwendung erneut bereitstellen. Durch den Prozess des Herunterfahrens werden die gesperrten JAR-Dateien wieder freigegeben, sodass die Aufhebung der Bereitstellung oder die erneute Bereitstellung nach dem Neustart erfolgreich ist.

WAR kann nicht mit Servlet 2.4-basierter Datei web.xml, die ein leeres <load-on-startup>-Element enthält, bereitgestellt werden. (Nr. 6172006)

Das optionale load-on-startup servlet-Element in der Datei web.xml gibt an, dass das zugehörige Servlet als Teil des Startvorgangs der die Deklaration ausführenden Webanwendung geladen und initialisiert werden muss.

Für dieses Element kann optional eine ganze Zahl angegeben werden, mit der festgelegt wird, in welcher Reihenfolge das Servlet mit Bezug auf die anderen Servlets der Anwendung geladen und initialisiert werden soll. Wenn für <load-on-startup> kein Wert angegeben ist, wird keine bestimmte Reihenfolge berücksichtigt und es wird lediglich festgelegt, dass das Servlet beim Start der entsprechenden Webanwendungen geladen und initialisiert wird.

Das Servlet 2.4-Schema für web.xml unterstützt keine leere <load-on-startup> mehr; dies bedeutet, dass bei Verwendung einer Servlet 2.4-basierten web.xml eine Ganzzahl angegeben werden muss. Wenn eine leere <load-on-startup> angegeben wurde, wie in <load-on-startup/>, schlägt die Validierung von web.xml basierend auf dem Servlet 2.4-Schema für web.xml fehl, wodurch die Bereitstellung der Webanwendung fehlschlägt.

Rückwärtskompatibilität: Die Angabe eines leeren <load-on-startup>-Elements ist mit Servlet 2.3-basierten web.xml-Dateien nach wie vor möglich.

Lösung

Geben Sie <load-on-startup>0</load-on-startup> an, wenn Sie eine Servlet 2.4-basierte web.xml-Datei verwenden, um anzugeben, dass die Servlet-Lastenreihenfolge irrelevant ist.

JSP-Seite kann auf Servern mit geringen Ressourcen nicht kompiliert werden (Nr. 6184122)

Der Zugriff auf die JSP-Seite erfolgt, aber die eigentliche Kompilierung wird durchgeführt und das Serverprotokoll enthält die Fehlermeldung "Unable to execute command" mit folgenden Stapelverlaufsinformationen:


at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.
exec(Execute.java:655) at org.apache.tools.ant.taskdefs.Execute.
launch(Execute.java:416) 
at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:427) 
at org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.
executeExternalCompile(DefaultCompilerAdapter.java:448) 
at org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute
(JavacExternal.java:81) 
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842) 
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682) 
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:396)

Lösung

Setzen Sie den Schalter für die JSP-Kompilierung fork auf false.

Wählen Sie eine der folgenden Vorgehensweisen:

Diese Einstellung verhindert, dass ant neue Prozesse für die javac -Kompilierung erzeugt.

Application Server unterstützt nicht das Add-On auth-passthrough von Web Server 6.1. (Nr. 6188932)

Sun Java System Application Server Enterprise Edition 8.2 fügt Unterstützung für die Funktionalität hinzu, die durch das Plulgin auth-passthrough bereitgestellt wird, das in Sun Java System Application Server Enterprise Edition 7.1 enthalten ist. In Application Server Enterprise Edition 8.2 ist jedoch die Plugin-Funktion auth-passthrough anders konfiguriert.

Die Funktion des Plugins auth-passthrough in Application Server Enterprise Edition 7.1 hat sich in zweischichtigen Bereitstellungsszenarien als nützlich erwiesen, für die Folgendes gilt:

In derartigen Netzwerkarchitekturen stellen Clients eine Verbindung mit einem Front-End-Webserver her, der mit der Plugin-Funktion service-passthrough konfiguriert wurde, und leiten HTTP-Anforderungen zum Verarbeiten an die Proxy-Instanz von Application Server weiter. Die Instanz von Application Server kann lediglich Anforderungen vom Proxy-Webserver erhalten. Direkte Anforderungen von Client-Hosts sind nicht möglich. Folglich erhalten alle auf der Proxy-Instanz von Application Server bereitgestellten Anwendungen, die Client-Informationen, wie z. B. die IP-Adresse des Clients, abfragen, die IP des Proxy-Hosts, da dies der tatsächliche Ursprungs-Host der weitergeleiteten Anforderung ist.

In Application Server Enterprise Edition 7.1 kann die Funktion des Plugins auth-passthrough auf der Proxy-Instanz von Application Server konfiguriert werden, um die Informationen des Remote-Clients allen auf ihm bereitgestellten Anwendungen direkt zur Verfügung zu stellen, als ob die Proxy-Instanz von Application Server die Anfrage auf direkte Weise und nicht über einen intermediären Webserver erhalten hätte, auf dem das Plugin service-passthrough ausgeführt wird.

In Application Server Enterprise Edition 8.2 kann die Funktion auth-passthrough aktiviert werden, indem die Eigenschaft authPassthroughEnabled des Elements <http-service> in der Datei domain.xml wie folgt auf TRUE gesetzt wird:


<property name="authPassthroughEnabled" value="true"/>

Dieselben Sicherheitserwägungen für die Funktion des Plugins auth-passthrough in Application Server Enterprise Edition 7.1 gelten auch für die Eigenschaft authPassthroughEnabled in Application Server Enterprise Edition 8.2. Da authPassthroughEnabled ermöglicht, Informationen zu umgehen, die für Authentifizierungszwecke verwendet werden können (wie z. B. die IP-Adresse, von der die Anforderung ausging, oder das SSL-Clientzertifikat), ist es erforderlich, dass nur vertrauenswürdigen Clients oder Servern das Recht gewährt wird, eine Verbindung mit einer Instanz von Application Server Enterprise Edition 8.2 herzustellen, wenn authPassthroughEnabled auf TRUE gesetzt ist. Als Vorsichtsmaßnahme wird empfohlen, dass nur Server hinter der firmeneigenen Firewall mit dem auf TRUE gesetzten Befehl authPassthroughEnabled konfiguriert werden. Ein Server, der über das Internet aufgerufen werden kann, darf niemals mit dem auf TRUE gesetzten Befehl authPassthroughEnabled konfiguriert werden.

Beachten Sie, dass in dem Fall, wenn ein Proxy-Webserver mit dem Plugin service-passthrough konfiguriert wurde und Anforderungen an eine Instanz von Application Server 8.1, Update 2 mit dem auf TRUE gesetzten Befehl authPassthroughEnabled weiterleitet, die SSL-Clientauthentifizierung auf dem Webserver-Proxy aktiviert sowie auf der Proxy-Instanz von Application Server 8.1, Update 2 deaktiviert werden kann. In diesem Fall behandelt die Proxy-Instanz von Application Server 8.1, Update 2 die Anforderung immer noch so, als wäre diese per SSL authentifiziert worden und stellt das SSL-Zertifikat des Clients allen bereitgestellten Anwendungen zur Verfügung, wenn diese es anfordern.

Bei der Erstellunge eines HTTP-Listener mit --enabled=false ist der Listener nicht deaktiviert. (Nr. 6190900)

Wenn ein httplistener mit dem Flag --enabled=false erstellt wird, wird der Listener dennoch nicht deaktiviert. Das Flag --enabled bleibt ohne Wirkung, wenn es gleichzeitig mit der Erstellung eines Listeners verwendet wird.

Lösung

Erstellen Sie den Listener im aktivierten Zustand und deaktivieren Sie ihn später manuell.

Erneute Bereitstellung unter Windows scheitert, da verify_file_user_exists_common nicht ausgeführt wird. (Nr. 6490227)

Wenn unter Windows eine Anwendung erneut bereitgestellt wird, die vor der Bereitstellung einen Benutzer erstellt, schlägt der Befehl create-file-user möglicherweise fehl, da verify_file_user_exists_common nicht ausgeführt wird (obwohl er aufgerufen wird) und nicht meldet, dass der Benutzer bereits vorhanden ist. Die Ausführung des deploy-Ziels wird an diesem Punkt abgebrochen und die Bereitstellung bzw. die Aufhebung der Bereitstellung scheitert.

Lösung

Löschen Sie zuerst die Dateibenutzer, die das keydel-Ziel verwenden und führen Sie dann das deploy-Ziel erneut aus:


asant keydel
asant deploy