[axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

Stadelmann Josef-2
[axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

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

Reply | Threaded
Open this post in threaded view
|

RE: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

Martin Gainty
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: [hidden email]
To: [hidden email]

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

Reply | Threaded
Open this post in threaded view
|

AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

Stadelmann Josef-2

Hi Martin,

 

thank you.

 

I toke the debugger and could follow down in code fromm y sample through all axis2 stuff, unless I hit

 

CommonsHttpTransportSender.invoke(mc)  which goes into

                             writeMessageWithCommons(mc,toper,format); which goes down to Line 404

                                sender.send(mc, url, soapaction);

 

and this call takes then up to 4 to 10 minutes for a 25 MB file; 

 

So my decision: got all the open sources from asf/repo for httpcomponents and will now build and check why  CommonsHttpTransportSender.invoke / write… / sender.send  behaves like that.

 

My I will then need some assistance. But let me see what happens in the sender.

 

Thanks

 

 

 

Von: Martin Gainty [mailto:[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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

Reply | Threaded
Open this post in threaded view
|

AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

Stadelmann Josef-2
In reply to this post by Martin Gainty

Hi Martin,

 

here the screen shoot from my NB Debug Window

while we are waiting for a return from CommonsHTTPTransportSender.writeMessageWithCommons()

(sender.send at Line 404)

 

again, it's a java client problem as the same transfer using a WCF client with a fully generated svcutil proxy stub

using :NET V4.0 works like a charm and transfers 25 MB binary data (axis2.zip) in 5 to 8 seconds.

 

Josef

 

Von: Martin Gainty [mailto:[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: [hidden email]
For additional commands, e-mail: [hidden email]

CommonsHTTPTransportSender.writeMessage.writeMessageWithCommons 404.gif (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

Stadelmann Josef-2
In reply to this post by Stadelmann Josef-2

The image was catch by our security team making our life extremely hard! told them to send it anyway.

Josef – stay tuned

 

Von: Stadelmann Josef [mailto:[hidden email]]
Gesendet: Dienstag, 16. April 2013 18:58
An: [hidden email]
Betreff: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

 

Hi Martin,

 

thank you.

 

I toke the debugger and could follow down in code fromm y sample through all axis2 stuff, unless I hit

 

CommonsHttpTransportSender.invoke(mc)  which goes into

                             writeMessageWithCommons(mc,toper,format); which goes down to Line 404

                                sender.send(mc, url, soapaction);

 

and this call takes then up to 4 to 10 minutes for a 25 MB file; 

 

So my decision: got all the open sources from asf/repo for httpcomponents and will now build and check why  CommonsHttpTransportSender.invoke / write… / sender.send  behaves like that.

 

My I will then need some assistance. But let me see what happens in the sender.

 

Thanks

 

 

 

 

Von: Martin Gainty [[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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

Reply | Threaded
Open this post in threaded view
|

AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

Stadelmann Josef-2
In reply to this post by Martin Gainty

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:[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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

Reply | Threaded
Open this post in threaded view
|

AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

Stadelmann Josef-2
In reply to this post by Martin Gainty

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: <[hidden email]>[\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:[hidden email]"/></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:[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: [hidden email]
For additional commands, e-mail: [hidden email]

log-1.txt (6M) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

Martin Gainty
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: [hidden email]
To: [hidden email]

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: <[hidden email]>[\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:[hidden email]"/></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:[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: [hidden email] For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

Stadelmann Josef-2

Hi Martin

 

let me ask and comment on your response.

 

Von: Martin Gainty [mailto:[hidden email]]
Gesendet: Donnerstag, 18. April 2013 00:43
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: <[hidden email]>[\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="<a href="cid:e4d8953e766f4ad5afd4dbda9ddf2e0e0717f1c793e08ff7@apache.org">cid:e4d8953e766f4ad5afd4dbda9ddf2e0e0717f1c793e08ff7@..."/></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 [[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: [hidden email] For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

Martin Gainty
ISO8859-1 is the standard for Latin based languages..AFAIK ISO8859-1 Character Set should *not* have an impact..
I remember the *FUN* we experienced at the bank while  porting our ISO8859-1  based Axis Services and client stubs to 'American' UTF-8

One more thing that (I thought of while reading your response) This *sounds* like you may be using Chunked-encoding  (instead of binary)
The SOAP-Envelope is *supposed* to be reconstructed from the fragments sent to Servlet Connector and handed to the Axis Service *intact*

Turn off chunked-encoding on both sides and set Transfer-Encoding to binary in  .\WEB-INF\conf\Axis2.xml  e.g.

<transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
   ....
   <parameter name="Transfer-Encoding">binary</parameter>
.....
</transportSender>

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.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.


 

Subject: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client
Date: Thu, 18 Apr 2013 10:02:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin

 

let me ask and comment on your response.

 

Von: Martin Gainty [mailto:[hidden email]]
Gesendet: Donnerstag, 18. April 2013 00:43
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: <[hidden email]>[\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@..."/></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 [[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: [hidden email] For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

Stadelmann Josef-2

Hi Martin é all

 

I have found that a SOAPBinding.java allows i.e.

isMTOMEnabled() 

setMTOMEnabled(true)

setMTOMThreshold(2048);

 

will check what the threshold value shows on effects and maybe side effects on either side and applications,

 

BUT

Where and how can I select that Transfer-Encoding is changed from chunked to binary for a JAX-WS Annotation based client and for a service by program control.

Doing so a) by configuration or b) programmatic is it guaranteed that only the service doing so is configured.

 

Note: a JAX-WS does not need a service.xml, so configuring the transport on a per-service-base for a given service using service.xml is a no-go

 

So how can I configure my transport used in my JAX-WS client / JAX-WS service programmatically?

 

again:

if each clinet / servide has a Axis2.xml is it by definition assured that such type of "global configuration" are not overriding among already configured clients/service

 

i.e. we have only 1 axis2 engine running;

setting transfer encoding to chunked for webservice1 will transfer encoding binary for webservice2 also override transfer-encoding chunked for webservice1?

 

are all configurations made in one of the many axis2.xmls influencing all web-services-configurations or only the on for which it is delivered in /WEB-INF/conf ?

 

Josef

 

 

Von: Martin Gainty [mailto:[hidden email]]
Gesendet: Freitag, 19. April 2013 00:36
An: [hidden email]
Betre
ff: RE: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

 

ISO8859-1 is the standard for Latin based languages..AFAIK ISO8859-1 Character Set should *not* have an impact..
I remember the *FUN* we experienced at the bank while  porting our ISO8859-1  based Axis Services and client stubs to 'American' UTF-8

One more thing that (I thought of while reading your response) This *sounds* like you may be using Chunked-encoding  (instead of binary)
The SOAP-Envelope is *supposed* to be reconstructed from the fragments sent to Servlet Connector and handed to the Axis Service *intact*

Turn off chunked-encoding on both sides and set Transfer-Encoding to binary in  .\WEB-INF\conf\Axis2.xml  e.g.

<transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
   ....
   <parameter name="Transfer-Encoding">binary</parameter>
.....
</transportSender>

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.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.



 


Subject: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client
Date: Thu, 18 Apr 2013 10:02:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin

 

let me ask and comment on your response.

 

Von: Martin Gainty [[hidden email]]
Gesendet: Donnerstag, 18. April 2013 00:43
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: <[hidden email]>[\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@..."/></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 [[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: [hidden email] For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

Martin Gainty
Guten Tag Josef!

axis2.xml declarator:
<transportSender name="http"
                     class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
        <parameter name="PROTOCOL">HTTP/1.1</parameter>
        <parameter name="Transfer-Encoding">chunked</parameter>

programmatic:
  org.apache.axis2.client.Options options = neworg.apache.axis2.client.Options();
  options.setProperty(HTTPConstants.HTTP_PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_11);
   options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);
   org.apache.axis2.client.ServiceClient sender = new org.apache.axis2.client.ServiceClient(configcontext, service);
   
   sender.setOptions(options);

?
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] how to configire JAX-WS MTOM client / service programmatically
Date: Thu, 20 Jun 2013 12:43:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin é all

 

I have found that a SOAPBinding.java allows i.e.

isMTOMEnabled() 

setMTOMEnabled(true)

setMTOMThreshold(2048);

 

will check what the threshold value shows on effects and maybe side effects on either side and applications,

 

BUT

Where and how can I select that Transfer-Encoding is changed from chunked to binary for a JAX-WS Annotation based client and for a service by program control.

Doing so a) by configuration or b) programmatic is it guaranteed that only the service doing so is configured.

 

Note: a JAX-WS does not need a service.xml, so configuring the transport on a per-service-base for a given service using service.xml is a no-go

 

So how can I configure my transport used in my JAX-WS client / JAX-WS service programmatically?

 

again:

if each clinet / servide has a Axis2.xml is it by definition assured that such type of "global configuration" are not overriding among already configured clients/service

 

i.e. we have only 1 axis2 engine running;

setting transfer encoding to chunked for webservice1 will transfer encoding binary for webservice2 also override transfer-encoding chunked for webservice1?

 

are all configurations made in one of the many axis2.xmls influencing all web-services-configurations or only the on for which it is delivered in /WEB-INF/conf ?

 

Josef

 

 

Von: Martin Gainty [mailto:[hidden email]]
Gesendet: Freitag, 19. April 2013 00:36
An: [hidden email]
Betre
ff: RE: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

 

ISO8859-1 is the standard for Latin based languages..AFAIK ISO8859-1 Character Set should *not* have an impact..
I remember the *FUN* we experienced at the bank while  porting our ISO8859-1  based Axis Services and client stubs to 'American' UTF-8

One more thing that (I thought of while reading your response) This *sounds* like you may be using Chunked-encoding  (instead of binary)
The SOAP-Envelope is *supposed* to be reconstructed from the fragments sent to Servlet Connector and handed to the Axis Service *intact*

Turn off chunked-encoding on both sides and set Transfer-Encoding to binary in  .\WEB-INF\conf\Axis2.xml  e.g.

<transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
   ....
   <parameter name="Transfer-Encoding">binary</parameter>
.....
</transportSender>

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.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.



 


Subject: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client
Date: Thu, 18 Apr 2013 10:02:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin

 

let me ask and comment on your response.

 

Von: Martin Gainty [[hidden email]]
Gesendet: Donnerstag, 18. April 2013 00:43
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: <[hidden email]>[\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@..."/></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 [[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: [hidden email] For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

Stadelmann Josef-2

Guten Tag Martin,

 

vielen Dank

 

I have identified in this direction as well

options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);

 

But how do I go for binary ?

 

In a previous response from you, you said, to avoid the "\r\n" problem I have to set
<parameter name="Transfer-Encoding">binary</parameter> on either side.

 

The question is how do I do that using a JAX-WS client and servise?

 

Does that imply that when I do

options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.FALSE);

 

it will fore

org.apache.axis2.transport.http.CommonsHTTPTransportSender

to use a "BINARY" encoding for the header and the content in the SOAP envelope ?

 

I found at org.apache.axis2.transport.http.CommonsHTTPTransportSender

            boolean chunked;

            if (messageContext.getProperty(HTTPConstants.CHUNKED) != null) {

                chunked = JavaUtils.isTrueExplicitly(messageContext

                        .getProperty(HTTPConstants.CHUNKED));

            } else {

                chunked = defaultChunked;

            }

 

at the very moment it executes chunked = defaultChunked; which is TRUE by default,

which means that so far I am unable to set the chunked value to false

 

 

Josef

 

Von: Martin Gainty [mailto:[hidden email]]
Gesendet: Donnerstag, 20. Juni 2013 14:07
An: [hidden email]
Betreff: RE: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

 

Guten Tag Josef!

axis2.xml declarator:
<tra
nsportSender name="http"
                     class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
        <parameter name="PROTOCOL">HTTP/1.1</parameter>
        <parameter name="Transfer-Encoding">chunked</parameter>

programmatic:
  org.apache.axis2.client.Options options = neworg.apache.axis2.client.Options();
  options.setProperty(HTTPConstants.HTTP_PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_11);
   options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);
   org.apache.axis2.client.ServiceClient sender = new org.apache.axis2.client.ServiceClient(configcontext, service);
   
   sender.setOptions(options);

?
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] how to configire JAX-WS MTOM client / service programmatically
Date: Thu, 20 Jun 2013 12:43:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin é all

 

I have found that a SOAPBinding.java allows i.e.

isMTOMEnabled() 

setMTOMEnabled(true)

setMTOMThreshold(2048);

 

will check what the threshold value shows on effects and maybe side effects on either side and applications,

 

BUT

Where and how can I select that Transfer-Encoding is changed from chunked to binary for a JAX-WS Annotation based client and for a service by program control.

Doing so a) by configuration or b) programmatic is it guaranteed that only the service doing so is configured.

 

Note: a JAX-WS does not need a service.xml, so configuring the transport on a per-service-base for a given service using service.xml is a no-go

 

So how can I configure my transport used in my JAX-WS client / JAX-WS service programmatically?

 

again:

if each clinet / servide has a Axis2.xml is it by definition assured that such type of "global configuration" are not overriding among already configured clients/service

 

i.e. we have only 1 axis2 engine running;

setting transfer encoding to chunked for webservice1 will transfer encoding binary for webservice2 also override transfer-encoding chunked for webservice1?

 

are all configurations made in one of the many axis2.xmls influencing all web-services-configurations or only the on for which it is delivered in /WEB-INF/conf ?

 

Josef

 

 

Von: Martin Gainty [[hidden email]]
Gesendet: Freitag, 19. April 2013 00:36
An: [hidden email]
Betre
ff: RE: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

 

ISO8859-1 is the standard for Latin based languages..AFAIK ISO8859-1 Character Set should *not* have an impact..
I remember the *FUN* we experienced at the bank while  porting our ISO8859-1  based Axis Services and client stubs to 'American' UTF-8

One more thing that (I thought of while reading your response) This *sounds* like you may be using Chunked-encoding  (instead of binary)
The SOAP-Envelope is *supposed* to be reconstructed from the fragments sent to Servlet Connector and handed to the Axis Service *intact*

Turn off chunked-encoding on both sides and set Transfer-Encoding to binary in  .\WEB-INF\conf\Axis2.xml  e.g.

<transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
   ....
   <parameter name="Transfer-Encoding">binary</parameter>
.....
</transportSender>

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.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.



 


Subject: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client
Date: Thu, 18 Apr 2013 10:02:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin

 

let me ask and comment on your response.

 

Von: Martin Gainty [[hidden email]]
Gesendet: Donnerstag, 18. April 2013 00:43
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: <[hidden email]>[\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@..."/></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 [[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: [hidden email] For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

Stadelmann Josef-2
In reply to this post by Martin Gainty

Hallo Martin

hallo developers,

 

I have a JAX-WS client, one of its classes is called, and has, which has,

 

MtomFile12PortType

  _descriptor

    _service           = new MtomFileService12()

      _delegate

        serviceClient

          options

 

During initialization at the JAX-WS client

I can see, by debugger that I have a ServiceDelegate object!

it's serviceClient object is null,

so there is no such thing as a options object

and I cannot set user defined properties such as HTTPConstant.CHUNKED, BooleanFALSE

 

In other words;

does a JAX-WS Proxy Client allow to tell the underlying transport that it shall not use CHUNKED but BINARY encoding?

 

The JAX-WS client is taken from the JAX-WS samples and modified to my demand.

Maybe I should use the proxy handler to get at required objects to add some more properties.

 

Josef

    

 

Von: Martin Gainty [mailto:[hidden email]]
Gesendet: Donnerstag, 20. Juni 2013 14:07
An: [hidden email]
Betreff: RE: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

 

Guten Tag Josef!

axis2.xml declarator:
<transportSender name="http"
                     class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
        <parameter name="PROTOCOL">HTTP/1.1</parameter>
        <parameter name="Transfer-Encoding">chunked</parameter>

programmatic:
  org.apache.axis2.client.Options options = neworg.apache.axis2.client.Options();
  options.setProperty(HTTPConstants.HTTP_PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_11);
   options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);
   org.apache.axis2.client.ServiceClient sender = new org.apache.axis2.client.ServiceClient(configcontext, service);
   
   sender.setOptions(options);

?
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] how to configire JAX-WS MTOM client / service programmatically
Date: Thu, 20 Jun 2013 12:43:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin é all

 

I have found that a SOAPBinding.java allows i.e.

isMTOMEnabled() 

setMTOMEnabled(true)

setMTOMThreshold(2048);

 

will check what the threshold value shows on effects and maybe side effects on either side and applications,

 

BUT

Where and how can I select that Transfer-Encoding is changed from chunked to binary for a JAX-WS Annotation based client and for a service by program control.

Doing so a) by configuration or b) programmatic is it guaranteed that only the service doing so is configured.

 

Note: a JAX-WS does not need a service.xml, so configuring the transport on a per-service-base for a given service using service.xml is a no-go

 

So how can I configure my transport used in my JAX-WS client / JAX-WS service programmatically?

 

again:

if each clinet / servide has a Axis2.xml is it by definition assured that such type of "global configuration" are not overriding among already configured clients/service

 

i.e. we have only 1 axis2 engine running;

setting transfer encoding to chunked for webservice1 will transfer encoding binary for webservice2 also override transfer-encoding chunked for webservice1?

 

are all configurations made in one of the many axis2.xmls influencing all web-services-configurations or only the on for which it is delivered in /WEB-INF/conf ?

 

Josef

 

 

Von: Martin Gainty [[hidden email]]
Gesendet: Freitag, 19. April 2013 00:36
An: [hidden email]
Betre
ff: RE: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

 

ISO8859-1 is the standard for Latin based languages..AFAIK ISO8859-1 Character Set should *not* have an impact..
I remember the *FUN* we experienced at the bank while  porting our ISO8859-1  based Axis Services and client stubs to 'American' UTF-8

One more thing that (I thought of while reading your response) This *sounds* like you may be using Chunked-encoding  (instead of binary)
The SOAP-Envelope is *supposed* to be reconstructed from the fragments sent to Servlet Connector and handed to the Axis Service *intact*

Turn off chunked-encoding on both sides and set Transfer-Encoding to binary in  .\WEB-INF\conf\Axis2.xml  e.g.

<transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
   ....
   <parameter name="Transfer-Encoding">binary</parameter>
.....
</transportSender>

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.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.



 


Subject: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client
Date: Thu, 18 Apr 2013 10:02:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin

 

let me ask and comment on your response.

 

Von: Martin Gainty [[hidden email]]
Gesendet: Donnerstag, 18. April 2013 00:43
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: <[hidden email]>[\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@..."/></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 [[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: [hidden email] For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

Stadelmann Josef-2
In reply to this post by Martin Gainty

The code at

 

org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.java

 

public MessageContext doInvoke(MessageContext request) {

 

        InvocationContext ic = request.getInvocationContext();

        ServiceClient svcClient = ic.getServiceClient();

        OperationClient opClient = createOperationClient(svcClient, operationName);

 

has an error at least it has something I do not understand !!!

 

ic has

  serviceClient

    options

      properties

        [0] has "ServiceClient.autoOperationsCleanup" = "false"

 

svcClient has

  options

    properties

      [0] has "ServiceClient.autoOperationsCleanup" = "false"

 

        OperationClient opClient = createOperationClient(svcClient, operationName);

// is used to copy from svcClient into opClient BUT

 

opClient has

  options

    properties = null

 

 

Cosequence:

any properties like [0] has "ServiceClient.autoOperationsCleanup" = "false

will not make it into opClient, and as this opClient is further used it will

not deliver properties such as __CHUNKED__ false to the HTTPSende object

 

Question:

So how can I pass properties to the underlying transport for a JAX-WS proxy client?

 

Josef

   

 

 

 

 

Von: Martin Gainty [mailto:[hidden email]]
Gesendet: Donnerstag, 20. Juni 2013 14:07
An: [hidden email]
Betreff: RE: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

 

Guten Tag Josef!

axis2.xml declarator:
<transportSender name="http"
                     class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
        <parameter name="PROTOCOL">HTTP/1.1</parameter>
        <parameter name="Transfer-Encoding">chunked</parameter>

programmatic:
  org.apache.axis2.client.Options options = neworg.apache.axis2.client.Options();
  options.setProperty(HTTPConstants.HTTP_PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_11);
   options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);
   org.apache.axis2.client.ServiceClient sender = new org.apache.axis2.client.ServiceClient(configcontext, service);
   
   sender.setOptions(options);

?
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] how to configire JAX-WS MTOM client / service programmatically
Date: Thu, 20 Jun 2013 12:43:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin é all

 

I have found that a SOAPBinding.java allows i.e.

isMTOMEnabled() 

setMTOMEnabled(true)

setMTOMThreshold(2048);

 

will check what the threshold value shows on effects and maybe side effects on either side and applications,

 

BUT

Where and how can I select that Transfer-Encoding is changed from chunked to binary for a JAX-WS Annotation based client and for a service by program control.

Doing so a) by configuration or b) programmatic is it guaranteed that only the service doing so is configured.

 

Note: a JAX-WS does not need a service.xml, so configuring the transport on a per-service-base for a given service using service.xml is a no-go

 

So how can I configure my transport used in my JAX-WS client / JAX-WS service programmatically?

 

again:

if each clinet / servide has a Axis2.xml is it by definition assured that such type of "global configuration" are not overriding among already configured clients/service

 

i.e. we have only 1 axis2 engine running;

setting transfer encoding to chunked for webservice1 will transfer encoding binary for webservice2 also override transfer-encoding chunked for webservice1?

 

are all configurations made in one of the many axis2.xmls influencing all web-services-configurations or only the on for which it is delivered in /WEB-INF/conf ?

 

Josef

 

 

Von: Martin Gainty [[hidden email]]
Gesendet: Freitag, 19. April 2013 00:36
An: [hidden email]
Betreff: RE: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

 

ISO8859-1 is the standard for Latin based languages..AFAIK ISO8859-1 Character Set should *not* have an impact..
I remember the *FUN* we experienced at the bank while  porting our ISO8859-1  based Axis Services and client stubs to 'American' UTF-8

One more thing that (I thought of while reading your response) This *sounds* like you may be using Chunked-encoding  (instead of binary)
The SOAP-Envelope is *supposed* to be reconstructed from the fragments sent to Servlet Connector and handed to the Axis Service *intact*

Turn off chunked-encoding on both sides and set Transfer-Encoding to binary in  .\WEB-INF\conf\Axis2.xml  e.g.

<transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
   ....
   <parameter name="Transfer-Encoding">binary</parameter>
.....
</transportSender>

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.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.



 


Subject: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client
Date: Thu, 18 Apr 2013 10:02:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin

 

let me ask and comment on your response.

 

Von: Martin Gainty [[hidden email]]
Gesendet: Donnerstag, 18. April 2013 00:43
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: <[hidden email]>[\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@..."/></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 [[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: [hidden email] For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

Martin Gainty
In reply to this post by Stadelmann Josef-2
 

Subject: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically
Date: Thu, 20 Jun 2013 15:59:41 +0200
From: [hidden email]
To: [hidden email]

Guten Tag Martin,

 

vielen Dank

 

I have identified in this direction as well

options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);

 

But how do I go for binary ?

 

In a previous response from you, you said, to avoid the "\r\n" problem I have to set
<parameter name="Transfer-Encoding">binary</parameter> on either side.

 

The question is how do I do that using a JAX-WS client and servise?

 

Does that imply that when I do

options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.FALSE);

MG>Informs Sender  How to transmit 

 

it will force

MG>no relationship to other HTTP Headers 

 

org.apache.axis2.transport.http.CommonsHTTPTransportSender

to use a "BINARY" encoding for the header and the content in the SOAP envelope ?

MG>what to send... BINARY or TEXT

MG>JAX-WS: HTTP Header must be set to Content-Transfer-Encoding: binary e.g.
MG>JAX-WS: writeln("Content-Transfer-Encoding: binary", outputstream);

MG>SOAP-USING-AXIS <parameter name="Transfer-Encoding">binary</parameter>

MG>Configuring Binary Attachment DataHandlers for response:

 // Create a dataHandler using the fileDataSource. Any implementation of
  // javax.activation.DataSource interface can fit here.
  DataHandler dataHandler = new DataHandler(fileDataSource);
  base64Binary.setBase64Binary(dataHandler);
  MTOMSampleMTOMSampleSOAP11Port_httpStub.ContentType_type0 param = new MTOMSampleMTOMSampleSOAP11Port_httpStub.ContentType_type0();
        param.setContentType_type0(dataHandler.getContentType());
        base64Binary.setContentType(param);
  attachmentType.setBinaryData(base64Binary);
  attachmentType.setFileName(destination);
  attachmentRequest.setAttachmentRequest(attachmentType);

  MTOMSampleMTOMSampleSOAP11Port_httpStub.AttachmentResponse response = serviceStub.attachment(attachmentRequest);
MG>

MG>likewise when sending information to AxisService you need a special Binary dataHandler e.g.

MG>options.setProperty(org.apache.axiom.om.OMConstants.DATA_HANDLER, dataHandler);
MG>a MTOM Aware reader example when Transfer-Encoding is binary

MG> if (isReaderMTOMAware(reader)
                                            &&
                                            java.lang.Boolean.TRUE.equals(reader.getProperty(org.apache.axiom.om.OMConstants.IS_BINARY)))
                                    {
                                        //MTOM aware reader - get the datahandler directly and put it in the object
                                        object.setParam1(
                                                (javax.activation.DataHandler) reader.getProperty(org.apache.axiom.om.OMConstants.DATA_HANDLER));

MG>

 

I found at org.apache.axis2.transport.http.CommonsHTTPTransportSender

            boolean chunked;

            if (messageContext.getProperty(HTTPConstants.CHUNKED) != null) {

                chunked = JavaUtils.isTrueExplicitly(messageContext

                        .getProperty(HTTPConstants.CHUNKED));

            } else {

                chunked = defaultChunked;

            }

 

at the very moment it executes chunked = defaultChunked; which is TRUE by default,

which means that so far I am unable to set the chunked value to false

 

MG>options.setProperty(HTTPConstants.CHUNKED, Boolean.TRUE);

MG>sender.setOptions(options);

 

 

Josef

MG>Martin

 

Von: Martin Gainty [mailto:[hidden email]]
Gesendet: Donnerstag, 20. Juni 2013 14:07
An: [hidden email]
Betreff: RE: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

 

Guten Tag Josef!

axis2.xml declarator:
<tra
nsportSender name="http"
                     class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
        <parameter name="PROTOCOL">HTTP/1.1</parameter>
        <parameter name="Transfer-Encoding">chunked</parameter>

programmatic:
  org.apache.axis2.client.Options options = neworg.apache.axis2.client.Options();
  options.setProperty(HTTPConstants.HTTP_PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_11);
   options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);
   org.apache.axis2.client.ServiceClient sender = new org.apache.axis2.client.ServiceClient(configcontext, service);
   
   sender.setOptions(options);

?
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] how to configire JAX-WS MTOM client / service programmatically
Date: Thu, 20 Jun 2013 12:43:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin é all

 

I have found that a SOAPBinding.java allows i.e.

isMTOMEnabled() 

setMTOMEnabled(true)

setMTOMThreshold(2048);

 

will check what the threshold value shows on effects and maybe side effects on either side and applications,

 

BUT

Where and how can I select that Transfer-Encoding is changed from chunked to binary for a JAX-WS Annotation based client and for a service by program control.

Doing so a) by configuration or b) programmatic is it guaranteed that only the service doing so is configured.

 

Note: a JAX-WS does not need a service.xml, so configuring the transport on a per-service-base for a given service using service.xml is a no-go

 

So how can I configure my transport used in my JAX-WS client / JAX-WS service programmatically?

 

again:

if each clinet / servide has a Axis2.xml is it by definition assured that such type of "global configuration" are not overriding among already configured clients/service

 

i.e. we have only 1 axis2 engine running;

setting transfer encoding to chunked for webservice1 will transfer encoding binary for webservice2 also override transfer-encoding chunked for webservice1?

 

are all configurations made in one of the many axis2.xmls influencing all web-services-configurations or only the on for which it is delivered in /WEB-INF/conf ?

 

Josef

 

 

Von: Martin Gainty [[hidden email]]
Gesendet: Freitag, 19. April 2013 00:36
An: [hidden email]
Betre
ff: RE: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

 

ISO8859-1 is the standard for Latin based languages..AFAIK ISO8859-1 Character Set should *not* have an impact..
I remember the *FUN* we experienced at the bank while  porting our ISO8859-1  based Axis Services and client stubs to 'American' UTF-8

One more thing that (I thought of while reading your response) This *sounds* like you may be using Chunked-encoding  (instead of binary)
The SOAP-Envelope is *supposed* to be reconstructed from the fragments sent to Servlet Connector and handed to the Axis Service *intact*

Turn off chunked-encoding on both sides and set Transfer-Encoding to binary in  .\WEB-INF\conf\Axis2.xml  e.g.

<transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
   ....
   <parameter name="Transfer-Encoding">binary</parameter>
.....
</transportSender>

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.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.



 


Subject: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client
Date: Thu, 18 Apr 2013 10:02:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin

 

let me ask and comment on your response.

 

Von: Martin Gainty [[hidden email]]
Gesendet: Donnerstag, 18. April 2013 00:43
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: <[hidden email]>[\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@..."/></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 [[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: [hidden email] For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

Stadelmann Josef-2

Hi Martin.

 

very much thanks for your greate and extensive help;

however I have still difficulties to get worlds together;

 

 

there is on one part of what WE have, fully based on axis2-1.6.1/samples/jaxws-samples.

And there is another part to be developerd to sniff in an option object and values to make things going.

 

 

In the example code you find a jaxws for echo, ping  and mtom. My file service is fully based on this mtom samples part found, slightly refactored to reflect the file service characteristics it should finaly have; it has a send method in the example; so as reference I started with the send() as well, which is just looping back an image depot.

 

my service and client is then extended by a upload() and a download() method passing parameters i.e. a file path to the to be downloaded file.

 

Now – we should look at the proxy server part of SamplesMTOMTests.java

 

In the axis2-1.6.1/samples/jaxws-samples you can find in class SampleMTOMTests.java

and there you can find

 

     *

     * @param result - String - used to pass back results to servlet.

     * @return String - the input string or null

     * @throws Exception

     */

    public String testMtomWithProxy(String result, URL url) throws Exception {

 

. . .

 

        // Setup the necessary JAX-WS artifacts

        try {

            if (soap12) {

                // Use the generated proxy

                MtomSample12PortProxy proxy = new MtomSample12PortProxy(url);

                proxy._getDescriptor().setEndpoint(uriString + urlSuffix);

 

                // Enable MTOM

                BindingProvider bp = (BindingProvider) proxy._getDescriptor().getProxy();

                SOAPBinding binding = (SOAPBinding) bp.getBinding();

                binding.setMTOMEnabled(true);

 

                // Send the image and process the response image

                response = proxy.sendImage(imageDepot);

            } else {

                // SOAP 1.1 Create the service

                //                       Use the generated proxy

 

 

The part I have potentially to extend with an option object starts with if (soap12) buty might be similar for the else-part for soap11.

 

What I do not know is: which classes on this examples I have to modify to sniff in / to get a

a)     service client or the like to get an

b)    options

c)     to pass options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.FALSE);

d)    to see if it passes binary data

 

options to be used following your explanations above.

 

                MtomSample12PortProxy proxy = new MtomSample12PortProxy(url);

                proxy._getDescriptor().setEndpoint(uriString + urlSuffix);

 

                // Enable MTOM

                BindingProvider bp = (BindingProvider) proxy._getDescriptor().getProxy();

                SOAPBinding binding = (SOAPBinding) bp.getBinding();

                binding.setMTOMEnabled(true);

 

                // Send the image and process the response image

                response = proxy.sendImage(imageDepot);

 

looking at this few lines of code I have no clue where to get the serviceClient from to ask for his options.

 

The closes I was is to get/ask for a request context to pass

 

                Map<String, Object> rc = proxy._getDescriptor().getDispatch().getRequestContext();

                rc.put(HTTPConstants.CHUNKED, Boolean.FALSE);

 

But that fails for reasons already explained in my previous e-mail. also and again: other data is also not passed to the context object as used by the sender. (as explained)

 

 

While I understand what you do with this code

  org.apache.axis2.client.Options options = new org.apache.axis2.client.Options();
  options.setProperty(HTTPConstants.HTTP_PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_11);
   options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);
   org.apache.axis2.client.ServiceClient sender = new org.apache.axis2.client.ServiceClient(configcontext, service);
   
   sender.setOptions(options);

I do not understand how to bring this objects/functionality together with a (generated) proxy client as shown in the axis2-1.6.1/samples/jaxws-sampl.

 

and for the jaxws-samples: It was a alltime my understanding that MTOM was for BINARY not for CHUNKED data!

and that a MTOM sample should actually transfers BINARY data without going via all the options. Joint with MTOM enabled, if then CHUNKED is the default, sniffing in "\r\n" into the data stream to the service, then I get the impression that the way this is done is not so propper.  

 

 

Maybe one can say a word how to annotate JAXWS classes used to make it transfer MTOM BINNARY data and not MTOM CHUNKED data. (if this ever makes sense)

 

Also there is a TRESHOLD somewhere used to define the size of binary converted and transferred within the SOAP body as opposed to be transferred as attachment.

Does that work as well?

 

Very thanks full for any hint; I already dived deep into axis2-1.6.1 code and into CommonsHTTPTransportSender code to see how the work together passing the CHUNKED (TRUE) or BINRAY (FALSE) indicator to make the sender transporting binaries.

 

Josef

 

 

Josef

 

 

 

 

 

Von: Martin Gainty [mailto:[hidden email]]
Gesendet: Freitag, 21. Juni 2013 12:52
An: [hidden email]
Betreff: RE: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

 

 


Subject: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically
Date: Thu, 20 Jun 2013 15:59:41 +0200
From: [hidden email]
To: [hidden email]

Guten Tag Martin,

 

vielen Dank

 

I have identified in this direction as well

options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);

 

But how do I go for binary ?

 

In a previous response from you, you said, to avoid the "\r\n" problem I have to set
<parameter name="Transfer-Encoding">binary</parameter> on either side.

 

The question is how do I do that using a JAX-WS client and servise?

 

Does that imply that when I do

options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.FALSE);

MG>Informs Sender  How to transmit 

 

it will force

MG>no relationship to other HTTP Headers 

 

org.apache.axis2.transport.http.CommonsHTTPTransportSender

to use a "BINARY" encoding for the header and the content in the SOAP envelope ?

MG>what to send... BINARY or TEXT

MG>JAX-WS: HTTP Header must be set to Content-Transfer-Encoding: binary e.g.
MG>JAX-WS: writeln("Content-Transfer-Encoding: binary", outputstream);

MG>SOAP-USING-AXIS <parameter name="Transfer-Encoding">binary</parameter>

MG>Configuring Binary Attachment DataHandlers for response:

 // Create a dataHandler using the fileDataSource. Any implementation of
  // javax.activation.DataSource interface can fit here.
  DataHandler dataHandler = new DataHandler(fileDataSource);
  base64Binary.setBase64Binary(dataHandler);
  MTOMSampleMTOMSampleSOAP11Port_httpStub.ContentType_type0 param = new MTOMSampleMTOMSampleSOAP11Port_httpStub.ContentType_type0();
        param.setContentType_type0(dataHandler.getContentType());
        base64Binary.setContentType(param);
  attachmentType.setBinaryData(base64Binary);
  attachmentType.setFileName(destination);
  attachmentRequest.setAttachmentRequest(attachmentType);

  MTOMSampleMTOMSampleSOAP11Port_httpStub.AttachmentResponse response = serviceStub.attachment(attachmentRequest);
MG>

MG>likewise when sending information to AxisService you need a special Binary dataHandler e.g.

MG>options.setProperty(org.apache.axiom.om.OMConstants.DATA_HANDLER, dataHandler);
MG>a MTOM Aware reader example when Transfer-Encoding is binary

MG> if (isReaderMTOMAware(reader)
                                            &&
                                            java.lang.Boolean.TRUE.equals(reader.getProperty(org.apache.axiom.om.OMConstants.IS_BINARY)))
                                    {
                                        //MTOM aware reader - get the datahandler directly and put it in the object
                                        object.setParam1(
                                                (javax.activation.DataHandler) reader.getProperty(org.apache.axiom.om.OMConstants.DATA_HANDLER));

MG>

 

I found at org.apache.axis2.transport.http.CommonsHTTPTransportSender

            boolean chunked;

            if (messageContext.getProperty(HTTPConstants.CHUNKED) != null) {

                chunked = JavaUtils.isTrueExplicitly(messageContext

                        .getProperty(HTTPConstants.CHUNKED));

            } else {

                chunked = defaultChunked;

            }

 

at the very moment it executes chunked = defaultChunked; which is TRUE by default,

which means that so far I am unable to set the chunked value to false

 

MG>options.setProperty(HTTPConstants.CHUNKED, Boolean.TRUE);

MG>sender.setOptions(options);

 

 

Josef

MG>Martin

 

Von: Martin Gainty [[hidden email]]
Gesendet: Donnerstag, 20. Juni 2013 14:07
An: [hidden email]
Betreff: RE: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

 

Guten Tag Josef!

axis2.xml declarator:
<transportSender name="http"
                     class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
        <parameter name="PROTOCOL">HTTP/1.1</parameter>
        <parameter name="Transfer-Encoding">chunked</parameter>

programmatic:
  org.apache.axis2.client.Options options = neworg.apache.axis2.client.Options();
  options.setProperty(HTTPConstants.HTTP_PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_11);
   options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);
   org.apache.axis2.client.ServiceClient sender = new org.apache.axis2.client.ServiceClient(configcontext, service);
   
   sender.setOptions(options);

?
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] how to configire JAX-WS MTOM client / service programmatically
Date: Thu, 20 Jun 2013 12:43:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin é all

 

I have found that a SOAPBinding.java allows i.e.

isMTOMEnabled() 

setMTOMEnabled(true)

setMTOMThreshold(2048);

 

will check what the threshold value shows on effects and maybe side effects on either side and applications,

 

BUT

Where and how can I select that Transfer-Encoding is changed from chunked to binary for a JAX-WS Annotation based client and for a service by program control.

Doing so a) by configuration or b) programmatic is it guaranteed that only the service doing so is configured.

 

Note: a JAX-WS does not need a service.xml, so configuring the transport on a per-service-base for a given service using service.xml is a no-go

 

So how can I configure my transport used in my JAX-WS client / JAX-WS service programmatically?

 

again:

if each clinet / servide has a Axis2.xml is it by definition assured that such type of "global configuration" are not overriding among already configured clients/service

 

i.e. we have only 1 axis2 engine running;

setting transfer encoding to chunked for webservice1 will transfer encoding binary for webservice2 also override transfer-encoding chunked for webservice1?

 

are all configurations made in one of the many axis2.xmls influencing all web-services-configurations or only the on for which it is delivered in /WEB-INF/conf ?

 

Josef

 

 

Von: Martin Gainty [[hidden email]]
Gesendet: Freitag, 19. April 2013 00:36
An: [hidden email]
Betreff: RE: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

 

ISO8859-1 is the standard for Latin based languages..AFAIK ISO8859-1 Character Set should *not* have an impact..
I remember the *FUN* we experienced at the bank while  porting our ISO8859-1  based Axis Services and client stubs to 'American' UTF-8

One more thing that (I thought of while reading your response) This *sounds* like you may be using Chunked-encoding  (instead of binary)
The SOAP-Envelope is *supposed* to be reconstructed from the fragments sent to Servlet Connector and handed to the Axis Service *intact*

Turn off chunked-encoding on both sides and set Transfer-Encoding to binary in  .\WEB-INF\conf\Axis2.xml  e.g.

<transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
   ....
   <parameter name="Transfer-Encoding">binary</parameter>
.....
</transportSender>

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.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.



 


Subject: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client
Date: Thu, 18 Apr 2013 10:02:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin

 

let me ask and comment on your response.

 

Von: Martin Gainty [[hidden email]]
Gesendet: Donnerstag, 18. April 2013 00:43
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: <[hidden email]>[\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@..."/></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 [[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: [hidden email] For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

Okken,Brett

It was a alltime my understanding that MTOM was for BINARY not for CHUNKED data!

and that a MTOM sample should actually transfers BINARY data without going via all the options. Joint with MTOM enabled, if then CHUNKED is the default, sniffing in "\r\n" into the data stream to the service, then I get the impression that the way this is done is not so propper.  

 

 

Maybe one can say a word how to annotate JAXWS classes used to make it transfer MTOM BINNARY data and not MTOM CHUNKED data. (if this ever makes sense)

 

It seems to me that 2 different concepts are being conflated here. I believe that the org.apache.axis2.transport.http.HTTPConstants.CHUNKED property is used to control the http transfer encoding[1]. This functionality was introduced with http 1.1 and removes the requirement to know the entire length of the response before being able to send any data. Setting this to false would require the entire response to be buffered up (so that total length could be calculated) before anything was written. The additional “\r\n” characters you are seeing are part of the “chunking” format. It is made up of several bytes at the beginning of the chunk describing the length of that chunk and has the new line chars marking the end of the chunk. This does not cause any problems for SOAP, MTOM, or any other type of response data.

 

How MTOM manages the binary content (whether base 64 encode in the xml itself or reference binary content) is a completely independent issue. I have not looked at the 1.6 version yet, but in the previous 1.x versions, the size threshold was configurable. I believe it was in the axis.xml file, but I am not certain.

 

[1] - http://en.wikipedia.org/wiki/Chunked_transfer_encoding

 

Brett Okken | CAMM Platform Services | Lead Architect | 816.201.6112 | www.cerner.com | [hidden email]

 

From: Stadelmann Josef [mailto:[hidden email]]
Sent: Monday, June 24, 2013 3:49 AM
To: [hidden email]
Subject: AW: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

 

Hi Martin.

 

very much thanks for your greate and extensive help;

however I have still difficulties to get worlds together;

 

 

there is on one part of what WE have, fully based on axis2-1.6.1/samples/jaxws-samples.

And there is another part to be developerd to sniff in an option object and values to make things going.

 

 

In the example code you find a jaxws for echo, ping  and mtom. My file service is fully based on this mtom samples part found, slightly refactored to reflect the file service characteristics it should finaly have; it has a send method in the example; so as reference I started with the send() as well, which is just looping back an image depot.

 

my service and client is then extended by a upload() and a download() method passing parameters i.e. a file path to the to be downloaded file.

 

Now – we should look at the proxy server part of SamplesMTOMTests.java

 

In the axis2-1.6.1/samples/jaxws-samples you can find in class SampleMTOMTests.java

and there you can find

 

     *

     * @param result - String - used to pass back results to servlet.

     * @return String - the input string or null

     * @throws Exception

     */

    public String testMtomWithProxy(String result, URL url) throws Exception {

 

. . .

 

        // Setup the necessary JAX-WS artifacts

        try {

            if (soap12) {

                // Use the generated proxy

                MtomSample12PortProxy proxy = new MtomSample12PortProxy(url);

                proxy._getDescriptor().setEndpoint(uriString + urlSuffix);

 

                // Enable MTOM

                BindingProvider bp = (BindingProvider) proxy._getDescriptor().getProxy();

                SOAPBinding binding = (SOAPBinding) bp.getBinding();

                binding.setMTOMEnabled(true);

 

                // Send the image and process the response image

                response = proxy.sendImage(imageDepot);

            } else {

                // SOAP 1.1 Create the service

                //                       Use the generated proxy

 

 

The part I have potentially to extend with an option object starts with if (soap12) buty might be similar for the else-part for soap11.

 

What I do not know is: which classes on this examples I have to modify to sniff in / to get a

a)     service client or the like to get an

b)    options

c)     to pass options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.FALSE);

d)    to see if it passes binary data

 

options to be used following your explanations above.

 

                MtomSample12PortProxy proxy = new MtomSample12PortProxy(url);

                proxy._getDescriptor().setEndpoint(uriString + urlSuffix);

 

                // Enable MTOM

                BindingProvider bp = (BindingProvider) proxy._getDescriptor().getProxy();

                SOAPBinding binding = (SOAPBinding) bp.getBinding();

                binding.setMTOMEnabled(true);

 

                // Send the image and process the response image

                response = proxy.sendImage(imageDepot);

 

looking at this few lines of code I have no clue where to get the serviceClient from to ask for his options.

 

The closes I was is to get/ask for a request context to pass

 

                Map<String, Object> rc = proxy._getDescriptor().getDispatch().getRequestContext();

                rc.put(HTTPConstants.CHUNKED, Boolean.FALSE);

 

But that fails for reasons already explained in my previous e-mail. also and again: other data is also not passed to the context object as used by the sender. (as explained)

 

 

While I understand what you do with this code

  org.apache.axis2.client.Options options = new org.apache.axis2.client.Options();
  options.setProperty(HTTPConstants.HTTP_PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_11);
   options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);
   org.apache.axis2.client.ServiceClient sender = new org.apache.axis2.client.ServiceClient(configcontext, service);
   
   sender.setOptions(options);

I do not understand how to bring this objects/functionality together with a (generated) proxy client as shown in the axis2-1.6.1/samples/jaxws-sampl.

 

and for the jaxws-samples: It was a alltime my understanding that MTOM was for BINARY not for CHUNKED data!

and that a MTOM sample should actually transfers BINARY data without going via all the options. Joint with MTOM enabled, if then CHUNKED is the default, sniffing in "\r\n" into the data stream to the service, then I get the impression that the way this is done is not so propper.  

 

 

Maybe one can say a word how to annotate JAXWS classes used to make it transfer MTOM BINNARY data and not MTOM CHUNKED data. (if this ever makes sense)

 

Also there is a TRESHOLD somewhere used to define the size of binary converted and transferred within the SOAP body as opposed to be transferred as attachment.

Does that work as well?

 

Very thanks full for any hint; I already dived deep into axis2-1.6.1 code and into CommonsHTTPTransportSender code to see how the work together passing the CHUNKED (TRUE) or BINRAY (FALSE) indicator to make the sender transporting binaries.

 

Josef

 

 

Josef

 

 

 

 

 

Von: Martin Gainty [mailto:[hidden email]]
Gesendet: Freitag, 21. Juni 2013 12:52
An: [hidden email]
Betreff: RE: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

 

 


Subject: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically
Date: Thu, 20 Jun 2013 15:59:41 +0200
From: [hidden email]
To: [hidden email]

Guten Tag Martin,

 

vielen Dank

 

I have identified in this direction as well

options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);

 

But how do I go for binary ?

 

In a previous response from you, you said, to avoid the "\r\n" problem I have to set
<parameter name="Transfer-Encoding">binary</parameter> on either side.

 

The question is how do I do that using a JAX-WS client and servise?

 

Does that imply that when I do

options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.FALSE);

MG>Informs Sender  How to transmit 

 

it will force

MG>no relationship to other HTTP Headers 

 

org.apache.axis2.transport.http.CommonsHTTPTransportSender

to use a "BINARY" encoding for the header and the content in the SOAP envelope ?

MG>what to send... BINARY or TEXT

MG>JAX-WS: HTTP Header must be set to Content-Transfer-Encoding: binary e.g.
MG>JAX-WS: writeln("Content-Transfer-Encoding: binary", outputstream);

MG>SOAP-USING-AXIS <parameter name="Transfer-Encoding">binary</parameter>

MG>Configuring Binary Attachment DataHandlers for response:

 // Create a dataHandler using the fileDataSource. Any implementation of
  // javax.activation.DataSource interface can fit here.
  DataHandler dataHandler = new DataHandler(fileDataSource);
  base64Binary.setBase64Binary(dataHandler);
  MTOMSampleMTOMSampleSOAP11Port_httpStub.ContentType_type0 param = new MTOMSampleMTOMSampleSOAP11Port_httpStub.ContentType_type0();
        param.setContentType_type0(dataHandler.getContentType());
        base64Binary.setContentType(param);
  attachmentType.setBinaryData(base64Binary);
  attachmentType.setFileName(destination);
  attachmentRequest.setAttachmentRequest(attachmentType);

  MTOMSampleMTOMSampleSOAP11Port_httpStub.AttachmentResponse response = serviceStub.attachment(attachmentRequest);
MG>

MG>likewise when sending information to AxisService you need a special Binary dataHandler e.g.

MG>options.setProperty(org.apache.axiom.om.OMConstants.DATA_HANDLER, dataHandler);
MG>a MTOM Aware reader example when Transfer-Encoding is binary

MG> if (isReaderMTOMAware(reader)
                                            &&
                                            java.lang.Boolean.TRUE.equals(reader.getProperty(org.apache.axiom.om.OMConstants.IS_BINARY)))
                                    {
                                        //MTOM aware reader - get the datahandler directly and put it in the object
                                        object.setParam1(
                                                (javax.activation.DataHandler) reader.getProperty(org.apache.axiom.om.OMConstants.DATA_HANDLER));

MG>

 

I found at org.apache.axis2.transport.http.CommonsHTTPTransportSender

            boolean chunked;

            if (messageContext.getProperty(HTTPConstants.CHUNKED) != null) {

                chunked = JavaUtils.isTrueExplicitly(messageContext

                        .getProperty(HTTPConstants.CHUNKED));

            } else {

                chunked = defaultChunked;

            }

 

at the very moment it executes chunked = defaultChunked; which is TRUE by default,

which means that so far I am unable to set the chunked value to false

 

MG>options.setProperty(HTTPConstants.CHUNKED, Boolean.TRUE);

MG>sender.setOptions(options);

 

 

Josef

MG>Martin

 

Von: Martin Gainty [[hidden email]]
Gesendet: Donnerstag, 20. Juni 2013 14:07
An: [hidden email]
Betreff: RE: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

 

Guten Tag Josef!

axis2.xml declarator:
<transportSender name="http"
                     class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
        <parameter name="PROTOCOL">HTTP/1.1</parameter>
        <parameter name="Transfer-Encoding">chunked</parameter>

programmatic:
  org.apache.axis2.client.Options options = neworg.apache.axis2.client.Options();
  options.setProperty(HTTPConstants.HTTP_PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_11);
   options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);
   org.apache.axis2.client.ServiceClient sender = new org.apache.axis2.client.ServiceClient(configcontext, service);
   
   sender.setOptions(options);

?
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] how to configire JAX-WS MTOM client / service programmatically
Date: Thu, 20 Jun 2013 12:43:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin é all

 

I have found that a SOAPBinding.java allows i.e.

isMTOMEnabled() 

setMTOMEnabled(true)

setMTOMThreshold(2048);

 

will check what the threshold value shows on effects and maybe side effects on either side and applications,

 

BUT

Where and how can I select that Transfer-Encoding is changed from chunked to binary for a JAX-WS Annotation based client and for a service by program control.

Doing so a) by configuration or b) programmatic is it guaranteed that only the service doing so is configured.

 

Note: a JAX-WS does not need a service.xml, so configuring the transport on a per-service-base for a given service using service.xml is a no-go

 

So how can I configure my transport used in my JAX-WS client / JAX-WS service programmatically?

 

again:

if each clinet / servide has a Axis2.xml is it by definition assured that such type of "global configuration" are not overriding among already configured clients/service

 

i.e. we have only 1 axis2 engine running;

setting transfer encoding to chunked for webservice1 will transfer encoding binary for webservice2 also override transfer-encoding chunked for webservice1?

 

are all configurations made in one of the many axis2.xmls influencing all web-services-configurations or only the on for which it is delivered in /WEB-INF/conf ?

 

Josef

 

 

Von: Martin Gainty [[hidden email]]
Gesendet: Freitag, 19. April 2013 00:36
An: [hidden email]
Betreff: RE: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

 

ISO8859-1 is the standard for Latin based languages..AFAIK ISO8859-1 Character Set should *not* have an impact..
I remember the *FUN* we experienced at the bank while  porting our ISO8859-1  based Axis Services and client stubs to 'American' UTF-8

One more thing that (I thought of while reading your response) This *sounds* like you may be using Chunked-encoding  (instead of binary)
The SOAP-Envelope is *supposed* to be reconstructed from the fragments sent to Servlet Connector and handed to the Axis Service *intact*

Turn off chunked-encoding on both sides and set Transfer-Encoding to binary in  .\WEB-INF\conf\Axis2.xml  e.g.

<transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
   ....
   <parameter name="Transfer-Encoding">binary</parameter>
.....
</transportSender>

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.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.



 


Subject: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client
Date: Thu, 18 Apr 2013 10:02:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin

 

let me ask and comment on your response.

 

Von: Martin Gainty [[hidden email]]
Gesendet: Donnerstag, 18. April 2013 00:43
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: <[hidden email]>[\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@..."/></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 [[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: [hidden email] For additional commands, e-mail: [hidden email]

CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
Reply | Threaded
Open this post in threaded view
|

RE: AW: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

Martin Gainty
In reply to this post by Stadelmann Josef-2

MG>Aw:
______________________________________________
Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Ez az üzenet bizalmas.  Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett.  Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs.  Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt.

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.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.


 



Subject: AW: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically
Date: Mon, 24 Jun 2013 10:49:11 +0200
From: [hidden email]
To: [hidden email]

Hi Martin.

 

very much thanks for your greate and extensive help;

however I have still difficulties to get worlds together;

 

 

there is on one part of what WE have, fully based on axis2-1.6.1/samples/jaxws-samples.

And there is another part to be developerd to sniff in an option object and values to make things going.

 

 

In the example code you find a jaxws for echo, ping  and mtom. My file service is fully based on this mtom samples part found, slightly refactored to reflect the file service characteristics it should finaly have; it has a send method in the example; so as reference I started with the send() as well, which is just looping back an image depot.

 

my service and client is then extended by a upload() and a download() method passing parameters i.e. a file path to the to be downloaded file.

 

Now – we should look at the proxy server part of SamplesMTOMTests.java

 

In the axis2-1.6.1/samples/jaxws-samples you can find in class SampleMTOMTests.java

and there you can find

 

     *

     * @param result - String - used to pass back results to servlet.

     * @return String - the input string or null

     * @throws Exception

     */

    public String testMtomWithProxy(String result, URL url) throws Exception {

 

. . .

 

        // Setup the necessary JAX-WS artifacts

        try {

            if (soap12) {

                // Use the generated proxy

                MtomSample12PortProxy proxy = new MtomSample12PortProxy(url);

                proxy._getDescriptor().setEndpoint(uriString + urlSuffix);

 

                // Enable MTOM

                BindingProvider bp = (BindingProvider) proxy._getDescriptor().getProxy();

                SOAPBinding binding = (SOAPBinding) bp.getBinding();

                binding.setMTOMEnabled(true);

 

                // Send the image and process the response image

                response = proxy.sendImage(imageDepot);

            } else {

                // SOAP 1.1 Create the service

                //                       Use the generated proxy

 

 

The part I have potentially to extend with an option object starts with if (soap12) buty might be similar for the else-part for soap11.

 

What I do not know is: which classes on this examples I have to modify to sniff in / to get a

a)     service client or the like to get an

b)    options

c)     to pass options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.FALSE);

d)    to see if it passes binary data

MG>modify SampleClient.java for options.setProperty
MG>modify axis2.xml e.g

&lt;transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender"&gt;
   &lt;parameter name="PROTOCOL"&gt;HTTP/1.1&lt;/parameter&gt;
   &lt;parameter name="Transfer-Encoding"&gt;chunked&lt;/parameter&gt;
&lt;/transportSender&gt;

MG>

 

options to be used following your explanations above.

 

                MtomSample12PortProxy proxy = new MtomSample12PortProxy(url);

                proxy._getDescriptor().setEndpoint(uriString + urlSuffix);

 

                // Enable MTOM

                BindingProvider bp = (BindingProvider) proxy._getDescriptor().getProxy();

                SOAPBinding binding = (SOAPBinding) bp.getBinding();

                binding.setMTOMEnabled(true);

 

                // Send the image and process the response image

                response = proxy.sendImage(imageDepot);

 

MG>MTOMSampleServlet.java contains sample client whose options can be modified
MG> try {

...
                client.setOptions(uriString,Transfer-Encoding,"chunked");

..
MG>

 

MG>generally (with exception of MTOMSampleServlet.java  ) clientstub != ServiceStub
MG>MtomSample12PortProxy.java is ServiceStub code so modify axis2.xml to get your binary option in
MG><parameter name="Transfer-Encoding">binary</parameter>

 

looking at this few lines of code I have no clue where to get the serviceClient from to ask for his options.

 

The closes I was is to get/ask for a request context to pass

 

                Map<String, Object> rc = proxy._getDescriptor().getDispatch().getRequestContext();

                rc.put(HTTPConstants.CHUNKED, Boolean.FALSE);

 

But that fails for reasons already explained in my previous e-mail. also and again: other data is also not passed to the context object as used by the sender. (as explained)


MG> runSampleMtom -h [hostname] -p [port] -f [urlSuffix] -i [imageFilename] -d -x -1 -2  -d = (Use Dispatch Only)
MG> runSampleMtom -h [hostname] -p [port] -f [urlSuffix] -i [imageFilename] -d -x -1 -2  -x = (Use Proxy Only)

 

 

While I understand what you do with this code

  org.apache.axis2.client.Options options = new org.apache.axis2.client.Options();
  options.setProperty(HTTPConstants.HTTP_PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_11);
   options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);
   org.apache.axis2.client.ServiceClient sender = new org.apache.axis2.client.ServiceClient(configcontext, service);
   
   sender.setOptions(options);

I do not understand how to bring this objects/functionality together with a (generated) proxy client as shown in the axis2-1.6.1/samples/jaxws-sampl.

MG>this isnt a proxy such as Spring injected Proxy so proxy is just a name to call the constructed object to act on our url
MG>MtomSample12PortProxy proxy = new MtomSample12PortProxy(url);
MG>  public MtomSample12PortProxy(URL wsdlLocation) {
MG>First param assigns a namespace that XSD will be using
        _descriptor = new Descriptor(wsdlLocation, new QName("http://org/apache/axis2/jaxws/samples/mtom/",
"MtomSampleService12"));
MG>the name of the service is MtomSampleService12
,,,,
 public Descriptor(URL wsdlLocation, QName serviceName) {
            _service = new MtomSampleService12(wsdlLocation, serviceName);
            initCommon();
        }

...
MG>
    }

 

and for the jaxws-samples: It was a alltime my understanding that MTOM was for BINARY not for CHUNKED data!

and that a MTOM sample should actually transfers BINARY data without going via all the options. Joint with MTOM enabled, if then CHUNKED is the default, sniffing in "\r\n" into the data stream to the service, then I get the impression that the way this is done is not so propper.  

MG>BINARY is content-format (format of what you are sending)
MG>CHUNKED is a HTTP 1.1 specific Transport algorithm for how to transport data on a connector..Connector must be
MG>1)HTTP 1.1
MG>2)CHUNKED enabled
MG>request guidance from sys-admin  on what protocols his container connector(s) currently supports

 

 

Maybe one can say a word how to annotate JAXWS classes used to make it transfer MTOM BINNARY data and not MTOM CHUNKED data. (if this ever makes sense)
MG>CHUNKED cannot be handled by annotations as this happens at the connector level
MG>BINARY not yet placed into Annotations

MG>here are the JAX-WS definitions
MG> static final QName QNAME_TYPE_BASE64_BINARY = new QName(NS_XSD, "base64Binary");
 MG>   static final QName QNAME_TYPE_HEX_BINARY = new QName(NS_XSD, "hexBinary");
MG>set the binary characteristics by setting Contnet-Transfer-Encoding in HTTP-HEADER of Request e.g.
MG>jax-ws: HTTPClientTransport reqHeaders  writeln("Content-Transfer-Encoding: binary", outputstream);
MG>jax-ws: which you get when you call MTOMCodec.writeMimeHeaders
MG>jax-ws: or when type is set to xop+xml e.g. Content-Type: type="application/xop+xml"

 

Also there is a TRESHOLD somewhere used to define the size of binary converted and transferred within the SOAP body as opposed to be transferred as attachment.

Does that work as well?
MG>THRESHOLD is used when file-caching is implemented by axis2

<p>The following parameters need to be set in Axis2.xml in order to enable file caching.</p>
<pre>&lt;axisconfig name="AxisJava2.0"&gt;

    &lt;!-- ================================================= --&gt;
    &lt;!-- Parameters --&gt;
    &lt;!-- ================================================= --&gt;
    &lt;parameter name="cacheAttachments"&gt;true&lt;/parameter&gt;
    &lt;parameter name="attachmentDIR"&gt;temp&lt;/parameter&gt;

    &lt;parameter name="sizeThreshold"&gt;4000&lt;/parameter&gt;
&lt;/axisconfig&gt;</pre>
MG>

 

Very thanks full for any hint; I already dived deep into axis2-1.6.1 code and into CommonsHTTPTransportSender code to see how the work together passing the CHUNKED (TRUE) or BINRAY (FALSE) indicator to make the sender transporting binaries.

 

Josef
MG>mit freundlichen grüßen
MG>Martin

 

 

Josef

 

 

 

 

 

Von: Martin Gainty [mailto:[hidden email]]
Gesendet: Freitag, 21. Juni 2013 12:52
An: [hidden email]
Betreff: RE: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

 

 


Subject: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically
Date: Thu, 20 Jun 2013 15:59:41 +0200
From: [hidden email]
To: [hidden email]

Guten Tag Martin,

 

vielen Dank

 

I have identified in this direction as well

options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);

 

But how do I go for binary ?

 

In a previous response from you, you said, to avoid the "\r\n" problem I have to set
<parameter name="Transfer-Encoding">binary</parameter> on either side.

 

The question is how do I do that using a JAX-WS client and servise?

 

Does that imply that when I do

options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.FALSE);

MG>Informs Sender  How to transmit 

 

it will force

MG>no relationship to other HTTP Headers 

 

org.apache.axis2.transport.http.CommonsHTTPTransportSender

to use a "BINARY" encoding for the header and the content in the SOAP envelope ?

MG>what to send... BINARY or TEXT

MG>JAX-WS: HTTP Header must be set to Content-Transfer-Encoding: binary e.g.
MG>JAX-WS: writeln("Content-Transfer-Encoding: binary", outputstream);

MG>SOAP-USING-AXIS <parameter name="Transfer-Encoding">binary</parameter>

MG>Configuring Binary Attachment DataHandlers for response:

 // Create a dataHandler using the fileDataSource. Any implementation of
  // javax.activation.DataSource interface can fit here.
  DataHandler dataHandler = new DataHandler(fileDataSource);
  base64Binary.setBase64Binary(dataHandler);
  MTOMSampleMTOMSampleSOAP11Port_httpStub.ContentType_type0 param = new MTOMSampleMTOMSampleSOAP11Port_httpStub.ContentType_type0();
        param.setContentType_type0(dataHandler.getContentType());
        base64Binary.setContentType(param);
  attachmentType.setBinaryData(base64Binary);
  attachmentType.setFileName(destination);
  attachmentRequest.setAttachmentRequest(attachmentType);

  MTOMSampleMTOMSampleSOAP11Port_httpStub.AttachmentResponse response = serviceStub.attachment(attachmentRequest);
MG>

MG>likewise when sending information to AxisService you need a special Binary dataHandler e.g.

MG>options.setProperty(org.apache.axiom.om.OMConstants.DATA_HANDLER, dataHandler);
MG>a MTOM Aware reader example when Transfer-Encoding is binary

MG> if (isReaderMTOMAware(reader)
                                            &&
                                            java.lang.Boolean.TRUE.equals(reader.getProperty(org.apache.axiom.om.OMConstants.IS_BINARY)))
                                    {
                                        //MTOM aware reader - get the datahandler directly and put it in the object
                                        object.setParam1(
                                                (javax.activation.DataHandler) reader.getProperty(org.apache.axiom.om.OMConstants.DATA_HANDLER));

MG>

 

I found at org.apache.axis2.transport.http.CommonsHTTPTransportSender

            boolean chunked;

            if (messageContext.getProperty(HTTPConstants.CHUNKED) != null) {

                chunked = JavaUtils.isTrueExplicitly(messageContext

                        .getProperty(HTTPConstants.CHUNKED));

            } else {

                chunked = defaultChunked;

            }

 

at the very moment it executes chunked = defaultChunked; which is TRUE by default,

which means that so far I am unable to set the chunked value to false

 

MG>options.setProperty(HTTPConstants.CHUNKED, Boolean.TRUE);

MG>sender.setOptions(options);

 

 

Josef

MG>Martin

 

Von: Martin Gainty [[hidden email]]
Gesendet: Donnerstag, 20. Juni 2013 14:07
An: [hidden email]
Betreff: RE: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

 

Guten Tag Josef!

axis2.xml declarator:
<transportSender name="http"
                     class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
        <parameter name="PROTOCOL">HTTP/1.1</parameter>
        <parameter name="Transfer-Encoding">chunked</parameter>

programmatic:
  org.apache.axis2.client.Options options = neworg.apache.axis2.client.Options();
  options.setProperty(HTTPConstants.HTTP_PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_11);
   options.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED, Boolean.TRUE);
   org.apache.axis2.client.ServiceClient sender = new org.apache.axis2.client.ServiceClient(configcontext, service);
   
   sender.setOptions(options);

?
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] how to configire JAX-WS MTOM client / service programmatically
Date: Thu, 20 Jun 2013 12:43:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin é all

 

I have found that a SOAPBinding.java allows i.e.

isMTOMEnabled() 

setMTOMEnabled(true)

setMTOMThreshold(2048);

 

will check what the threshold value shows on effects and maybe side effects on either side and applications,

 

BUT

Where and how can I select that Transfer-Encoding is changed from chunked to binary for a JAX-WS Annotation based client and for a service by program control.

Doing so a) by configuration or b) programmatic is it guaranteed that only the service doing so is configured.

 

Note: a JAX-WS does not need a service.xml, so configuring the transport on a per-service-base for a given service using service.xml is a no-go

 

So how can I configure my transport used in my JAX-WS client / JAX-WS service programmatically?

 

again:

if each clinet / servide has a Axis2.xml is it by definition assured that such type of "global configuration" are not overriding among already configured clients/service

 

i.e. we have only 1 axis2 engine running;

setting transfer encoding to chunked for webservice1 will transfer encoding binary for webservice2 also override transfer-encoding chunked for webservice1?

 

are all configurations made in one of the many axis2.xmls influencing all web-services-configurations or only the on for which it is delivered in /WEB-INF/conf ?

 

Josef

 

 

Von: Martin Gainty [[hidden email]]
Gesendet: Freitag, 19. April 2013 00:36
An: [hidden email]
Betreff: RE: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client

 

ISO8859-1 is the standard for Latin based languages..AFAIK ISO8859-1 Character Set should *not* have an impact..
I remember the *FUN* we experienced at the bank while  porting our ISO8859-1  based Axis Services and client stubs to 'American' UTF-8

One more thing that (I thought of while reading your response) This *sounds* like you may be using Chunked-encoding  (instead of binary)
The SOAP-Envelope is *supposed* to be reconstructed from the fragments sent to Servlet Connector and handed to the Axis Service *intact*

Turn off chunked-encoding on both sides and set Transfer-Encoding to binary in  .\WEB-INF\conf\Axis2.xml  e.g.

<transportSender name="http" class="org.apache.axis2.transport.http.CommonsHTTPTransportSender">
   ....
   <parameter name="Transfer-Encoding">binary</parameter>
.....
</transportSender>

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.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.



 


Subject: AW: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client
Date: Thu, 18 Apr 2013 10:02:22 +0200
From: [hidden email]
To: [hidden email]

Hi Martin

 

let me ask and comment on your response.

 

Von: Martin Gainty [[hidden email]]
Gesendet: Donnerstag, 18. April 2013 00:43
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: <[hidden email]>[\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@..."/></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 [[hidden email]]
Gesendet: Dienstag, 16. April 2013 11:54
An: [hidden email]
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: [hidden email]
To: [hidden email]

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: [hidden email] For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

Stadelmann Josef-2
In reply to this post by Okken,Brett

Thank you Brett

 

you write

The additional “\r\n” characters you are seeing are part of the “chunking” format.

 

my question: What defines the length for each chunk?

As far as I can see --- every chunk is passed to the network --- a call is required to do so --- generating a lot overhead --- making my thing sooooo slow.

 

my comment: Given the length of the chunk is determined by the "\r\n" sequence in a stream of binary data -- then it is very likely that we send thousands of little chunks for a 25 MB (axis2.zip)  file each with great network overhead – which makes my system slow. That is what I see if I turn on the wire logger or look at the wire with WireShark.

 

what would you recommend to use for a most efficient binary data transfer which does not need to go into memory in total first but can be streamed A to B over the network with as low overhead as possible.

 

Josef

 

 

Von: Okken,Brett [mailto:[hidden email]]
Gesendet: Montag, 24. Juni 2013 14:40
An: [hidden email]
Betreff: RE: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

 

It was a alltime my understanding that MTOM was for BINARY not for CHUNKED data!

and that a MTOM sample should actually transfers BINARY data without going via all the options. Joint with MTOM enabled, if then CHUNKED is the default, sniffing in "\r\n" into the data stream to the service, then I get the impression that the way this is done is not so propper.  

 

 

Maybe one can say a word how to annotate JAXWS classes used to make it transfer MTOM BINNARY data and not MTOM CHUNKED data. (if this ever makes sense)

 

It seems to me that 2 different concepts are being conflated here. I believe that the org.apache.axis2.transport.http.HTTPConstants.CHUNKED property is used to control the http transfer encoding[1]. This functionality was introduced with http 1.1 and removes the requirement to know the entire length of the response before being able to send any data. Setting this to false would require the entire response to be buffered up (so that total length could be calculated) before anything was written. The additional “\r\n” characters you are seeing are part of the “chunking” format. It is made up of several bytes at the beginning of the chunk describing the length of that chunk and has the new line chars marking the end of the chunk. This does not cause any problems for SOAP, MTOM, or any other type of response data.

 

How MTOM manages the binary content (whether base 64 encode in the xml itself or reference binary content) is a completely independent issue. I have not looked at the 1.6 version yet, but in the previous 1.x versions, the size threshold was configurable. I believe it was in the axis.xml file, but I am not certain.

 

[1] - http://en.wikipedia.org/wiki/Chunked_transfer_encoding

 

Brett Okken | CAMM Platform Services | Lead Architect | 816.201.6112 | www.cerner.com | [hidden email]

 

From: Stadelmann Josef [[hidden email]]
Sent: Monday, June 24, 2013 3:49 AM
To: [hidden email]
Subject: AW: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically

 

Hi Martin.

 

very much thanks for your greate and extensive help;

however I have still difficulties to get worlds together;

 

 

there is on one part of what WE have, fully based on axis2-1.6.1/samples/jaxws-samples.

And there is another part to be developerd to sniff in an option object and values to make things going.

 

 

In the example code you find a jaxws for echo, ping  and mtom. My file service is fully based on this mtom samples part found, slightly refactored to reflect the file service characteristics it should finaly have; it has a send method in the example; so as reference I started with the send() as well, which is just looping back an image depot.

 

my service and client is then extended by a upload() and a download() method passing parameters i.e. a file path to the to be downloaded file.

 

Now – we should look at the proxy server part of SamplesMTOMTests.java

 

In the axis2-1.6.1/samples/jaxws-samples you can find in class SampleMTOMTests.java

and there you can find

 

     *

     * @param result - String - used to pass back results to servlet.

     * @return String - the input string or null

     * @throws Exception

     */