axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <samisa_abeysin...@yahoo.com>
Subject Re: [jira] Commented: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Date Tue, 21 Sep 2004 01:54:49 GMT
Hi,

--- Kenneth Chiu <chiuk@cs.indiana.edu> wrote:

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

This is what we are trying to achieve. 

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

Yes; and with current desing it is harder than the earlier case.

Samisa...

> 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)
> > > >>{
> 
=== message truncated ===



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Mime
View raw message