Eclipse-generierter Web-Service-Client extrem langsam

8

Ein wenig nach vorne Info:

Ich habe einen SOAP-Service (gehostet mit JAX-WS (Endpoint-Klasse), aber ich denke nicht, dass das wichtig ist).

Ich kann eine Verbindung herstellen und den Web-Service problemlos verwenden, wenn Visual Studio den Client generiert (C #).

Ich habe einen Java-Client mit Eclipse-Webtools erstellt (neu - & gt; andere - & gt; Web-Services - & gt; Web-Services-Client).

Dann schrieb ich einen JUnit-Test, um den Client zu testen. Der Test ist bestanden, aber es dauert extrem lange. Jeder Service-Anruf dauert 300 Sekunden (geben oder nehmen Sie ein paar Sekunden). Außerdem spielt es keine Rolle, wie schnell der Computer ist. Wenn ich das auf meinem sehr langsamen Arbeits-Laptop ausführe, dauert es genauso lange, als wenn ich es auf meiner schnellen Heim-Maschine laufen lasse.

Ich habe in der axis code zu der folgenden Funktion in org.apache.axis.encoding.DeserializationContext:

debugged %Vor%

keine Überraschung, aber der Aufruf von parser.parse () dauert die 300 Sekunden. Der aus dem Webdienst ist sehr kurz, so dass es nicht lange dauern sollte zu analysieren.

Falls jemand sich fragt, ist der eigentliche Typ des Parsers com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl

Ich kann nicht darin debuggen, weil ich die Quelle nicht habe (und ich bin müde, 50 Anrufe tief in häufig verwendete Bibliotheken zu debuggen).

Ich führe gerade den Profiler, um Pakete von Sun einzuschließen. Ich poste meine Ergebnisse dafür, sobald es abgeschlossen ist (das Hinzufügen all dieser Pakete verlangsamt den Test erheblich)

Ich verwende Eclipse 3.5.1 und verwende axis 1.4

Bearbeiten:

Hier ist der JUnit-Test:

%Vor%

HINWEIS: Beide Möglichkeiten, den Executer zu erstellen, haben dasselbe Problem.

Bearbeiten2:

Hier ist der Code, den ich verwende, um den Dienst zu starten:

%Vor%

Ich kann die URL nicht posten, da ich sie gerade auf einer einzigen Maschine entwickle. Hier ist jedoch die WSDL, die generiert wird, wenn ich zu Ссылка

gehe %Vor%

Bearbeiten:

Ich denke, das könnte ein Problem verursachen:

Ich habe TCPMonitor verwendet, um die SOAP-Anfragen zu betrachten, und mir ist aufgefallen, dass der Client HTTP / 1.0 spricht und der Server HTTP / 1.1 spricht, aber ich weiß nicht, ob dies das Problem verursacht. Ich versuche gerade herauszufinden, wie man den Client HTTP / 1.1 sprechen lässt.

Hier sind die SOAP-Nachrichten für den Fall, dass sich jemand fragen würde:

%Vor%

und die Antwort:

%Vor%

Bearbeiten:

Endlich! Es stellt sich heraus, dass der HTTP-Client in CommonsHTTPClient geändert wurde und HTTP / 1.1 das Problem behoben hat:

Hier ist der Code, den ich dem Client hinzugefügt habe, der es behoben hat:

%Vor%

Hinweis: Sie müssen common-httpclient.jar und common.codec.jar zum Klassenpfad hinzufügen.

    
tster 31.12.2009, 16:09
quelle

4 Antworten

1

1) Stellen Sie sicher, dass die C # - und Java-Clients genau dieselben Anforderungen an den Server senden. Wenn Sie Jetty verwenden, erhalten Sie bei Anforderungsprotokollierung wahrscheinlich die erforderlichen Daten.

2) Sobald der SAX-Parser auf dem Client ausgeführt wird, werden Callbacks ausgeführt, die - direkt oder indirekt - Methoden in Ihrem generierten Client aufrufen. Sie sollten in der Lage sein, Breakpoints am Anfang und am Ende (und / oder return s) der generierten Clientmethoden zu setzen und diese zu verwenden, um zu bestimmen, wo die Verzögerung [s] passiert.

(BTW, in der SAX-API werden URLs wie http://xml.org/sax/properties/lexical-handler lokal verwendet, um Eigenschaftsnamen zu identifizieren; nichts wird an dieser Adresse nach etwas suchen. Siehe Ссылка für weitere Informationen.

    
Dan Breslau 04.01.2010, 16:35
quelle
2

Ich habe das gleiche Problem und löste es, die HTTP-Version modifizierend.

Ein einfacherer Weg dazu ist, innerhalb der Stub-Klasse die setProperty-Methode in der Call-Instanz aufzurufen:

%Vor%     
Francesco Monari 06.12.2011 13:58
quelle
1

Ihr Problem ist genau das, was ich jetzt vor mir habe. Und komisch, ich habe fast den gleichen Zyklus durchlaufen (vom Endpoint-Service, der .net-Client funktioniert gut und der Eclipse-generierte Client dauert gut 5 Minuten). Danke, dass Sie die Updates und die Lösung gepostet haben. Ich bin kein Java-Experte, also kann ich fragen, ob Sie die Lösung auf den von eclipse generierten Client-Code angewendet haben? Oder hast du etwas ganz anderes gemacht? Wenn Sie den von Eclipse generierten Client-Code geändert haben, wo genau haben Sie diese Zeilen hinzugefügt?

Danke, und ich schätze die Hilfe wirklich:)

Prost, Arash

    
Arash Motamedi 10.10.2010 05:25
quelle
0

Höchstwahrscheinlich eine Zeitüberschreitung. Könnte sein, dass der Parser versucht, etwas aus dem Internet herunterzuladen (DTD, XSD, etc), aber Sie sind hinter einem Proxy / Firewall.

Versuchen Sie, den Stack-Trace des Servers zu nehmen, wenn Sie den Test ausführen, um zu sehen, was passiert (z. B. jps / jstat).

    
maximdim 31.12.2009 18:44
quelle

Tags und Links