axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <mgai...@hotmail.com>
Subject RE: AW: [axis2-1.6.1] how to configire JAX-WS MTOM client / service programmatically
Date Fri, 21 Jun 2013 10:52:03 GMT
 
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: josef.stadelmann@axa-winterthur.ch
To: java-user@axis.apache.org

Guten Tag Martin, vielen Dank I have identified in this direction as welloptions.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 dooptions.setProperty(org.apache.axis2.transport.http.HTTPConstants.CHUNKED,
Boolean.FALSE);MG>Informs Sender  How to transmit   it will forceMG>no relationship
to other HTTP Headers  org.apache.axis2.transport.http.CommonsHTTPTransportSenderto 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);  JosefMG>Martin Von: Martin Gainty [mailto:mgainty@hotmail.com]

Gesendet: Donnerstag, 20. Juni 2013 14:07
An: java-user@axis.apache.org
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: josef.stadelmann@axa-winterthur.ch
To: java-user@axis.apache.orgHi 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, BUTWhere 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:mgainty@hotmail.com] 
Gesendet: Freitag, 19. April 2013 00:36
An: java-user@axis.apache.org
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: josef.stadelmann@axa-winterthur.ch
To: java-user@axis.apache.orgHi Martin let me ask and comment on your response. Von: Martin
Gainty [mailto:mgainty@hotmail.com] 
Gesendet: Donnerstag, 18. April 2013 00:43
An: java-user@axis.apache.org
Betreff: RE: AW: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client Goddag
Josef
 
\r\n is the cuplrit?++ I can see in my log file (I've sent) that some xml soap records end
in [\r][\n]
I can further see that most remaining binary data breaks up the stream at [\n]
I think if the transfer mode is real binary [\r][\n] should never have any impact.Any chance
of doing dos2unix on all the files for your servicewhat do you mean with that? which files
would need treatment?javac  -Dline.separator='\r' *.javaare 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'
*.aarare 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 toolOKand rerun the container with java
-Dline.separator='\r' ContainerBootstrap.jarDo 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 regardsJosef
______________________________________________ Vertraulichkeit und Datenschutz 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten
wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist
unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet
keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen
wir keine Haftung fuer den Inhalt uebernehmen.  Subject: AW: [axis2-1.6.1] java MTOM client
very slow compared to .NET WCF client
Date: Wed, 17 Apr 2013 12:21:08 +0200
From: josef.stadelmann@axa-winterthur.ch
To: java-user@axis.apache.orgHi Martin, turning on DEBUG logging  #--- logging to CL_FAPlog4j.logger.org.apache.commons.httpclient=DEBUG,
CONS, CL_FAPlog4j.additivity.org.apache.commons.httpclient=false log4j.logger.httpclient.wire=DEBUG,
CONS, CL_FAPlog4j.additivity.httpclient.wire=false shows that I have in fact a binary encoding
for the content  2013-04-17 11:42:30,194      DEBUG      httpclient.wire.content      >>
"2364[\r][\n]" 2013-04-17 11:42:30,194      DEBUG      httpclient.wire.content      >>
"--MIMEBoundary_a4d8953e766f4ad5afd4dbda9ddf2e0e0717f1c793e08ff7[\r][\n]" 2013-04-17 11:42:30,194
     DEBUG      httpclient.wire.content      >> "Content-Type: application/xop+xml;
charset=UTF-8; type="application/soap+xml"[\r][\n]" 2013-04-17 11:42:30,194      DEBUG   
  httpclient.wire.content      >> "Content-Transfer-Encoding: binary[\r][\n]" 2013-04-17
11:42:30,194      DEBUG      httpclient.wire.content      >> "Content-ID: <0.b4d8953e766f4ad5afd4dbda9ddf2e0e0717f1c793e08ff7@apache.org>[\r][\n]"
2013-04-17 11:42:30,194      DEBUG      httpclient.wire.content      >> "[\r][\n]" 2013-04-17
11:42:30,194      DEBUG      httpclient.wire.content      >> "<?xml version='1.0'
encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Body><sendImage
xmlns="http://ch/axa/spezpla/fs1/"><input><imageData><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include"
href="cid:e4d8953e766f4ad5afd4dbda9ddf2e0e0717f1c793e08ff7@apache.org"/></imageData></input></sendImage></soapenv:Body></soapenv:Envelope>[\r][\n]"
and it shows octet stream but breaks the stream up into pieces em up at each "\r\n" 2013-04-17
11:42:30,194      DEBUG      httpclient.wire.content      >> "--MIMEBoundary_a4d8953e766f4ad5afd4dbda9ddf2e0e0717f1c793e08ff7[\r][\n]"
2013-04-17 11:42:30,194      DEBUG      httpclient.wire.content      >> "Content-Type:
application/octet-stream[\r][\n]" 2013-04-17 11:42:30,194      DEBUG      httpclient.wire.content
     >> "Content-Transfer-Encoding: binary[\r][\n]"but then the content breaks up into
pices at each "\n" That is why I get such a lousy performance!
WHY Please remember: some weeks ago, my example was fast running as well under a JAVA Client.
So I expect a new maven build getting down some to me yet unknown jar makes this happenat
the java client side awhile at the WCF .NET client side all runs at full speed and transfers
25MB asci2.zip in 5 to 8 seconds to a remote node. full log (until I stopped the apps) is
attached. Josef Von: Martin Gainty [mailto:mgainty@hotmail.com] 
Gesendet: Dienstag, 16. April 2013 11:54
An: java-user@axis.apache.org
Betreff: RE: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client Goddag Josef

Trying to narrow down the environments in play here
NetBeans
AxisClient/AxisService
Network Path
 
what happens when you run Axis client outside of NB?
If your MTOM client achieves consistent rapid results you know NB plugin is at fault

On the other hand if you port the same Axis Client to another box
clean the arp cache and run the AxisClient repeatedly 
If you achieve consistent rapid results you know your Network path (Arp cache?) is at fault
on  box 1

If there is consistent degradation on both boxes over a period of time the problem is with
AxisClient
and or Axis Service

Apologies as this is Not an answer but a means to narrow down the culprit

Viel Gluck,
Martin 
______________________________________________ 
Verzicht und Vertraulichkeitanmerkung

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten
wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist
unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet
keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen
wir keine Haftung fuer den Inhalt uebernehmen.

  Subject: [axis2-1.6.1] java MTOM client very slow compared to .NET WCF client
Date: Mon, 15 Apr 2013 20:54:30 +0200
From: josef.stadelmann@axa-winterthur.ch
To: axis-user@ws.apache.orgHi 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. ! JBut 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.RegardsJosef
--------------------------------------------------------------------- To unsubscribe, e-mail:
java-user-unsubscribe@axis.apache.org For additional commands, e-mail: java-user-help@axis.apache.org
		 	   		  
Mime
View raw message