Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <20040920031450.44003.qmail@web40609.mail.yahoo.com>
Date: Sun, 19 Sep 2004 20:14:50 -0700 (PDT)
From: Samisa Abeysinghe <samisa_abeysinghe@yahoo.com>
Subject: Re: multi-threading or performance and easy to work with code ? [Re:
 Analysis of Axis C++ client transport
To: Apache AXIS C Developers List <axis-c-dev@ws.apache.org>
In-Reply-To: <414B34B8.4000906@cs.indiana.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi Alec,
    What I meant by multi threads here is that if the users want to use the subs in a threaded
envioronment, then Axis c++ lib should support that.
   I do not want the transport (or any other part of Axis C++) to use threads. However, for those
who wish to use the multiple stubs in threads, we have to make sure that Axis C++ lib is thread
safe.
   I am *totally* in sync with you regarding the trouble that we bring into the code if we try to
make Axis C++ code multithreaded. 
   However we could refrain from using static globles etc..

Thansk,
Samisa...


--- Aleksander Slominski <aslom@cs.indiana.edu> wrote:

> hi,
> 
> i am not sure by what you mean when you talk about multi-thread 
> transport and performance. it is much more efficient to avoid 
> synchronization required for multiple threads and simply attach 
> transport state to stub/skeleton. the only multi-thread re-use i would 
> worry is for sockets when doing  HTTP keep-alive. otherwise performance 
> decreases, code complexity increases, and you have host of lovely bugs 
> typical in concurrent programming emerge ...
> 
> so i would aim for good design, ease of understanding, simplicity, and 
> performance in this order - multi-threading adds so much complexity that 
> it must be really really required to go this route and anyway i think 
> most of XML parsers are not multi-thread safe and that is where are 
> typical SOAP stack bottlenecks (CPU bound) not in network (IO bound) ...
> 
> just my .02PLN
> 
> alek
> 
> Samisa Abeysinghe wrote:
> 
> >Hi John,
> >   I believe that if we could get rid of the static globles then this new transport as well as
> the
> >LibWWW transport would be thread safe. (However it is a *belief*, we have to practically try
> and
> >see)
> >   If we could get LibWWW working with threads, then that is the best, as it supports many
> >transports - not only HTTP - and we do not have to bother about transport specific stuff such
> as
> >chunking etc.
> >
> >    I would try and see if we could get rid of static globles and if that would free us from
> >threading problems. 
> >
> >Reagrds,
> >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]);
> >>             }
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail