Hi Martin,
just forget my stack, it dives deeper then what I wrote, but I don't know why it did not enter sender.send() using a debugger. This made me assuming that I have to wait for an objects method not under control of axis2 developers. Will have to re-setup. Sorry for that. Josef Von: Martin Gainty [mailto:mgai...@hotmail.com] Gesendet: Dienstag, 16. April 2013 11:54 An: java-user@axis.apache.org Betreff: RE: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client Goddag Josef Trying to narrow down the environments in play here NetBeans AxisClient/AxisService Network Path what happens when you run Axis client outside of NB? If your MTOM client achieves consistent rapid results you know NB plugin is at fault On the other hand if you port the same Axis Client to another box clean the arp cache and run the AxisClient repeatedly If you achieve consistent rapid results you know your Network path (Arp cache?) is at fault on box 1 If there is consistent degradation on both boxes over a period of time the problem is with AxisClient and or Axis Service Apologies as this is Not an answer but a means to narrow down the culprit Viel Gluck, Martin ______________________________________________ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. ________________________________ Subject: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client Date: Mon, 15 Apr 2013 20:54:30 +0200 From: josef.stadelm...@axa-winterthur.ch To: axis-u...@ws.apache.org Hi all, I've developed a MTOM Client server apps sending up- and downloading larger files. Doing some performance testing I toke 25 MB files and did some up and downloads routinely using dispatch and proxy approaches. The outcome was very nice, I had a java client working uploading axis2.zip (25MB) to a OpenVMS Java web service server within 5 to 8 seconds. Generating a stub in Visual Studio delivered me the same. A very performing CL/SV transfer aps, and the Vista task Manager showed close to 100% network utilization. Since a few days however, this is no longer the case for the java client, the network utilization has degraded to 1 to 2% and now the same transfer takes 4 to 5 minutes. Unacceptable. At the same time absolute no problem and close to 100% network utilization if I run my Visual Studio Test Suite of proxy based up and down load tests. If I changed something on my client side java code, that would be unintentionally. ! J But any hint where I can start to hunt this phenomena would be very appreciated? I am launching my java client within NetBeans 7.2.1 for debugging and testing reasons, also it the past it was working so nicely. There is maybe one point I can make: When I used the NB debugger, I could see the "MultiThreadedHttpConnectionManager" doing some cleanup 'running' forever. What makes him running? Fiddling a bit around within the debug-view, I have seen an immediate Network utilization going up to 100% when this manager was suspended for a moment. as I have no clue what has happen then or how to catch it any hints are very welcome. Any hints welcome. Regards Josef
