You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by ax...@ws.apache.org on 2004/07/20 23:13:39 UTC
[jira] Created: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-111
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-111
Summary: Axis C++ doesn't support href/multiRef
Type: Bug
Status: Unassigned
Priority: Major
Project: Axis-C++
Components:
Serialization/Deserialization
Versions:
1.2 Final
Assignee:
Reporter: Alexei Dets
Created: Tue, 20 Jul 2004 2:12 PM
Updated: Tue, 20 Jul 2004 2:12 PM
Environment: RedHat Linux 9
Description:
Axis C++ doesn't understand SOAP requests (and replies) that use <multiRef>. This automatically makes it incompatible, for example, with Axis Java because it uses multiRef by default.
If it is not possible to fix this issue quickly then this issue should be very well documentated and probably it should contain instructions how to switch off multiRefs usage in Axis Java (it _is_ possible). I'm sure that this is a very common source of problems.
For example, if I have an Axis C++ server & an Axis Java client than it is necessary to add to the client something like:
((org.apache.axis.client.Stub)port)._setProperty(org.apache.axis.AxisEngine.PROP_DOMULTIREFS, Boolean.FALSE);
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi,
--- Kenneth Chiu <ch...@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 <as...@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 <HA...@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 <ax...@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
Re: [jira] Commented: (AXISCPP-111) Axis C++ doesn't support
href/multiRef
Posted by Kenneth Chiu <ch...@cs.indiana.edu>.
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 <as...@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 <HA...@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 <ax...@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
>
Re: [jira] Commented: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi Alec,
Thank you for the information.
Samisa...
--- Aleksander Slominski <as...@cs.indiana.edu> wrote:
> Samisa Abeysinghe wrote:
>
> > There are no ongoing work to fix this problem.
> >
> > As I mentioned in an earlier comment in Jira on this issue, the
> > challenge is to get this working with the pull model currently being
> > used by Axis C++ in deserializing. Supporting href would mean the
> > deserializer may have to back-track (or forward leap) in the XML
> > stream, which totally contradicts the existing model, and is not
> > possible with current code - we would have to rewrite the parser
> > algorithm which is parser specific (the next() method ). This means
> > that this task would take some considerable time to implement - a
> > candidate requirement for 1.4 - may be.
>
> Samisa,
>
> it requires more work but it is possible to implement and quite easy
> *with* full streaming model.
>
> in nutshell: you record location of unresolved hrefs (pointers) and when
> parsing is finished you go back and patch every unresolved pointer.
> similar techniques are used in compilers so this is not like a new
> approach ... if you want an example take look on XSOAP 1.2 and mailing
> list archives of different SOAP implementatons where this topic was
> discussed in pas (Apache SOAP, AXIS SOAP/Java, gSOAP, XSOAP, ...)
>
> thanks,
>
> alek
>
> >
> >
> > */Andrew Perry2 <PE...@uk.ibm.com>/* wrote:
> >
> >
> >
> >
> >
> > Complex Arrays returned from a Java web service on websphere
> > package the
> > RCP encoded response using multiref so the C++ client cannot read the
> > response. I feel that this seriously limits the viability of the
> > Axis C++
> > client.
> >
> > Is anything being done to rectify this problem?
> >
> > Regards,
> >
> > Andrew Perry
> > Clients for Web Service Stack
> > perryan@uk.ibm.com
> > Mail Point 127
> > IBM UK Laboratories. Hursley Park, Winchester, Hants. SO21 2JN
> > Tel. Internal 249828 External + 44 (0)1962 819828
> > Fax. + 44(0)1962 818080
> >
> >
> >
> > axis-c-dev@ws.apa
> > che.org
> > To
> > 13/09/2004 05:43 axis-c-dev@ws.apache.org
> > cc
> >
> > Please respond to Subject
> > "Apache AXIS C [jira] Commented: (AXISCPP-111)
> > Developers List" Axis C++ doesn't support
> > href/multiRef
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > The following comment has been! added to this issue:
> >
> > Author: Samisa Abeysinghe
> > Created: Sun, 12 Sep 2004 9:42 PM
> > Body:
> > 'href' support is challenging in Axis C++ because the parser
> > interface uses
> > a pull model. Not that it is impossible, but it is difficult; The
> > question
> > is: "is it worth the effort?"
> > ---------------------------------------------------------------------
> > View this comment:
> >
> > http://issues.apache.org/jira/browse/AXISCPP-111?page=comments#action_53064
> >
> > ---------------------------------------------------------------------
> > View the issue:
> > http://issues.apache.org/jira/browse/AXISCPP-111
> >
> > Here is an overview of the issue:
> > ---------------------------------------------------------------------
> > Key: AXISCPP-111
> > Summary: Axis C++ doesn't support href/multiRef
> > Type: Bug
> >
> > Status: Unassigned
> > Priority: Major
> >
> > Project: Axis-C++
> > Components:
> > Serialization/Deserialization
> > Versions:
> > 1.2 Final
> >
> > Assignee:
> > Reporter: Alexei Dets
> >
> > Created: Tue, 20 Jul 2004 2:12 PM
> > Updated: Sun, 12 Sep 2004 9:42 PM
> > Environment: RedHat Linux 9
> >
> > Description:
> > Axis C++ doesn't understand SOAP requests (and replies) that use
> > . This automatically makes it incompatible, for example, with
> > Axis Java because it uses multiRef by default.
> >
> > If it is not possible to fix this issue quickly then this issue
> > should be
> > very well documentated and probably it should contain instructions
> > how to
> > switch off multiRefs usage in Axis Java (it _is_ possible). I'm
> > sure that
> > this is a very common source of problems.
> >
> > For example, if I have an Axis C++ server & an Axis Java client
> > than it is
> > necessary to add to the client something like:
> >
> ((org.apache.axis.client.Stub)port)._setProperty(org.apache.axis.AxisEngine.PROP_DOMULTIREFS,
> > Boolean.FALSE);
> >
> >
> >
> > ---------------------------------------------------------------------
> > JIRA INFORMATION:
> > This message is auto! matically generated by JIRA.
> >
> > If you think it was sent incorrectly contact one of the
> > administrators:
> > http://issues.apache.org/jira/secure/Administrators.jspa
> >
> > If you want more information on JIRA, or have a bug to report see:
> > http://www.atlassian.com/software/jira
> >
> >
> >
> > ------------------------------------------------------------------------
> > Do you Yahoo!?
> > vote.yahoo.com <http://vote.yahoo.com> - Register online to vote today!
>
>
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
Re: [jira] Commented: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Samisa Abeysinghe wrote:
> There are no ongoing work to fix this problem.
>
> As I mentioned in an earlier comment in Jira on this issue, the
> challenge is to get this working with the pull model currently being
> used by Axis C++ in deserializing. Supporting href would mean the
> deserializer may have to back-track (or forward leap) in the XML
> stream, which totally contradicts the existing model, and is not
> possible with current code - we would have to rewrite the parser
> algorithm which is parser specific (the next() method ). This means
> that this task would take some considerable time to implement - a
> candidate requirement for 1.4 - may be.
Samisa,
it requires more work but it is possible to implement and quite easy
*with* full streaming model.
in nutshell: you record location of unresolved hrefs (pointers) and when
parsing is finished you go back and patch every unresolved pointer.
similar techniques are used in compilers so this is not like a new
approach ... if you want an example take look on XSOAP 1.2 and mailing
list archives of different SOAP implementatons where this topic was
discussed in pas (Apache SOAP, AXIS SOAP/Java, gSOAP, XSOAP, ...)
thanks,
alek
>
>
> */Andrew Perry2 <PE...@uk.ibm.com>/* wrote:
>
>
>
>
>
> Complex Arrays returned from a Java web service on websphere
> package the
> RCP encoded response using multiref so the C++ client cannot read the
> response. I feel that this seriously limits the viability of the
> Axis C++
> client.
>
> Is anything being done to rectify this problem?
>
> Regards,
>
> Andrew Perry
> Clients for Web Service Stack
> perryan@uk.ibm.com
> Mail Point 127
> IBM UK Laboratories. Hursley Park, Winchester, Hants. SO21 2JN
> Tel. Internal 249828 External + 44 (0)1962 819828
> Fax. + 44(0)1962 818080
>
>
>
> axis-c-dev@ws.apa
> che.org
> To
> 13/09/2004 05:43 axis-c-dev@ws.apache.org
> cc
>
> Please respond to Subject
> "Apache AXIS C [jira] Commented: (AXISCPP-111)
> Developers List" Axis C++ doesn't support
> href/multiRef
>
>
>
>
>
>
>
>
>
>
> The following comment has been! added to this issue:
>
> Author: Samisa Abeysinghe
> Created: Sun, 12 Sep 2004 9:42 PM
> Body:
> 'href' support is challenging in Axis C++ because the parser
> interface uses
> a pull model. Not that it is impossible, but it is difficult; The
> question
> is: "is it worth the effort?"
> ---------------------------------------------------------------------
> View this comment:
>
> http://issues.apache.org/jira/browse/AXISCPP-111?page=comments#action_53064
>
> ---------------------------------------------------------------------
> View the issue:
> http://issues.apache.org/jira/browse/AXISCPP-111
>
> Here is an overview of the issue:
> ---------------------------------------------------------------------
> Key: AXISCPP-111
> Summary: Axis C++ doesn't support href/multiRef
> Type: Bug
>
> Status: Unassigned
> Priority: Major
>
> Project: Axis-C++
> Components:
> Serialization/Deserialization
> Versions:
> 1.2 Final
>
> Assignee:
> Reporter: Alexei Dets
>
> Created: Tue, 20 Jul 2004 2:12 PM
> Updated: Sun, 12 Sep 2004 9:42 PM
> Environment: RedHat Linux 9
>
> Description:
> Axis C++ doesn't understand SOAP requests (and replies) that use
> . This automatically makes it incompatible, for example, with
> Axis Java because it uses multiRef by default.
>
> If it is not possible to fix this issue quickly then this issue
> should be
> very well documentated and probably it should contain instructions
> how to
> switch off multiRefs usage in Axis Java (it _is_ possible). I'm
> sure that
> this is a very common source of problems.
>
> For example, if I have an Axis C++ server & an Axis Java client
> than it is
> necessary to add to the client something like:
> ((org.apache.axis.client.Stub)port)._setProperty(org.apache.axis.AxisEngine.PROP_DOMULTIREFS,
> Boolean.FALSE);
>
>
>
> ---------------------------------------------------------------------
> JIRA INFORMATION:
> This message is auto! matically generated by JIRA.
>
> If you think it was sent incorrectly contact one of the
> administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
>
> If you want more information on JIRA, or have a bug to report see:
> http://www.atlassian.com/software/jira
>
>
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> vote.yahoo.com <http://vote.yahoo.com> - Register online to vote today!
--
The best way to predict the future is to invent it - Alan Kay
Re: Analysis of Axis C++ client transport
Posted by John Hawkins <HA...@uk.ibm.com>.
If someone can tell me how to get a build onto the ftp server I can put
one up there.
fyi: Soon (late next wk?) we will be putting daily builds up.
John Hawkins
Aleksander
Slominski
<aslom@cs.indiana To
.edu> Apache AXIS C Developers List
<ax...@ws.apache.org>
23/09/2004 18:44 cc
Subject
Please respond to Re: Analysis of Axis C++ client
"Apache AXIS C transport
Developers List"
Sanjiva Weerawarana wrote:
>Once we get this tested and working on windoze, I'd be for making
>this the default transport! Great job Samisa ...
>
>Alek, any chance you can re-run your perf benchmark on Linux with
>the new transport code?
>
>
tests should be easy to rerun if you have current AXIS-C++ compiled (i
do not have current version compiled, i do not have a machine to run
tests, and i am a bit scared to spend another few _days_ trying to
follow complicated/outdated/incomplete build/run instructions) then
running tests is very easy.
C++ test service source code is available at:
http://www.extreme.indiana.edu/xgws/soap_bench/axis_cpp/samples_server/soapbench/
services implement set of simple methods described in WSDL
http://www.extreme.indiana.edu/xgws/soap_bench/#bench
those methods are called by test driver is in Java:
http://www.extreme.indiana.edu/xgws/soap_bench/#driver
send me questions if you can not get Java driver to work.
i would be happy to see that my tests helped to improve AXIS C++
perfromance :)
thanks,
alek
>Sanjiva.
>
>----- Original Message -----
>From: "Samisa Abeysinghe" <sa...@yahoo.com>
>To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>Sent: Thursday, September 23, 2004 3:52 PM
>Subject: Re: Analysis of Axis C++ client transport
>
>
>
>
>>Hi,
>> The new transport lib (and LibWWW based transport) is about 150 times
>>
>>
>faster than the original
>
>
>>transport.
>> Thus Axis C++ should be at least as fast as gSOAP or XSOAP4 according
>>
>>
>to the statement "However
>
>
>>it seems that AXIS-C++ HTTP transport is very inefficient as even for
ping
>>
>>
>(echoVoid) method that
>
>
>>has empty body it was 4x slower than gSOAP or XSOAP4" in the benchmark
>>
>>
>report.
>
>
>> I would love to run this benchmark and evaluate Axis 1.3 against
others
>>
>>
>when I get some time.
>
>
>>Samisa...
>>
>>--- Aleksander Slominski <as...@cs.indiana.edu> wrote:
>>
>>
>>
>>>Samisa Abeysinghe wrote:
>>>
>>>
>>>
>>>>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)
>
>
>>>>
>>>>
>>>hi,
>>>
>>>that would explain why AXIS C++ could not get pas some sizes when i was
>>>running those tests:
>>>(...)*Medium size array*s: AXIS-C++ was not able to finish this test and
>>>is not shown.(...)
>>>http://www.extreme.indiana.edu/xgws/soap_bench/linux_xeon_sc/
>>>
>>>hopefullly that can be soon fixed.
>>>
>>>alek
>>>
>>>
>>>
>>>> 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;
>>>>
>>>> }
>>>> catch (AxisException & e)
>>>> {
>>>>printf ("Exception : %s\n", e.what ());
>>>> }
>>>> catch (exception & e)
>>>> {
>>>>printf ("Unknown exception has occured\n");
>>>> }
>>>> catch (...)
>>>> {
>>>>printf ("Unknown exception has occured\n");
>>>> }
>>>>
>>>> // System vs User time stuff
>>>>#ifdef WIN32
>>>>#else // Linux/Unix
>>>> tms timesSpent;
>>>> times(×Spent);
>>>>
>>>> printf( "User time = %ld clock ticks\n",
>>>>
>>>>
>timesSpent.tms_utime );
>
>
>>>> printf( "System time = %ld clock ticks\n",
>>>>
>>>>
>timesSpent.tms_stime);
>
>
>>>> printf( "User time of children = %ld clock ticks\n",
>>>>
>>>>
>timesSpent.tms_cutime);
>
>
>>>> printf( "System time of children = %ld clock ticks\n",
>>>>
>>>>
>timesSpent.tms_cstime);
>
>
>>>> printf( "Processor time used = %ld clock ticks\n", clock());
>>>> printf( "Number of clock ticks per second = %ld clock ticks/s\n",
>>>>
>>>>
>sysconf(_SC_CLK_TCK) );
>
>
>>>>#endif
>>>>
>>>> return 0;
>>>>}
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>_______________________________
>>>>Do you Yahoo!?
>>>>Declare Yourself - Register online to vote today!
>>>>http://vote.yahoo.com
>>>>
>>>>
>>>>
>>>>
>>------------------------------------------------------------------------
>>
>>
>>>>Message Size (characters) Original Axis Transport New Axis
>>>>Transport LibWWW
>>>>
>>>>
>>=== 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
Re: Analysis of Axis C++ client transport
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:
>Once we get this tested and working on windoze, I'd be for making
>this the default transport! Great job Samisa ...
>
>Alek, any chance you can re-run your perf benchmark on Linux with
>the new transport code?
>
>
tests should be easy to rerun if you have current AXIS-C++ compiled (i
do not have current version compiled, i do not have a machine to run
tests, and i am a bit scared to spend another few _days_ trying to
follow complicated/outdated/incomplete build/run instructions) then
running tests is very easy.
C++ test service source code is available at:
http://www.extreme.indiana.edu/xgws/soap_bench/axis_cpp/samples_server/soapbench/
services implement set of simple methods described in WSDL
http://www.extreme.indiana.edu/xgws/soap_bench/#bench
those methods are called by test driver is in Java:
http://www.extreme.indiana.edu/xgws/soap_bench/#driver
send me questions if you can not get Java driver to work.
i would be happy to see that my tests helped to improve AXIS C++
perfromance :)
thanks,
alek
>Sanjiva.
>
>----- Original Message -----
>From: "Samisa Abeysinghe" <sa...@yahoo.com>
>To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
>Sent: Thursday, September 23, 2004 3:52 PM
>Subject: Re: Analysis of Axis C++ client transport
>
>
>
>
>>Hi,
>> The new transport lib (and LibWWW based transport) is about 150 times
>>
>>
>faster than the original
>
>
>>transport.
>> Thus Axis C++ should be at least as fast as gSOAP or XSOAP4 according
>>
>>
>to the statement "However
>
>
>>it seems that AXIS-C++ HTTP transport is very inefficient as even for ping
>>
>>
>(echoVoid) method that
>
>
>>has empty body it was 4x slower than gSOAP or XSOAP4" in the benchmark
>>
>>
>report.
>
>
>> I would love to run this benchmark and evaluate Axis 1.3 against others
>>
>>
>when I get some time.
>
>
>>Samisa...
>>
>>--- Aleksander Slominski <as...@cs.indiana.edu> wrote:
>>
>>
>>
>>>Samisa Abeysinghe wrote:
>>>
>>>
>>>
>>>>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)
>
>
>>>>
>>>>
>>>hi,
>>>
>>>that would explain why AXIS C++ could not get pas some sizes when i was
>>>running those tests:
>>>(...)*Medium size array*s: AXIS-C++ was not able to finish this test and
>>>is not shown.(...)
>>>http://www.extreme.indiana.edu/xgws/soap_bench/linux_xeon_sc/
>>>
>>>hopefullly that can be soon fixed.
>>>
>>>alek
>>>
>>>
>>>
>>>> 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;
>>>>
>>>> }
>>>> catch (AxisException & e)
>>>> {
>>>>printf ("Exception : %s\n", e.what ());
>>>> }
>>>> catch (exception & e)
>>>> {
>>>>printf ("Unknown exception has occured\n");
>>>> }
>>>> catch (...)
>>>> {
>>>>printf ("Unknown exception has occured\n");
>>>> }
>>>>
>>>> // System vs User time stuff
>>>>#ifdef WIN32
>>>>#else // Linux/Unix
>>>> tms timesSpent;
>>>> times(×Spent);
>>>>
>>>> printf( "User time = %ld clock ticks\n",
>>>>
>>>>
>timesSpent.tms_utime );
>
>
>>>> printf( "System time = %ld clock ticks\n",
>>>>
>>>>
>timesSpent.tms_stime);
>
>
>>>> printf( "User time of children = %ld clock ticks\n",
>>>>
>>>>
>timesSpent.tms_cutime);
>
>
>>>> printf( "System time of children = %ld clock ticks\n",
>>>>
>>>>
>timesSpent.tms_cstime);
>
>
>>>> printf( "Processor time used = %ld clock ticks\n", clock());
>>>> printf( "Number of clock ticks per second = %ld clock ticks/s\n",
>>>>
>>>>
>sysconf(_SC_CLK_TCK) );
>
>
>>>>#endif
>>>>
>>>> return 0;
>>>>}
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>_______________________________
>>>>Do you Yahoo!?
>>>>Declare Yourself - Register online to vote today!
>>>>http://vote.yahoo.com
>>>>
>>>>
>>>>
>>>>
>>------------------------------------------------------------------------
>>
>>
>>>>Message Size (characters) Original Axis Transport New Axis
>>>>Transport LibWWW
>>>>
>>>>
>>=== 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
Re: Analysis of Axis C++ client transport
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Once we get this tested and working on windoze, I'd be for making
this the default transport! Great job Samisa ...
Alek, any chance you can re-run your perf benchmark on Linux with
the new transport code?
Sanjiva.
----- Original Message -----
From: "Samisa Abeysinghe" <sa...@yahoo.com>
To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
Sent: Thursday, September 23, 2004 3:52 PM
Subject: Re: Analysis of Axis C++ client transport
> Hi,
> The new transport lib (and LibWWW based transport) is about 150 times
faster than the original
> transport.
> Thus Axis C++ should be at least as fast as gSOAP or XSOAP4 according
to the statement "However
> it seems that AXIS-C++ HTTP transport is very inefficient as even for ping
(echoVoid) method that
> has empty body it was 4x slower than gSOAP or XSOAP4" in the benchmark
report.
>
> I would love to run this benchmark and evaluate Axis 1.3 against others
when I get some time.
> Samisa...
>
> --- Aleksander Slominski <as...@cs.indiana.edu> wrote:
>
> > Samisa Abeysinghe wrote:
> >
> > >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)
> > >
> > >
> > hi,
> >
> > that would explain why AXIS C++ could not get pas some sizes when i was
> > running those tests:
> > (...)*Medium size array*s: AXIS-C++ was not able to finish this test and
> > is not shown.(...)
> > http://www.extreme.indiana.edu/xgws/soap_bench/linux_xeon_sc/
> >
> > hopefullly that can be soon fixed.
> >
> > alek
> >
> > > 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;
> > >
> > > }
> > > catch (AxisException & e)
> > > {
> > > printf ("Exception : %s\n", e.what ());
> > > }
> > > catch (exception & e)
> > > {
> > > printf ("Unknown exception has occured\n");
> > > }
> > > catch (...)
> > > {
> > > printf ("Unknown exception has occured\n");
> > > }
> > >
> > > // System vs User time stuff
> > >#ifdef WIN32
> > >#else // Linux/Unix
> > > tms timesSpent;
> > > times(×Spent);
> > >
> > > printf( "User time = %ld clock ticks\n",
timesSpent.tms_utime );
> > > printf( "System time = %ld clock ticks\n",
timesSpent.tms_stime);
> > > printf( "User time of children = %ld clock ticks\n",
timesSpent.tms_cutime);
> > > printf( "System time of children = %ld clock ticks\n",
timesSpent.tms_cstime);
> > > printf( "Processor time used = %ld clock ticks\n", clock());
> > > printf( "Number of clock ticks per second = %ld clock ticks/s\n",
sysconf(_SC_CLK_TCK) );
> > >#endif
> > >
> > > return 0;
> > >}
> > >
> > >
> > >
> > >
> > >
> > >_______________________________
> > >Do you Yahoo!?
> > >Declare Yourself - Register online to vote today!
> > >http://vote.yahoo.com
> > >
> > >
> >
> ------------------------------------------------------------------------
> > >
> > > Message Size (characters) Original Axis Transport New Axis
> > > Transport LibWWW
> >
> === message truncated ===
>
>
>
>
> _______________________________
> Do you Yahoo!?
> Declare Yourself - Register online to vote today!
> http://vote.yahoo.com
>
Re: Analysis of Axis C++ client transport
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi,
The new transport lib (and LibWWW based transport) is about 150 times faster than the original
transport.
Thus Axis C++ should be at least as fast as gSOAP or XSOAP4 according to the statement "However
it seems that AXIS-C++ HTTP transport is very inefficient as even for ping (echoVoid) method that
has empty body it was 4x slower than gSOAP or XSOAP4" in the benchmark report.
I would love to run this benchmark and evaluate Axis 1.3 against others when I get some time.
Samisa...
--- Aleksander Slominski <as...@cs.indiana.edu> wrote:
> Samisa Abeysinghe wrote:
>
> >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)
> >
> >
> hi,
>
> that would explain why AXIS C++ could not get pas some sizes when i was
> running those tests:
> (...)*Medium size array*s: AXIS-C++ was not able to finish this test and
> is not shown.(...)
> http://www.extreme.indiana.edu/xgws/soap_bench/linux_xeon_sc/
>
> hopefullly that can be soon fixed.
>
> alek
>
> > 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;
> >
> > }
> > catch (AxisException & e)
> > {
> > printf ("Exception : %s\n", e.what ());
> > }
> > catch (exception & e)
> > {
> > printf ("Unknown exception has occured\n");
> > }
> > catch (...)
> > {
> > printf ("Unknown exception has occured\n");
> > }
> >
> > // System vs User time stuff
> >#ifdef WIN32
> >#else // Linux/Unix
> > tms timesSpent;
> > times(×Spent);
> >
> > printf( "User time = %ld clock ticks\n", timesSpent.tms_utime );
> > printf( "System time = %ld clock ticks\n", timesSpent.tms_stime);
> > printf( "User time of children = %ld clock ticks\n", timesSpent.tms_cutime);
> > printf( "System time of children = %ld clock ticks\n", timesSpent.tms_cstime);
> > printf( "Processor time used = %ld clock ticks\n", clock());
> > printf( "Number of clock ticks per second = %ld clock ticks/s\n", sysconf(_SC_CLK_TCK) );
> >#endif
> >
> > return 0;
> >}
> >
> >
> >
> >
> >
> >_______________________________
> >Do you Yahoo!?
> >Declare Yourself - Register online to vote today!
> >http://vote.yahoo.com
> >
> >
> > ------------------------------------------------------------------------
> >
> > Message Size (characters) Original Axis Transport New Axis
> > Transport LibWWW
>
=== message truncated ===
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Re: Analysis of Axis C++ client transport
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Samisa Abeysinghe wrote:
>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)
>
>
hi,
that would explain why AXIS C++ could not get pas some sizes when i was
running those tests:
(...)*Medium size array*s: AXIS-C++ was not able to finish this test and
is not shown.(...)
http://www.extreme.indiana.edu/xgws/soap_bench/linux_xeon_sc/
hopefullly that can be soon fixed.
alek
> 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;
>
> }
> catch (AxisException & e)
> {
> printf ("Exception : %s\n", e.what ());
> }
> catch (exception & e)
> {
> printf ("Unknown exception has occured\n");
> }
> catch (...)
> {
> printf ("Unknown exception has occured\n");
> }
>
> // System vs User time stuff
>#ifdef WIN32
>#else // Linux/Unix
> tms timesSpent;
> times(×Spent);
>
> printf( "User time = %ld clock ticks\n", timesSpent.tms_utime );
> printf( "System time = %ld clock ticks\n", timesSpent.tms_stime);
> printf( "User time of children = %ld clock ticks\n", timesSpent.tms_cutime);
> printf( "System time of children = %ld clock ticks\n", timesSpent.tms_cstime);
> printf( "Processor time used = %ld clock ticks\n", clock());
> printf( "Number of clock ticks per second = %ld clock ticks/s\n", sysconf(_SC_CLK_TCK) );
>#endif
>
> return 0;
>}
>
>
>
>
>
>_______________________________
>Do you Yahoo!?
>Declare Yourself - Register online to vote today!
>http://vote.yahoo.com
>
>
> ------------------------------------------------------------------------
>
> Message Size (characters) Original Axis Transport New Axis
> Transport LibWWW
> 5120 real 0m15.113s real 0m0.084s real 0m0.360s
>
> user 0m0.043s user 0m0.036s user 0m0.113s
>
> sys 0m0.012s sys 0m0.015s sys 0m0.028s
>
>
>
>
> 10240 real 0m15.121s real 0m0.081s real 0m0.224s
>
> user 0m0.047s user 0m0.046s user 0m0.119s
>
> sys 0m0.011s sys 0m0.010s sys 0m0.026s
>
>
>
>
> 20480 real 0m15.128s real 0m0.103s real 0m0.268s
>
> user 0m0.058s user 0m0.056s user 0m0.150s
>
> sys 0m0.013s sys 0m0.013s sys 0m0.029s
>
>
>
>
> 40960 real 0m15.127s real 0m0.156s real 0m0.416s
>
> user 0m0.108s user 0m0.111s user 0m0.264s
>
> sys 0m0.013s sys 0m0.012s sys 0m0.036s
>
>
>
>
> 81920 Segmentation fault
>
>
> real 0m15.335s real 0m0.394s real 0m0.924s
>
> user 0m0.305s user 0m0.305s user 0m0.702s
>
> sys 0m0.011s sys 0m0.016s sys 0m0.035s
>
>
>
>
> 163840 Segmentation fault
>
>
> real 0m16.168s real 0m1.233s real 0m2.844s
>
> user 0m1.078s user 0m1.094s user 0m2.437s
>
> sys 0m0.014s sys 0m0.017s sys 0m0.054s
>
>
>
>
> 327680 Segmentation fault
>
>
> real 0m20.402s real 0m4.697s real 0m10.801s
>
> user 0m4.154s user 0m4.305s user 0m9.350s
>
> sys 0m0.031s sys 0m0.018s sys 0m0.101s
>
>
>
>
> 655360 Segmentation fault
>
>
> real 0m38.541s real 0m17.718s real 0m30.372s
>
> user 0m17.683s user 0m15.765s user 0m27.242s
>
> sys 0m0.057s sys 0m0.052s sys 0m0.188s
>
>
>
>
> 1310720 Segmentation fault
>
>
> real 1m21.945s real 1m3.540s real 1m52.533s
>
> user 1m2.152s user 0m58.013s user 1m39.505s
>
> sys 0m0.110s sys 0m0.102s sys 0m0.244s
>
>
>
>
> 2621440 Segmentation fault
>
>
> real 4m42.126s real 4m26.030s real 5m47.741s
>
> user 4m8.387s user 4m4.459s user 5m32.326s
>
> sys 0m0.413s sys 0m0.376s sys 0m0.879s
>
--
The best way to predict the future is to invent it - Alan Kay
Re: multi-threading or performance and easy to work with code ? [Re: Analysis of Axis C++ client transport
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
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 <as...@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 <HA...@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 <ax...@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
multi-threading or performance and easy to work with code ? [Re:
Analysis of Axis C++ client transport
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
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 <HA...@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 <ax...@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
Re: Analysis of Axis C++ client transport
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
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 <HA...@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 <ax...@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
Re: Analysis of Axis C++ client transport
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Alek,
> isn't it what exactly should be happening in AXIS/C++ that should use on
> server side apache to do chunking and on client side use library to do
> chunking - good transport layer should care of all those details on SOAP
> level you just give it a chunk (or stream) that you want to send?
The only chunking server-side Apache can do is 1-chunk .. just
like Tomcat. The app has to do the chunking to get real chunking.
Again, Axis/Java does not do this work yet either - it looks like
a very small amount of work however .. we'll look into it for
Axis/C++.
> >You're proposing using box-carring
> >
> not at all - i do not want to send one giant SOAP message but use
> KeepAlive/chunking to reuse one TCP connection to send *multiple* SOAP
> messages- this is simple transport optimization similar to in spirit to
Yes that's what I meant too. I meant boxcarring of *SOAP messages*
into one HTTP connection using keep-alive. I guess boxcarring is
not the right word for it.
> Nagle Algorithm that delays sending of TCP packet to try to minimize
> overhead sending of just one character (of just one message).
Yep.
> >Ever heard of BEEP?
> >
> yes - good idea but too complicated protocol that never really gained
> popularity (maybe because it was too hard to implement ...)
Not too hard to implement at all - in fact there are open source
implementations available. Just not PC :).
> it is what TCP/IP initially was before firewalls/NAT/... and
> asymmetrical HTTP request/response: two peers each with unique IP
> addresses that could send to each other whatever and open any number TCP
> connections ...
Yeah I guess you have a point .. if there's a company-wide HTTP proxy
for example it would make sense to keep one connection and channel
a bunch of stuff thru that.
> >Yes that's fine - supporting 1.0 from the new transport should be
> >a start.
> >
> and well tested.
Testing? What's that?
Sanjiva.
Re: Analysis of Axis C++ client transport
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:
>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>
>
>>i though that AXIS/Java is doing chunking as tomcat4/5 will see HTTP/1.1
>>and assume that client can support it?!
>>
>>
>
>Axis/Java only sends one chunk .. and its Tomcat that's doing that,
>not Axis/Java.
>
>
isn't it what exactly should be happening in AXIS/C++ that should use on
server side apache to do chunking and on client side use library to do
chunking - good transport layer should care of all those details on SOAP
level you just give it a chunk (or stream) that you want to send?
>>there is other side to this argument: as messages do not need to be sent
>>right away and are most likely one-way (as this is message-oriented
>>model) you can gather multiple messages with he same host:port
>>destination (possibly targeted to multiple services on the same
>>host:port or even more likely targeted to go through the same
>>firewall/proxy server on intranet border) and then push them all over
>>one keep-alive/chunked connection - that should be very efficient
>>especially if you are sending lot of small messages ...
>>
>>
>
>You're proposing using box-carring
>
not at all - i do not want to send one giant SOAP message but use
KeepAlive/chunking to reuse one TCP connection to send *multiple* SOAP
messages- this is simple transport optimization similar to in spirit to
Nagle Algorithm that delays sending of TCP packet to try to minimize
overhead sending of just one character (of just one message).
>.. yes that can be more efficient
>but you have to consider RM too. In some sense the boxcarring model
>makes sense if you have lots of apps on one server all talking to
>a bunch of services on *one* other server. Then you can share one http
>connection and do stuff.
>
>
RM will work just fine as what i though about is just an optimization on
HTTP transport level and has nothing to do with messaging level
>Ever heard of BEEP?
>
yes - good idea but too complicated protocol that never really gained
popularity (maybe because it was too hard to implement ...)
>That's the right way to do this right :)
>
in principle yes but i would prefer more lightweight solution ...
> .. you
>can establish one connection and do lots of chats inside that one
>thing without being restricted to boxcar a bunch of one-way stuff.
>
>
it is what TCP/IP initially was before firewalls/NAT/... and
asymmetrical HTTP request/response: two peers each with unique IP
addresses that could send to each other whatever and open any number TCP
connection s ...
>
>
>>i think that should be configurable: when using HTTP/1.0 just open
>>connection, write output, close and with HTTP/1.1 use KA and chunking ...
>>
>>
>
>Yes that's fine - supporting 1.0 from the new transport should be
>a start.
>
and well tested.
>Next we can move to 1.1 and add support for chunking
>incrementally and then KA.
>
>
agreed.
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: Analysis of Axis C++ client transport
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
"Aleksander Slominski" <as...@cs.indiana.edu> writes:
> i though that AXIS/Java is doing chunking as tomcat4/5 will see HTTP/1.1
> and assume that client can support it?!
Axis/Java only sends one chunk .. and its Tomcat that's doing that,
not Axis/Java.
> there is other side to this argument: as messages do not need to be sent
> right away and are most likely one-way (as this is message-oriented
> model) you can gather multiple messages with he same host:port
> destination (possibly targeted to multiple services on the same
> host:port or even more likely targeted to go through the same
> firewall/proxy server on intranet border) and then push them all over
> one keep-alive/chunked connection - that should be very efficient
> especially if you are sending lot of small messages ...
You're proposing using box-carring .. yes that can be more efficient
but you have to consider RM too. In some sense the boxcarring model
makes sense if you have lots of apps on one server all talking to
a bunch of services on *one* other server. Then you can share one http
connection and do stuff.
Ever heard of BEEP? That's the right way to do this right :) .. you
can establish one connection and do lots of chats inside that one
thing without being restricted to boxcar a bunch of one-way stuff.
> i think that should be configurable: when using HTTP/1.0 just open
> connection, write output, close and with HTTP/1.1 use KA and chunking ...
Yes that's fine - supporting 1.0 from the new transport should be
a start. Next we can move to 1.1 and add support for chunking
incrementally and then KA.
Sanjiva.
Re: Analysis of Axis C++ client transport
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:
>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!
>
>
i though that AXIS/Java is doing chunking as tomcat4/5 will see HTTP/1.1
and assume that client can support it?!
>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.
>
>
there is other side to this argument: as messages do not need to be sent
right away and are most likely one-way (as this is message-oriented
model) you can gather multiple messages with he same host:port
destination (possibly targeted to multiple services on the same
host:port or even more likely targeted to go through the same
firewall/proxy server on intranet border) and then push them all over
one keep-alive/chunked connection - that should be very efficient
especially if you are sending lot of small messages ...
>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!
>
>
i think that should be configurable: when using HTTP/1.0 just open
connection, write output, close and with HTTP/1.1 use KA and chunking ...
thanks,
alek
>----- Original Message -----
>From: "John Hawkins" <HA...@uk.ibm.com>
>To: "Apache AXIS C Developers List" <ax...@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 <ax...@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 <HA...@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 <ax...@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
Re: Analysis of Axis C++ client transport
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi John,
>Does the new transport have support for chunking
Yes it does, but assuming the whole message would be in one chunk. As Sanjiva has mentioned, this
works perfect with Axis Java - as far as I tested.
Going through the mail thread, sounds like we need to support multiple chunks, which I hope I
could add to the code.
> (and any other things that the old transport had)?
Yes, timeout is supported.
Proxy is not (I need to add some code)
Thanks,
Samisa...
--- Aleksander Slominski <as...@cs.indiana.edu> wrote:
> 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"
> > <ax...@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" <HA...@uk.ibm.com>
> >To: "Apache AXIS C Developers List" <ax...@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"
> >> <ax...@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" <HA...@uk.ibm.com>
> >>To: "Apache AXIS C Developers List" <ax...@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 <ax...@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
> >>
> >>
>
=== message truncated ===
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Re: Analysis of Axis C++ client transport
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
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 ...
This is correct; I observed this with Axis Java, and fixed the new transport to deal with this
situation.
Thanks,
Samisa...
--- Aleksander Slominski <as...@cs.indiana.edu> wrote:
> hi,
>
>
> 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"
> > <ax...@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" <HA...@uk.ibm.com>
> >To: "Apache AXIS C Developers List" <ax...@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"
> >> <ax...@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" <HA...@uk.ibm.com>
> >>To: "Apache AXIS C Developers List" <ax...@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 <ax...@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
> >>
> >>
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
Re: Analysis of Axis C++ client transport
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
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"
> <ax...@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" <HA...@uk.ibm.com>
>To: "Apache AXIS C Developers List" <ax...@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"
>> <ax...@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" <HA...@uk.ibm.com>
>>To: "Apache AXIS C Developers List" <ax...@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 <ax...@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 <HA...@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 <ax...@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
Re: Analysis of Axis C++ client transport
Posted by John Hawkins <HA...@uk.ibm.com>.
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"
<ax...@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" <HA...@uk.ibm.com>
To: "Apache AXIS C Developers List" <ax...@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"
> <ax...@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" <HA...@uk.ibm.com>
> To: "Apache AXIS C Developers List" <ax...@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 <ax...@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 <HA...@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 <ax...@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
> >
> >
> >
>
>
>
>
Re: Analysis of Axis C++ client transport
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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" <HA...@uk.ibm.com>
To: "Apache AXIS C Developers List" <ax...@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"
> <ax...@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" <HA...@uk.ibm.com>
> To: "Apache AXIS C Developers List" <ax...@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 <ax...@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 <HA...@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 <ax...@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
> >
> >
> >
>
>
>
>
Re: Analysis of Axis C++ client transport
Posted by John Hawkins <HA...@uk.ibm.com>.
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"
<ax...@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" <HA...@uk.ibm.com>
To: "Apache AXIS C Developers List" <ax...@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 <ax...@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 <HA...@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 <ax...@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
>
>
>
Re: Analysis of Axis C++ client transport
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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" <HA...@uk.ibm.com>
To: "Apache AXIS C Developers List" <ax...@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 <ax...@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 <HA...@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 <ax...@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
>
>
>
Re: Analysis of Axis C++ client transport
Posted by John Hawkins <HA...@uk.ibm.com>.
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 <ax...@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 <HA...@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 <ax...@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
Re: Analysis of Axis C++ client transport
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
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 <HA...@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 <ax...@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
Re: Analysis of Axis C++ client transport
Posted by John Hawkins <HA...@uk.ibm.com>.
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 <ax...@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;
}
catch (AxisException & e)
{
printf ("Exception : %s\n", e.what ());
}
catch (exception & e)
{
printf ("Unknown exception has occured\n");
}
catch (...)
{
printf ("Unknown exception has occured\n");
}
// System vs User time stuff
#ifdef WIN32
#else // Linux/Unix
tms timesSpent;
times(×Spent);
printf( "User time = %ld clock ticks\n",
timesSpent.tms_utime );
printf( "System time = %ld clock ticks\n",
timesSpent.tms_stime);
printf( "User time of children = %ld clock ticks\n",
timesSpent.tms_cutime);
printf( "System time of children = %ld clock ticks\n",
timesSpent.tms_cstime);
printf( "Processor time used = %ld clock ticks\n", clock());
printf( "Number of clock ticks per second = %ld clock ticks/s\n",
sysconf(_SC_CLK_TCK) );
#endif
return 0;
}
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
|-----------------+-----------------+-----------------+-----------------|
| Message Size | Original Axis | New Axis | LibWWW |
| (characters) | Transport | Transport | |
|-----------------+-----------------+-----------------+-----------------|
| 5120|real 0m15.113s |real 0m0.084s |real 0m0.360s |
|-----------------+-----------------+-----------------+-----------------|
| |user 0m0.043s |user 0m0.036s |user 0m0.113s |
|-----------------+-----------------+-----------------+-----------------|
| |sys 0m0.012s |sys 0m0.015s |sys 0m0.028s |
|-----------------+-----------------+-----------------+-----------------|
| | | | |
|-----------------+-----------------+-----------------+-----------------|
| 10240|real 0m15.121s |real 0m0.081s |real 0m0.224s |
|-----------------+-----------------+-----------------+-----------------|
| |user 0m0.047s |user 0m0.046s |user 0m0.119s |
|-----------------+-----------------+-----------------+-----------------|
| |sys 0m0.011s |sys 0m0.010s |sys 0m0.026s |
|-----------------+-----------------+-----------------+-----------------|
| | | | |
|-----------------+-----------------+-----------------+-----------------|
| 20480|real 0m15.128s |real 0m0.103s |real 0m0.268s |
|-----------------+-----------------+-----------------+-----------------|
| |user 0m0.058s |user 0m0.056s |user 0m0.150s |
|-----------------+-----------------+-----------------+-----------------|
| |sys 0m0.013s |sys 0m0.013s |sys 0m0.029s |
|-----------------+-----------------+-----------------+-----------------|
| | | | |
|-----------------+-----------------+-----------------+-----------------|
| 40960|real 0m15.127s |real 0m0.156s |real 0m0.416s |
|-----------------+-----------------+-----------------+-----------------|
| |user 0m0.108s |user 0m0.111s |user 0m0.264s |
|-----------------+-----------------+-----------------+-----------------|
| |sys 0m0.013s |sys 0m0.012s |sys 0m0.036s |
|-----------------+-----------------+-----------------+-----------------|
| | | | |
|-----------------+-----------------+-----------------+-----------------|
| 81920|Segmentation | | |
| |fault | | |
|-----------------+-----------------+-----------------+-----------------|
| |real 0m15.335s |real 0m0.394s |real 0m0.924s |
|-----------------+-----------------+-----------------+-----------------|
| |user 0m0.305s |user 0m0.305s |user 0m0.702s |
|-----------------+-----------------+-----------------+-----------------|
| |sys 0m0.011s |sys 0m0.016s |sys 0m0.035s |
|-----------------+-----------------+-----------------+-----------------|
| | | | |
|-----------------+-----------------+-----------------+-----------------|
| 163840|Segmentation | | |
| |fault | | |
|-----------------+-----------------+-----------------+-----------------|
| |real 0m16.168s |real 0m1.233s |real 0m2.844s |
|-----------------+-----------------+-----------------+-----------------|
| |user 0m1.078s |user 0m1.094s |user 0m2.437s |
|-----------------+-----------------+-----------------+-----------------|
| |sys 0m0.014s |sys 0m0.017s |sys 0m0.054s |
|-----------------+-----------------+-----------------+-----------------|
| | | | |
|-----------------+-----------------+-----------------+-----------------|
| 327680|Segmentation | | |
| |fault | | |
|-----------------+-----------------+-----------------+-----------------|
| |real 0m20.402s |real 0m4.697s |real 0m10.801s |
|-----------------+-----------------+-----------------+-----------------|
| |user 0m4.154s |user 0m4.305s |user 0m9.350s |
|-----------------+-----------------+-----------------+-----------------|
| |sys 0m0.031s |sys 0m0.018s |sys 0m0.101s |
|-----------------+-----------------+-----------------+-----------------|
| | | | |
|-----------------+-----------------+-----------------+-----------------|
| 655360|Segmentation | | |
| |fault | | |
|-----------------+-----------------+-----------------+-----------------|
| |real 0m38.541s |real 0m17.718s |real 0m30.372s |
|-----------------+-----------------+-----------------+-----------------|
| |user 0m17.683s |user 0m15.765s |user 0m27.242s |
|-----------------+-----------------+-----------------+-----------------|
| |sys 0m0.057s |sys 0m0.052s |sys 0m0.188s |
|-----------------+-----------------+-----------------+-----------------|
| | | | |
|-----------------+-----------------+-----------------+-----------------|
| 1310720|Segmentation | | |
| |fault | | |
|-----------------+-----------------+-----------------+-----------------|
| |real 1m21.945s |real 1m3.540s |real 1m52.533s |
|-----------------+-----------------+-----------------+-----------------|
| |user 1m2.152s |user 0m58.013s |user 1m39.505s |
|-----------------+-----------------+-----------------+-----------------|
| |sys 0m0.110s |sys 0m0.102s |sys 0m0.244s |
|-----------------+-----------------+-----------------+-----------------|
| | | | |
|-----------------+-----------------+-----------------+-----------------|
| 2621440|Segmentation | | |
| |fault | | |
|-----------------+-----------------+-----------------+-----------------|
| |real 4m42.126s |real 4m26.030s |real 5m47.741s |
|-----------------+-----------------+-----------------+-----------------|
| |user 4m8.387s |user 4m4.459s |user 5m32.326s |
|-----------------+-----------------+-----------------+-----------------|
| |sys 0m0.413s |sys 0m0.376s |sys 0m0.879s |
|-----------------+-----------------+-----------------+-----------------|
Analysis of Axis C++ client transport
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
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;
}
catch (AxisException & e)
{
printf ("Exception : %s\n", e.what ());
}
catch (exception & e)
{
printf ("Unknown exception has occured\n");
}
catch (...)
{
printf ("Unknown exception has occured\n");
}
// System vs User time stuff
#ifdef WIN32
#else // Linux/Unix
tms timesSpent;
times(×Spent);
printf( "User time = %ld clock ticks\n", timesSpent.tms_utime );
printf( "System time = %ld clock ticks\n", timesSpent.tms_stime);
printf( "User time of children = %ld clock ticks\n", timesSpent.tms_cutime);
printf( "System time of children = %ld clock ticks\n", timesSpent.tms_cstime);
printf( "Processor time used = %ld clock ticks\n", clock());
printf( "Number of clock ticks per second = %ld clock ticks/s\n", sysconf(_SC_CLK_TCK) );
#endif
return 0;
}
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Re: [jira] Commented: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Posted by John Hawkins <HA...@uk.ibm.com>.
Thanks Samisa,
We're trying to confim but we think this only happens on rpc encoded (with
the server that we are testing with) in which case this is not an issue for
us yet !
John Hawkins
Samisa Abeysinghe
<samisa_abeysingh
e@yahoo.com> To
Apache AXIS C Developers List
17/09/2004 03:43 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C Re: [jira] Commented: (AXISCPP-111)
Developers List" Axis C++ doesn't support
href/multiRef
There are no ongoing work to fix this problem.
As I mentioned in an earlier comment in Jira on this issue, the challenge
is to get this working with the pull model currently being used by Axis C++
in deserializing. Supporting href would mean the deserializer may have to
back-track (or forward leap) in the XML stream, which totally contradicts
the existing model, and is not possible with current code - we would have
to rewrite the parser algorithm which is parser specific (the next() method
). This means that this task would take some considerable time to implement
- a candidate requirement for 1.4 - may be.
Samisa...
Andrew Perry2 <PE...@uk.ibm.com> wrote:
Complex Arrays returned from a Java web service on websphere package the
RCP encoded response using multiref so the C++ client cannot read the
response. I feel that this seriously limits the viability of the Axis C++
client.
Is anything being done to rectify this problem?
Regards,
Andrew Perry
Clients for Web Service Stack
perryan@uk.ibm.com
Mail Point 127
IBM UK Laboratories. Hursley Park, Winchester, Hants. SO21 2JN
Tel. Internal 249828 External + 44 (0)1962 819828
Fax. + 44(0)1962 818080
axis-c-dev@ws.apa
che.org
To
13/09/2004 05:43 axis-c-dev@ws.apache.org
cc
Please respond to Subject
"Apache AXIS C [jira] Commented: (AXISCPP-111)
Developers List" Axis C++ doesn't support
href/multiRef
The following comment has been! added to this issue:
Author: Samisa Abeysinghe
Created: Sun, 12 Sep 2004 9:42 PM
Body:
'href' support is challenging in Axis C++ because the parser interface
uses
a pull model. Not that it is impossible, but it is difficult; The question
is: "is it worth the effort?"
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXISCPP-111?page=comments#action_53064
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-111
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-111
Summary: Axis C++ doesn't support href/multiRef
Type: Bug
Status: Unassigned
Priority: Major
Project: Axis-C++
Components:
Serialization/Deserialization
Versions:
1.2 Final
Assignee:
Reporter: Alexei Dets
Created: Tue, 20 Jul 2004 2:12 PM
Updated: Sun, 12 Sep 2004 9:42 PM
Environment: RedHat Linux 9
Description:
Axis C++ doesn't understand SOAP requests (and replies) that use
. This automatically makes it incompatible, for example, with
Axis Java because it uses multiRef by default.
If it is not possible to fix this issue quickly then this issue should be
very well documentated and probably it should contain instructions how to
switch off multiRefs usage in Axis Java (it _is_ possible). I'm sure that
this is a very common source of problems.
For example, if I have an Axis C++ server & an Axis Java client than it is
necessary to add to the client something like:
((org.apache.axis.client.Stub)port)._setProperty(org.apache.axis.AxisEngine.PROP_DOMULTIREFS,
Boolean.FALSE);
---------------------------------------------------------------------
JIRA INFORMATION:
This message is auto! matically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Do you Yahoo!?
vote.yahoo.com - Register online to vote today!
Re: [jira] Commented: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
There are no ongoing work to fix this problem.
As I mentioned in an earlier comment in Jira on this issue, the challenge is to get this working with the pull model currently being used by Axis C++ in deserializing. Supporting href would mean the deserializer may have to back-track (or forward leap) in the XML stream, which totally contradicts the existing model, and is not possible with current code - we would have to rewrite the parser algorithm which is parser specific (the next() method ). This means that this task would take some considerable time to implement - a candidate requirement for 1.4 - may be.
Samisa...
Andrew Perry2 <PE...@uk.ibm.com> wrote:
Complex Arrays returned from a Java web service on websphere package the
RCP encoded response using multiref so the C++ client cannot read the
response. I feel that this seriously limits the viability of the Axis C++
client.
Is anything being done to rectify this problem?
Regards,
Andrew Perry
Clients for Web Service Stack
perryan@uk.ibm.com
Mail Point 127
IBM UK Laboratories. Hursley Park, Winchester, Hants. SO21 2JN
Tel. Internal 249828 External + 44 (0)1962 819828
Fax. + 44(0)1962 818080
axis-c-dev@ws.apa
che.org
To
13/09/2004 05:43 axis-c-dev@ws.apache.org
cc
Please respond to Subject
"Apache AXIS C [jira] Commented: (AXISCPP-111)
Developers List" Axis C++ doesn't support
href/multiRef
The following comment has been added to this issue:
Author: Samisa Abeysinghe
Created: Sun, 12 Sep 2004 9:42 PM
Body:
'href' support is challenging in Axis C++ because the parser interface uses
a pull model. Not that it is impossible, but it is difficult; The question
is: "is it worth the effort?"
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXISCPP-111?page=comments#action_53064
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-111
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-111
Summary: Axis C++ doesn't support href/multiRef
Type: Bug
Status: Unassigned
Priority: Major
Project: Axis-C++
Components:
Serialization/Deserialization
Versions:
1.2 Final
Assignee:
Reporter: Alexei Dets
Created: Tue, 20 Jul 2004 2:12 PM
Updated: Sun, 12 Sep 2004 9:42 PM
Environment: RedHat Linux 9
Description:
Axis C++ doesn't understand SOAP requests (and replies) that use
. This automatically makes it incompatible, for example, with
Axis Java because it uses multiRef by default.
If it is not possible to fix this issue quickly then this issue should be
very well documentated and probably it should contain instructions how to
switch off multiRefs usage in Axis Java (it _is_ possible). I'm sure that
this is a very common source of problems.
For example, if I have an Axis C++ server & an Axis Java client than it is
necessary to add to the client something like:
((org.apache.axis.client.Stub)port)._setProperty(org.apache.axis.AxisEngine.PROP_DOMULTIREFS,
Boolean.FALSE);
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------
Do you Yahoo!?
vote.yahoo.com - Register online to vote today!
Re: [jira] Commented: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Posted by Andrew Perry2 <PE...@uk.ibm.com>.
Complex Arrays returned from a Java web service on websphere package the
RCP encoded response using multiref so the C++ client cannot read the
response. I feel that this seriously limits the viability of the Axis C++
client.
Is anything being done to rectify this problem?
Regards,
Andrew Perry
Clients for Web Service Stack
perryan@uk.ibm.com
Mail Point 127
IBM UK Laboratories. Hursley Park, Winchester, Hants. SO21 2JN
Tel. Internal 249828 External + 44 (0)1962 819828
Fax. + 44(0)1962 818080
axis-c-dev@ws.apa
che.org
To
13/09/2004 05:43 axis-c-dev@ws.apache.org
cc
Please respond to Subject
"Apache AXIS C [jira] Commented: (AXISCPP-111)
Developers List" Axis C++ doesn't support
href/multiRef
The following comment has been added to this issue:
Author: Samisa Abeysinghe
Created: Sun, 12 Sep 2004 9:42 PM
Body:
'href' support is challenging in Axis C++ because the parser interface uses
a pull model. Not that it is impossible, but it is difficult; The question
is: "is it worth the effort?"
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXISCPP-111?page=comments#action_53064
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-111
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-111
Summary: Axis C++ doesn't support href/multiRef
Type: Bug
Status: Unassigned
Priority: Major
Project: Axis-C++
Components:
Serialization/Deserialization
Versions:
1.2 Final
Assignee:
Reporter: Alexei Dets
Created: Tue, 20 Jul 2004 2:12 PM
Updated: Sun, 12 Sep 2004 9:42 PM
Environment: RedHat Linux 9
Description:
Axis C++ doesn't understand SOAP requests (and replies) that use
<multiRef>. This automatically makes it incompatible, for example, with
Axis Java because it uses multiRef by default.
If it is not possible to fix this issue quickly then this issue should be
very well documentated and probably it should contain instructions how to
switch off multiRefs usage in Axis Java (it _is_ possible). I'm sure that
this is a very common source of problems.
For example, if I have an Axis C++ server & an Axis Java client than it is
necessary to add to the client something like:
((org.apache.axis.client.Stub)port)._setProperty(org.apache.axis.AxisEngine.PROP_DOMULTIREFS,
Boolean.FALSE);
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Posted by ax...@ws.apache.org.
The following comment has been added to this issue:
Author: Samisa Abeysinghe
Created: Sun, 12 Sep 2004 9:42 PM
Body:
'href' support is challenging in Axis C++ because the parser interface uses a pull model. Not that it is impossible, but it is difficult; The question is: "is it worth the effort?"
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXISCPP-111?page=comments#action_53064
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-111
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-111
Summary: Axis C++ doesn't support href/multiRef
Type: Bug
Status: Unassigned
Priority: Major
Project: Axis-C++
Components:
Serialization/Deserialization
Versions:
1.2 Final
Assignee:
Reporter: Alexei Dets
Created: Tue, 20 Jul 2004 2:12 PM
Updated: Sun, 12 Sep 2004 9:42 PM
Environment: RedHat Linux 9
Description:
Axis C++ doesn't understand SOAP requests (and replies) that use <multiRef>. This automatically makes it incompatible, for example, with Axis Java because it uses multiRef by default.
If it is not possible to fix this issue quickly then this issue should be very well documentated and probably it should contain instructions how to switch off multiRefs usage in Axis Java (it _is_ possible). I'm sure that this is a very common source of problems.
For example, if I have an Axis C++ server & an Axis Java client than it is necessary to add to the client something like:
((org.apache.axis.client.Stub)port)._setProperty(org.apache.axis.AxisEngine.PROP_DOMULTIREFS, Boolean.FALSE);
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXISCPP-111) Axis C++ doesn't support
href/multiRef
Posted by "Fred Preston (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-111?page=all ]
Fred Preston updated AXISCPP-111:
---------------------------------
type: New Feature (was: Improvement)
Because of the amount of code that would need to change, it is not an enhancement, more new feature because Axis would need to parse the SOAP message using the DOM rather than the SAX model and thus would need a significant re-write (see JIRA AXISCPP-117).
> Axis C++ doesn't support href/multiRef
> --------------------------------------
>
> Key: AXISCPP-111
> URL: http://issues.apache.org/jira/browse/AXISCPP-111
> Project: Axis-C++
> Type: New Feature
> Components: Serialization
> Versions: 1.2 Final
> Environment: RedHat Linux 9
> Reporter: Alexei Dets
>
> Axis C++ doesn't understand SOAP requests (and replies) that use <multiRef>. This automatically makes it incompatible, for example, with Axis Java because it uses multiRef by default.
> If it is not possible to fix this issue quickly then this issue should be very well documentated and probably it should contain instructions how to switch off multiRefs usage in Axis Java (it _is_ possible). I'm sure that this is a very common source of problems.
> For example, if I have an Axis C++ server & an Axis Java client than it is necessary to add to the client something like:
> ((org.apache.axis.client.Stub)port)._setProperty(org.apache.axis.AxisEngine.PROP_DOMULTIREFS, Boolean.FALSE);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Posted by ax...@ws.apache.org.
The following comment has been added to this issue:
Author: John Wagg
Created: Fri, 3 Sep 2004 9:12 AM
Body:
Thanks Alexei. I'd worked out that I could turn it off using the server config. It just seems sad that I should have to turn it off because an Axis C++ client can't handle it.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXISCPP-111?page=comments#action_52808
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-111
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-111
Summary: Axis C++ doesn't support href/multiRef
Type: Bug
Status: Unassigned
Priority: Major
Project: Axis-C++
Components:
Serialization/Deserialization
Versions:
1.2 Final
Assignee:
Reporter: Alexei Dets
Created: Tue, 20 Jul 2004 2:12 PM
Updated: Fri, 3 Sep 2004 9:12 AM
Environment: RedHat Linux 9
Description:
Axis C++ doesn't understand SOAP requests (and replies) that use <multiRef>. This automatically makes it incompatible, for example, with Axis Java because it uses multiRef by default.
If it is not possible to fix this issue quickly then this issue should be very well documentated and probably it should contain instructions how to switch off multiRefs usage in Axis Java (it _is_ possible). I'm sure that this is a very common source of problems.
For example, if I have an Axis C++ server & an Axis Java client than it is necessary to add to the client something like:
((org.apache.axis.client.Stub)port)._setProperty(org.apache.axis.AxisEngine.PROP_DOMULTIREFS, Boolean.FALSE);
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Posted by ax...@ws.apache.org.
The following issue has been updated:
Updater: John Hawkins (mailto:hawkinsj@uk.ibm.com)
Date: Fri, 15 Oct 2004 3:28 AM
Changes:
type changed from Bug to Improvement
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/AXISCPP-111?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-111
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-111
Summary: Axis C++ doesn't support href/multiRef
Type: Improvement
Status: Unassigned
Priority: Major
Project: Axis-C++
Components:
Serialization/Deserialization
Versions:
1.2 Final
Assignee:
Reporter: Alexei Dets
Created: Tue, 20 Jul 2004 2:12 PM
Updated: Fri, 15 Oct 2004 3:28 AM
Environment: RedHat Linux 9
Description:
Axis C++ doesn't understand SOAP requests (and replies) that use <multiRef>. This automatically makes it incompatible, for example, with Axis Java because it uses multiRef by default.
If it is not possible to fix this issue quickly then this issue should be very well documentated and probably it should contain instructions how to switch off multiRefs usage in Axis Java (it _is_ possible). I'm sure that this is a very common source of problems.
For example, if I have an Axis C++ server & an Axis Java client than it is necessary to add to the client something like:
((org.apache.axis.client.Stub)port)._setProperty(org.apache.axis.AxisEngine.PROP_DOMULTIREFS, Boolean.FALSE);
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Posted by "John Hawkins (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-111?page=comments#action_58360 ]
John Hawkins commented on AXISCPP-111:
--------------------------------------
This error is not visible in doc/lit (it does not support multi-ref. WS-I are moving away from rpc encoded and towards doc/lit. However, I do understand that people may wish to support "old" standards ;-)
> Axis C++ doesn't support href/multiRef
> --------------------------------------
>
> Key: AXISCPP-111
> URL: http://issues.apache.org/jira/browse/AXISCPP-111
> Project: Axis-C++
> Type: Improvement
> Components: Serialization/Deserialization
> Versions: 1.2 Final
> Environment: RedHat Linux 9
> Reporter: Alexei Dets
>
> Axis C++ doesn't understand SOAP requests (and replies) that use <multiRef>. This automatically makes it incompatible, for example, with Axis Java because it uses multiRef by default.
> If it is not possible to fix this issue quickly then this issue should be very well documentated and probably it should contain instructions how to switch off multiRefs usage in Axis Java (it _is_ possible). I'm sure that this is a very common source of problems.
> For example, if I have an Axis C++ server & an Axis Java client than it is necessary to add to the client something like:
> ((org.apache.axis.client.Stub)port)._setProperty(org.apache.axis.AxisEngine.PROP_DOMULTIREFS, Boolean.FALSE);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Posted by ax...@ws.apache.org.
The following comment has been added to this issue:
Author: Alexei Dets
Created: Fri, 3 Sep 2004 8:38 AM
Body:
multiRefs are sent by the Java side (be it server or client), not C++. You can turn off multiRefs on the Axis Java server side in the Axis configuration file server-config.wsdd, it is described in the Axis Java Reference Guide: http://ws.apache.org/axis/java/reference.html
I don't think that you can change server behaviour from the client side...
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXISCPP-111?page=comments#action_52802
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-111
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-111
Summary: Axis C++ doesn't support href/multiRef
Type: Bug
Status: Unassigned
Priority: Major
Project: Axis-C++
Components:
Serialization/Deserialization
Versions:
1.2 Final
Assignee:
Reporter: Alexei Dets
Created: Tue, 20 Jul 2004 2:12 PM
Updated: Fri, 3 Sep 2004 8:38 AM
Environment: RedHat Linux 9
Description:
Axis C++ doesn't understand SOAP requests (and replies) that use <multiRef>. This automatically makes it incompatible, for example, with Axis Java because it uses multiRef by default.
If it is not possible to fix this issue quickly then this issue should be very well documentated and probably it should contain instructions how to switch off multiRefs usage in Axis Java (it _is_ possible). I'm sure that this is a very common source of problems.
For example, if I have an Axis C++ server & an Axis Java client than it is necessary to add to the client something like:
((org.apache.axis.client.Stub)port)._setProperty(org.apache.axis.AxisEngine.PROP_DOMULTIREFS, Boolean.FALSE);
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Posted by ax...@ws.apache.org.
The following comment has been added to this issue:
Author: John Wagg
Created: Fri, 3 Sep 2004 6:49 AM
Body:
I have the opposite situation. An Axis java server and an Axis C++ client and an attempt to transfer multiref data. Is there a workaround for this? Can I turn off the multiref from the client end with Axis C++?
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXISCPP-111?page=comments#action_52791
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-111
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-111
Summary: Axis C++ doesn't support href/multiRef
Type: Bug
Status: Unassigned
Priority: Major
Project: Axis-C++
Components:
Serialization/Deserialization
Versions:
1.2 Final
Assignee:
Reporter: Alexei Dets
Created: Tue, 20 Jul 2004 2:12 PM
Updated: Fri, 3 Sep 2004 6:49 AM
Environment: RedHat Linux 9
Description:
Axis C++ doesn't understand SOAP requests (and replies) that use <multiRef>. This automatically makes it incompatible, for example, with Axis Java because it uses multiRef by default.
If it is not possible to fix this issue quickly then this issue should be very well documentated and probably it should contain instructions how to switch off multiRefs usage in Axis Java (it _is_ possible). I'm sure that this is a very common source of problems.
For example, if I have an Axis C++ server & an Axis Java client than it is necessary to add to the client something like:
((org.apache.axis.client.Stub)port)._setProperty(org.apache.axis.AxisEngine.PROP_DOMULTIREFS, Boolean.FALSE);
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-111) Axis C++ doesn't support href/multiRef
Posted by ax...@ws.apache.org.
The following comment has been added to this issue:
Author: Alexei Dets
Created: Mon, 13 Sep 2004 8:13 AM
Body:
It is rather common to connect to some webservice that is out of your control (belonging to other company etc.). If it is using "href"/"multiRef" (this is default at least in Axis Java) then you can't use Axis C++ client to connect to such service :-(
AFAIK, usage of href/multiRef in SOAP is recommended, has some advantages and so support for this feature is critical for compatibility with other SOAP implementations.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/AXISCPP-111?page=comments#action_53073
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXISCPP-111
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXISCPP-111
Summary: Axis C++ doesn't support href/multiRef
Type: Bug
Status: Unassigned
Priority: Major
Project: Axis-C++
Components:
Serialization/Deserialization
Versions:
1.2 Final
Assignee:
Reporter: Alexei Dets
Created: Tue, 20 Jul 2004 2:12 PM
Updated: Mon, 13 Sep 2004 8:13 AM
Environment: RedHat Linux 9
Description:
Axis C++ doesn't understand SOAP requests (and replies) that use <multiRef>. This automatically makes it incompatible, for example, with Axis Java because it uses multiRef by default.
If it is not possible to fix this issue quickly then this issue should be very well documentated and probably it should contain instructions how to switch off multiRefs usage in Axis Java (it _is_ possible). I'm sure that this is a very common source of problems.
For example, if I have an Axis C++ server & an Axis Java client than it is necessary to add to the client something like:
((org.apache.axis.client.Stub)port)._setProperty(org.apache.axis.AxisEngine.PROP_DOMULTIREFS, Boolean.FALSE);
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira