Wie man den Java-Heap-Space in der Websphere repariert, wenn ich ein ungültiges XML sende

Ich habe versucht, das selbst zu beheben. Ich untersuchte, wie spring-ws xml validiert und es vor der Websphere versucht hat. Hier ist Code. Ich teste es und es funktioniert für mich.

und im Zusammenhang mit dem Frühling füge ich hinzu:

Der beste Weg besteht darin, den Spring-Payloadinterceptor zu verwenden, um das eingehende XML gegen das XML-Schema zu validieren, bevor es weiter analysiert werden kann ... Beispielcode:

Weitere Einzelheiten finden Sie in der Frühjahrs Dokumentation

Sie haben gerade einen Fehler gefunden. Bitte melden Sie den Fehler. Da dies mit dem Parsen zusammenhängt. Sie können zwei Dinge tun.

Zunächst können Sie einen Speicherabzug erstellen. Speicher einfach ab (oder profile dies mit visualvm und führe ein Speicherprofil aus). Auf diese Weise verstehst du, was den Speicher verschmutzt.

Zweitens können Sie das Problem beheben, das Sie gefunden haben. Ich mache es mit dem Code von Drittanbietern. Bevor Sie also mit der Analyse des Snippets beginnen, prüfen Sie noch einmal, ob das XML korrekt ist, ohne nach Shema zu suchen. Verwenden Sie einfach einen Parser, der ohne Shema ausgeführt wird.

Um eine modifizierte Implementierung bereitzustellen, verwenden Sie den Quellcode oder, falls nicht verfügbar, dekompilieren Sie ihn oder benennen Sie die Klasse um und stellen Sie eine neue Implementierungsklasse zur Verfügung, die sich von dieser aus erstreckt. Wenn es sich um eine private Methode oder Funktion handelt, müssen Sie nur den Byte-Code ändern.

Um Ihre Version zu injizieren, fügen Sie einfach Ihre Klasse Ihrem Klassenpfad (oder dem Klassenpfad der Websphere) hinzu und legen Sie sie davor. Normalerweise ist Ihr Code für jeden Bibliothekscode vorangestellt. Auf diese Weise können Sie jedes Implementierungsdetail einer Bibliothek überschreiben, solange Sie den Klassenpfad steuern (normalerweise durch Festlegen in der Datei java.exe.

Fügen Sie also einfach einen zusätzlichen Test auf Korrektheit hinzu, bevor diese abgemahnte Version ausgegeben wird. Und melden Sie den Fehler und bloggen Sie darüber.

Wenn Sie Fragen haben oder ein Werkzeug benötigen, fragen Sie einfach. Ich mache das regelmäßig. Mit Open-Source- und nicht-Open-Source-Software. Auch gut für andere Dinge wie das Erweitern von Features.

Nach Martin rate ich versuchen, den ibm-Code zu dekompilieren und ich denke, das Problem ist in diesem Verfahren:

Problemabschnitt:

Das sieht wie ein Websphere Bug aus. Mit Spring-WS habe ich einen Fehler bekommen:

  

java.lang.OutOfMemoryError: Java-Heapspeicher           unter com.ibm.ws.webservices.utils.BAIS.create (BAIS.java:74)

Ich habe es geschafft, diesen Weg zu finden: put in / AppServer / lib / ext diese Bibliothek: axis2-saaj-1.6.2.jar (arbeitete für mich auf Websphere v8.5 und Spring-WS v2.2.0, aber Sie können muss die Version ändern).

Erläuterung

Wenn Spring-WS nach einer javax.xml.soap.MessageFactory-Implementierung fragt, wird eine com.ibm.ws.webservices.engine.soap.MessageFactoryImpl-Instanz (aus WebSphere-Laufzeitumgebung) anstelle von com.sun.xml.internal abgerufen .messaging.saaj.soap.MessageFactoryImpl-Instanz (von JVM), was zu dem erwähnten Fehler führt. Die axis2-saaj-Bibliothek enthält auch eine javax.xml.soap.MessageFactory-Implementierung: org.apache.axis2.saaj.MessageFactoryImpl. Dieser wird jetzt verwendet, wenn sich axis2-saaj im Ordner lib / ext befindet und der Fehler weg ist (Ich habe auch PARENT LAST classpath konfiguriert, weiß nicht, ob es hier eine Rolle spielt)

Aktualisieren

@hudi deine Lösung ist richtig, ich habe es gerade getestet. Leider kann ich dich nicht upvote.

Der Kunde, der WebSphere 8.5.5.x mit SDK 1.7 verwendet und SAAJ mit Spring frmae verwendet, kann OutOfMemoryError beim Senden einer SOAP-Anfrage mit einer ungültigen Anfrage begegnen. Dies liegt an Fehler , der in SDK 1.7 und späteren Versionen behoben wurde.

IBM hat dieses Problem durch das IBM SDK APAR IV73614 behoben.

Details der Fehlerbehebung waren in späteren Versionen