Goddag Josef
\r\n is the cuplrit?
Any chance of doing dos2unix on all the files for your service
javac -Dline.separator='\r' *.java
jar -Dline.separator='\r' *.aar
redeploy with admin tool
and rerun the container with java -Dline.separator='\r' ContainerBootstrap.jar
and retry..
Viel Gluck!
Martin
______________________________________________
Vertraulichkeit und Datenschutz
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: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF
client
Date: Wed, 17 Apr 2013 12:21:08 +0200
From: josef.stadelm...@axa-winterthur.ch
To: java-user@axis.apache.org
Hi Martin,
turning on DEBUG logging
#--- logging to CL_FAP
log4j.logger.org.apache.commons.httpclient=DEBUG, CONS, CL_FAP
log4j.additivity.org.apache.commons.httpclient=false
log4j.logger.httpclient.wire=DEBUG, CONS, CL_FAP
log4j.additivity.httpclient.wire=false
shows that I have in fact a binary encoding for the content
2013-04-17 11:42:30,194
DEBUG
httpclient.wire.content
>> "2364[\r][\n]"
2013-04-17 11:42:30,194
DEBUG
httpclient.wire.content
>>
"--MIMEBoundary_a4d8953e766f4ad5afd4dbda9ddf2e0e0717f1c793e08ff7[\r][\n]"
2013-04-17 11:42:30,194
DEBUG
httpclient.wire.content
>> "Content-Type: application/xop+xml; charset=UTF-8;
type="application/soap+xml"[\r][\n]"
2013-04-17 11:42:30,194
DEBUG
httpclient.wire.content
>> "Content-Transfer-Encoding: binary[\r][\n]"
2013-04-17 11:42:30,194
DEBUG
httpclient.wire.content
>> "Content-ID:
<0.b4d8953e766f4ad5afd4dbda9ddf2e0e0717f1c793e08...@apache.org>[\r][\n]"
2013-04-17 11:42:30,194
DEBUG
httpclient.wire.content
>> "[\r][\n]"
2013-04-17 11:42:30,194
DEBUG
httpclient.wire.content
>> "<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope
xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope";><soapenv:Body><sendImage
xmlns="http://ch/axa/spezpla/fs1/";><input><imageData><xop:Include
xmlns:xop="http://www.w3.org/2004/08/xop/include";
href="cid:e4d8953e766f4ad5afd4dbda9ddf2e0e0717f1c793e08ff7@apache.org"/></imageData></input></sendImage></soapenv:Body></soapenv:Envelope>[\r][\n]"
and it shows octet stream but breaks the stream up into pieces em up at each
"\r\n"
2013-04-17 11:42:30,194
DEBUG
httpclient.wire.content
>>
"--MIMEBoundary_a4d8953e766f4ad5afd4dbda9ddf2e0e0717f1c793e08ff7[\r][\n]"
2013-04-17 11:42:30,194
DEBUG
httpclient.wire.content
>> "Content-Type: application/octet-stream[\r][\n]"
2013-04-17 11:42:30,194
DEBUG
httpclient.wire.content
>> "Content-Transfer-Encoding: binary[\r][\n]"
but then the content breaks up into pices at each "\n"
That is why I get such a lousy performance!
WHY
Please remember: some weeks ago, my example was fast running as well under a
JAVA Client.
So I expect a new maven build getting down some to me yet unknown jar makes
this happen
at the java client side awhile at the WCF .NET client side all runs at full
speed and transfers 25MB
asci2.zip in 5 to 8 seconds to a remote node.
full log (until I stopped the apps) is attached.
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
--------------------------------------------------------------------- To
unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org For additional
commands, e-mail: java-user-h...@axis.apache.org
