axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenneth Chiu <ch...@cs.indiana.edu>
Subject Re: [jira] Commented: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Date Mon, 20 Sep 2004 12:17:45 GMT
I think there might be some confusion between the stub code
and the stub "instance".  If you create two distinct stub
"instances" like:

    MyService s1(...);
    MyService s2(...);

then it should definitely be possible to have thread T1 use
s1 and thread T2 use s2, independently.

However, it's probably not necessary to allow T1 and T2 to
concurrently use s1.

On Sun, 19 Sep 2004, Samisa Abeysinghe wrote:

> 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
>

Mime
View raw message