axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: Analysis of Axis C++ client transport
Date Fri, 24 Sep 2004 19:03:57 GMT
hi,

i think if message size is bigger than some threshold or if underlying 
IO stream is flushed then chunk is sent (and yes i have seen this with  
my own eyes in tomcat 4.19 yesterday in my own app) - so even if SOAP 
APP writes all in one chunk it may be sent in multiple chunks ...

BTW: what Maels(t)rom you are talking about - i am pretty sure it is not 
http://www.devolution.com/~slouken/Maelstrom/
something more along lines of 
com.*ibm*.edge.webservices.systemservices.*maelstrom*. from ETTK?

thanks,

alek

John Hawkins wrote:

>
>
>Maelsrom - It does do multiple chunks (we've seen them with our own eyes
>not just specced ;-)
>
>
>John Hawkins
>
>
>
>
>                                                                           
>             "Sanjiva                                                      
>             Weerawarana"                                                  
>             <sanjiva@opensour                                          To 
>             ce.lk>                    "Apache AXIS C Developers List"     
>                                       <axis-c-dev@ws.apache.org>          
>             24/09/2004 09:57                                           cc 
>                                                                           
>                                                                   Subject 
>             Please respond to         Re: Analysis of Axis C++ client     
>              "Apache AXIS C           transport                           
>             Developers List"                                              
>                                                                           
>                                                                           
>                                                                           
>                                                                           
>                                                                           
>
>
>
>
>One chunk .. WAS uses Axis/Java. Unless you're referring to
>Maelstrom .. in which case I don't know whether it does real
>chunking.
>
>Sanjiva.
>
>----- Original Message -----
>From: "John Hawkins" <HAWKINSJ@uk.ibm.com>
>To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
>Sent: Friday, September 24, 2004 2:32 PM
>Subject: Re: Analysis of Axis C++ client transport
>
>
>  
>
>>
>>
>>WAS  does chunking - this is where we found the issue in the first place
>>:-)
>>
>>
>>John Hawkins
>>
>>
>>
>>
>>
>>             "Sanjiva
>>             Weerawarana"
>>             <sanjiva@opensour
>>    
>>
>To
>  
>
>>             ce.lk>                    "Apache AXIS C Developers List"
>>                                       <axis-c-dev@ws.apache.org>
>>             23/09/2004 17:24
>>    
>>
>cc
>  
>
>>    
>>
>Subject
>  
>
>>             Please respond to         Re: Analysis of Axis C++ client
>>              "Apache AXIS C           transport
>>             Developers List"
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>I don't get why we're bothering with chunking .. can you tell
>>me which server-side does chunking right now? Axis/Java
>>certainly does not - it always sends one chunk!
>>
>>Also, if we're not doing keep-alive, then you can forget
>>about computing content length and just stream the output thru
>>without bufferring. That gives you the memory benefit you get
>>from chunking at a loss of the keep-alive feature. As we
>>move forward in Web services in a more message-oriented model,
>>I don't see keep-alive being such a vital feature: its not
>>likely that apps will do series of very small and repeated
>>calls between the same client and server.
>>
>>I suggest we forget chunking and add an option at least to turn
>>off bufferring and content-length computation. That will give
>>us even more speed!
>>
>>Sanjiva.
>>
>>----- Original Message -----
>>From: "John Hawkins" <HAWKINSJ@uk.ibm.com>
>>To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
>>Sent: Thursday, September 23, 2004 4:17 PM
>>Subject: Re: Analysis of Axis C++ client transport
>>
>>
>>    
>>
>>>
>>>
>>>Hi Samisa,
>>>
>>>Does the new transport have support for chunking  (and any other things
>>>that the old transport had)?
>>>
>>>
>>>John Hawkins
>>>
>>>
>>>
>>>
>>>
>>>             Samisa Abeysinghe
>>>             <samisa_abeysingh
>>>             e@yahoo.com>
>>>      
>>>
>>To
>>    
>>
>>>                                       Apache AXIS C Developers List
>>>             23/09/2004 04:20          <axis-c-dev@ws.apache.org>
>>>
>>>      
>>>
>>cc
>>    
>>
>>>             Please respond to
>>>      
>>>
>>Subject
>>    
>>
>>>              "Apache AXIS C           Re: Analysis of Axis C++ client
>>>             Developers List"          transport
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>Hi All,
>>>    The new transport that I was talking about is in CVS
>>>(src/transport/axis2/)
>>>    This borrows many logic from the old one, however there are some
>>>considerable logic changes as
>>>well (but no magic ;-))
>>>
>>>    I strongly suggest that we try using this as the default transport
>>>considering the speed and
>>>the ability to send larger messages. This is also thread safe, after I
>>>      
>>>
>>made
>>    
>>
>>>the initialize_module
>>>possible outside the stub. But before we make this default, it has to
>>>      
>>>
>be
>  
>
>>>tested on Windows
>>>platform; I have so far tested only on Linux platform. Please help with
>>>testing on Windows.
>>>
>>>    I am now working to get LibWWW transport thread safe. This would
>>>      
>>>
>take
>  
>
>>>more effort as there
>>>need to be some lib level inits to be done. LibWWW is important,
>>>considering its rich set of
>>>features.
>>>
>>>Thanks,
>>>Samisa...
>>>
>>>
>>>
>>>--- John Hawkins <HAWKINSJ@uk.ibm.com> wrote:
>>>
>>>      
>>>
>>>>
>>>>
>>>>Wow !!!
>>>>
>>>>The old code was really slow !
>>>>Your code is really fast :-)
>>>>
>>>>We do get other things with libwww though don't we?
>>>>
>>>>
>>>>If your code is better than the current code 9(and we can make it
>>>>        
>>>>
>>thread
>>    
>>
>>>>safe and have the same function) then let's use it and ditch the
>>>>        
>>>>
>>original
>>    
>>
>>>>one?
>>>>
>>>>
>>>>
>>>>John Hawkins
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>             Samisa Abeysinghe
>>>>        
>>>>
>>>>             <samisa_abeysingh
>>>>        
>>>>
>>>>             e@yahoo.com>
>>>>        
>>>>
>>>To
>>>      
>>>
>>>>                                       Apache AXIS C Developers List
>>>>        
>>>>
>>>>             17/09/2004 09:39          <axis-c-dev@ws.apache.org>
>>>>        
>>>>
>>>cc
>>>      
>>>
>>>>             Please respond to
>>>>        
>>>>
>>>Subject
>>>      
>>>
>>>>              "Apache AXIS C           Analysis of Axis C++ client
>>>>        
>>>>
>>>>             Developers List"          transport
>>>>        
>>>>
>>>>
>>>>
>>>>Hi All,
>>>>    Since I was under the impression that the current Axis transport
>>>>        
>>>>
>>lib
>>    
>>
>>>>implementation is much
>>>>slower than LibWWW based implementation I did some measurers on the
>>>>        
>>>>
>>speed
>>    
>>
>>>>with echo string method
>>>>of base sample.
>>>>   The original Axis transport lib was much slower and hence I
>>>>        
>>>>
>>>implemented
>>>      
>>>
>>>>a new socket based Axis
>>>>transport lib with the logic similar to current Axis transport. The
>>>>        
>>>>
>>>results
>>>      
>>>
>>>>are interesting. The
>>>>original Axis transport implementation is too slow, and not only
>>>>        
>>>>
>that,
>  
>
>>it
>>    
>>
>>>>cannot send messages
>>>>lager than 48800 (strage number), if I try to the client segfaults.
>>>>        
>>>>
>The
>  
>
>>>new
>>>      
>>>
>>>>transport lib as well
>>>>as the LibWWW based transport can send much larger messages (I tested
>>>>        
>>>>
>>>upto
>>>      
>>>
>>>>2621440 characters)
>>>>   The other interesting thing is that the new trasport that I
>>>>        
>>>>
>>>implemented
>>>      
>>>
>>>>are faster than LibWWW
>>>>based implementation.
>>>>    Please have a look at the attached HTML file for results.
>>>>
>>>>    At the moment, the Call class creates a new transport object for
>>>>        
>>>>
>>each
>>    
>>
>>>>and every invcation. I
>>>>made the code to reuse the same transport and the code became still
>>>>        
>>>>
>>>faster.
>>>      
>>>
>>>>    However, testing for thread safety, both LibWWW and the new
>>>>        
>>>>
>>transport
>>    
>>
>>>>failed, only the old
>>>>trasport work with threads. I am doubtful of this, because in the new
>>>>transport I have very
>>>>similar logic to that of the old (but not the same) I doubt the old
>>>>transport pretends to be
>>>>thread safe as it is too slow. We have to remove the globle variables
>>>>        
>>>>
>>>from
>>>      
>>>
>>>>the code and see if
>>>>this thread safety problems would persist. We must look into thread
>>>>        
>>>>
>>>safety
>>>      
>>>
>>>>as an immediate high
>>>>priority issue.
>>>>
>>>>    As the code is frozen at the moment for 1.3 I did not commit the
>>>>        
>>>>
>>new
>>    
>>
>>>>trasport. It works for
>>>>chunks as well, however it would have to be tested more to be used in
>>>>production envioronments.
>>>>Hence, even if I put it in cvs, I would like it to be seperate from
>>>>        
>>>>
>the
>  
>
>>>>original Axis transport
>>>>lib. I have removed all cyclic couplings in this new code and hence
>>>>        
>>>>
>it
>  
>
>>>>would be easier to
>>>>maintain.
>>>>
>>>>    I have given below the client code that I used for this testing
>>>>        
>>>>
>>(with
>>    
>>
>>>>base.wsdl generated
>>>>code)
>>>>
>>>>Thanks,
>>>>Samisa...
>>>>
>>>>#include <string>
>>>>#include <iostream>
>>>>#include <time.h>
>>>>#include <stdio.h>
>>>>#include <sys/types.h>
>>>>#include <sys/timeb.h>
>>>>
>>>>#ifdef WIN32
>>>>#else
>>>>#include <sys/times.h>
>>>>#include <unistd.h>
>>>>#endif
>>>>
>>>>
>>>>#include <axis/AxisGenException.h>
>>>>#include "./gen_src/InteropTestPortType.h"
>>>>
>>>>using namespace std;
>>>>
>>>>#define STRING_TO_SEND "HelloWorld"
>>>>
>>>>static void
>>>>usage (char *programName, char *defaultURL)
>>>>{
>>>>    cout << "\nUsage:\n"
>>>>             << programName << " [-? | service_url] " <<
endl
>>>>             << "    -?             Show this help.\n"
>>>>             << "    service_url    URL of the service.\n"
>>>>             << "    Default service URL is assumed to be " <<
>>>>        
>>>>
>>defaultURL
>>    
>>
>>>>             <<
>>>>             "\n    Could use
>>>>        
>>>>
>http://localhost:8080/axis/services/echo
>  
>
>>to
>>    
>>
>>>>test with Axis Java."
>>>>             << endl;
>>>>}
>>>>
>>>>
>>>>int
>>>>main (int argc, char *argv[])
>>>>{
>>>>    int length = 10;
>>>>    char endpoint[256];
>>>>
>>>>    // Set default service URL
>>>>    sprintf (endpoint, "http://localhost/axis/base");
>>>>    // Could use http://localhost:8080/axis/services/echo to test
>>>>        
>>>>
>with
>  
>
>>>Axis
>>>      
>>>
>>>>Java
>>>>
>>>>    try
>>>>    {
>>>>
>>>>             if (argc > 1)
>>>>             {
>>>>                 // Watch for special case help request
>>>>                 if (!strncmp (argv[1], "-", 1)) // Check for - only
>>>>        
>>>>
>so
>  
>
>>>>that it works for
>>>>                                            //-?, -h
>>>>        
>>>>
>>or --help; -anything
>>    
>>
>>>>                 {
>>>>                         usage (argv[0], endpoint);
>>>>                         return 2;
>>>>                 }
>>>>                 length = atoi(argv[1]);
>>>>             }
>>>>
>>>>        if (argc > 2)
>>>>            sprintf (endpoint, argv[2]);
>>>>
>>>>             cout << endl << " Using service at " << endpoint
<< endl
>>>>        
>>>>
>><<
>>    
>>
>>>>endl;
>>>>
>>>>             InteropTestPortType ws (endpoint);
>>>>
>>>>        ws.setTransportTimeout(2);
>>>>
>>>>        // Prepare the string to be sent
>>>>        char* buffer = new char[ length * strlen(STRING_TO_SEND) +
>>>>        
>>>>
>1];
>  
>
>>>>        buffer[0] = '\0';
>>>>        for (int i = 0; i < length; i++ )
>>>>            strcat(buffer, STRING_TO_SEND);
>>>>
>>>>             // Time mesurement stuff
>>>>             time_t startTime;
>>>>        time_t endTime;
>>>>
>>>>             time( &startTime );
>>>>
>>>>        char* echoStringResult = ws.echoString(buffer);
>>>>
>>>>             time( &endTime );
>>>>        printf( "Time spent to invoke method ws.echoString(buffer); =
>>>>        
>>>>
>>%lf
>>    
>>
>>>>s\n", difftime( endTime,
>>>>startTime ) );
>>>>
>>>>             if (0 == strcmp(echoStringResult, buffer))
>>>>                 printf ("successful\n");
>>>>             else
>>>>                 printf ("failed\n");
>>>>
>>>>        // Clean memory
>>>>        if (echoStringResult)
>>>>            free(echoStringResult);
>>>>
>>>>        delete [] buffer;
>>>>
>>>>
>>>>        
>>>>
>>>=== message truncated ===
>>>
>>>
>>>
>>>
>>>_______________________________
>>>Do you Yahoo!?
>>>Declare Yourself - Register online to vote today!
>>>http://vote.yahoo.com
>>>
>>>
>>>
>>>      
>>>
>>
>>
>>    
>>
>
>
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay


Mime
View raw message