07.10.2009
14:21

Der lästige Knoten im Webserver

von Roman Seibold
Sie erinnern sich an meinen Beitrag zur Property-File-basierten Konfiguration von WebSphere Application Server V7. Bei weiteren Erkundungen zu diesem Thema habe ich mein Interesse auch auf eine ganze WebSphere-ND-Zelle ausgeweitet, die wie folgt aufgebaut ist:

was70host00Cell01 

+ was70host00CellManager01 @ was70host00
### dmgr

+ was70host00Node01 @ was70host00
### nodeagent
### server2

+ was70host01Node01 @ was70host01
### nodeagent
### server1

+ ihsnode @ was70host01
### webserver1

Es waren also zwei Rechnerknoten was70host00 und was70host01 im Einsatz. Auf Host 0 läuft der Deployment-Manager und ein Server, auf Host 1 läuft der andere Server und der WebServer (IBM HTTP Server). Das ist natürlich keine Produktionsumgebung.

Nun besorge man sich mit wsadmin die Konfiguration als Property-File:

AdminTask.extractConfigProperties(
'-propertiesFileName cell.props')

Egal was man jetzt macht, auch wenn keine Änderungen durchgeführt werden und man sofort nach Erhalt der Datei die Validierung versucht:

AdminTask.validateConfigProperties(
'-propertiesFileName cell.props')

erntet man einen Fehler. Oder, besser gesagt, ernte ich einen Fehler.

 

WASX7015E: Exception running command: 
[...]
ADMA5025E:
The ObjectName format is incorrect for WebSphere:
cell,node=ihsnode,server=webserver1.

 

Offenbar stimmt irgendetwas mit dem Namen des WebServers oder seines Verwaltungsknotens nicht. Leider bekommt man nirgendwo genaueren Aufschluß auf die präzise Ursache des Fehlers. Das von mir bereits dargestellte Report-File funktioniert nicht, weil dieses bei Exceptions nicht
geschrieben wird. SystemOut.log und SystemErr.log enthalten leider keine genaueren Angaben. Die Datei wsadmin.traceout enthält einige Ausgaben, die bei Extrahierung und Validierung anfallen, aber leider nicht die Zeilennummer derjenigen Zeile oder Zeilen, die das Problem verursachen.

 

Nach zahlreichen Versuchen, die Konfiguration so hinzubekommen, dass die Validierung durchläuft, kam ich zum folgenden Schluß:

 

1. Egal, wie der Webserver-Knoten heisst (der Administration von WebSphere ist das im übrigen sowieso völlig Wurst, ich habe "ihsadmin", "remoteHTTPServer" und "webserver1" probiert), die Validierung schlägt fehl.

2. Wenn man den Webserver und seinen Administrationsknoten aus der Zelle nimmt, die Konfiguration erneut exportiert und dann validiert, läuft alles ohne Probleme.

3. Es handelt sich höchstwahrscheinlich nicht um ein Feature, sondern um einen Bug.

Meine aktuelle Konfiguration war Linux, 32-Bit, und WebSphere Application Server ND 7.0.0.5.
Der HTTP-Server hat die Version 7.0.0.0, ebenso das Plugin.

Vielleicht hat schon ein geneigter Leser ein ähnliches Problem gehabt und es lösen können?
Sobald mir neue Informationen vorliegen, werde ich diese als Kommentar natürlich gerne weitergeben. Ein nächstes, vorerst letztes Experiment, wird darin bestehen, Plugin und WebServer als Präsent ein Fixpack zu verpassen.

 

Solange verbleibe ich mit administrativen Grüßen, Ihr

Roman Seibold

  •  
  • 1 Kommentare
  •  
Roman Seibold
12.10.2009
Der lästige Knoten im WebServer 2.0

Als Nachtrag: auch mit einem Update auf HTTP-Server und Plugin (jeweils die passende Version 7.0.0.5) hat sich nichts geändert.
Erwartungsgemäß, da die Problematik ja meines Erachtens am Master-Repository und/oder Property-based Configuration liegt und das sitzt nun mal am Deployment-Manager und nicht an einem entfernten Knoten.

Mein Kommentar

Zurück