axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stadelmann Josef" <josef.stadelm...@axa-winterthur.ch>
Subject AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client
Date Thu, 18 Apr 2013 08:02:22 GMT
Hi Martin

 

let me ask and comment on your response.

 

Von: Martin Gainty [mailto:mgainty@hotmail.com] 
Gesendet: Donnerstag, 18. April 2013 00:43
An: java-user@axis.apache.org
Betreff: RE: AW: [axis2-1.6.1] java MTOM client very slow compared to
.NET WCF client

 

Goddag Josef
 
\r\n is the cuplrit?

++ I can see in my log file (I've sent) that some xml soap records end
in [\r][\n]
I can further see that most remaining binary data breaks up the stream
at [\n]
I think if the transfer mode is real binary [\r][\n] should never have
any impact.

Any chance of doing dos2unix on all the files for your service

what do you mean with that? which files would need treatment?

javac  -Dline.separator='\r' *.java

are you saying with that, that my maven build for my project must
include somehow this 
line separator definition when it comes to a maven compile? How do I do
that?

jar -Dline.separator='\r' *.aar

are you saying that maven builds must package my are using this line
separator; again - how do I do that. 
Isn't this a maven-plugin issue?

redeploy with admin tool

OK

and rerun the container with java -Dline.separator='\r'
ContainerBootstrap.jar

Do you refer to the Apache Jakarta Tomcat on OpenVMS here. I have
problems with my client code only, kept on NetBeans 7.2.1 in JAVA. There
my project, made of a client and a service part is built using maven. 

Is there any negotiation going on between client and server? Does
ISO8859-1 somewhere above in the log file generate an indication that
\r\n shall be used? But I think that should not lead MTOM to be non
binary transparent. again - it cannot be a server/service issue because
my .NET WCF 4.0 client runs fine/fast.  But I think it is a question of
what binary transparency under MTOM means and how it potentially can be
that a sub module makes it no longer binary transparent. MTOM and binary
transparency shall never look a t \r \n or just \n as this is just a
pattern in a stream which can occur very frequently. As this client was
running fine before, there must be a module, a jar coming in from a
maven repo which gave me this non binary transparency. Intentionally I
was never fiddling around with any such issues as this would not be
"binary transparency" unless I run into this performance problems.

and retry..



anyway good hints about a generic problem. 


Viel Gluck!
Martin 

Thanks and regards

Josef


______________________________________________ 

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.stadelmann@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.b4d8953e766f4ad5afd4dbda9ddf2e0e0717f1c793e08ff7@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><s
endImage
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:mgainty@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.stadelmann@axa-winterthur.ch
To: axis-user@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-unsubscribe@axis.apache.org For
additional commands, e-mail: java-user-help@axis.apache.org


Mime
View raw message