axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <samisa_abeysin...@yahoo.com>
Subject Re: AXISCPP-89 and Transport2
Date Thu, 14 Oct 2004 05:54:11 GMT
> Hence I tested against Axis Java service. For 2621440 chars client succeeds. But for 5242880
> chars
> the client fails. Hence the bug must be related to the way chunks are handled. (Note:
Axis C++
> server does not send chunks)

Further llook into the problem reveals that the client crashes with 5242880 chars message
because
the Axis Java server returns an error. (I tied to use tcpmon to see what the error was but
it gets
stuck :-( )

Could you use tcpmon to veryfy that the server is sending the respose back correctly?

Samisa...



--- Samisa Abeysinghe <samisa_abeysinghe@yahoo.com> wrote:

> I used 5242880 (5MB) chars with echoString of base sample and it works.
> Environment:
>     Linux
>     Xerces parser
>     axis2 transport
>     Axis C++ server
> 
> > In your tests do you check the return message to make sure that it is the
> > correct size or even better compare the actual message?
> 
> I used strcmp to compare the message received with the message sent.
> 
> I think the secret of sucess is that I was using Axis C++ server.
> You must have tested againt a Java based service and if so, I doubt the bug is due to
cunking.
> Hence I tested against Axis Java service. For 2621440 chars client succeeds. But for
5242880
> chars
> the client fails. Hence the bug must be related to the way chunks are handled. (Note:
Axis C++
> server does not send chunks)
> 
> I will try to fid a fix for this.
> 
> > I haven't had a chance yet to look at the Axis2 transport code for any
> > clues.
> 
> It would be very helpful if you could review the code, specially chunking logic.
> 
> Thanks,
> Samisa...
> 
> --- Andrew Perry2 <PERRYAN@uk.ibm.com> wrote:
> 
> > 
> > 
> > 
> > 
> > I've got a little service that has sendLargeString and getLargeString
> > opetarions. The client creates a string and sends it to the send service,
> > then the get service is called and the length of the returned string is
> > compared to the length of the sent string. These should obviously be equal,
> > but I started to notice that this was not always the case. I modified the
> > client to have a loop to send (4MB - i*1K) sized message looping from 7 to
> > 0 and output the size of the sent message, the size of the received message
> > and the difference. As you can see from the output it doesn't consistently
> > lose the same number of bytes.
> > 
> > ------------------------------------
> > first run
> > ------------------------------------
> > sending 4187136 - 1 seconds
> > getting - 2 seconds
> > getLargeMsg after sendLargeMsg 4187136 <4178996> 8140 - FAILED
> > sending 4188160 - 1 seconds
> > getting - 2 seconds
> > getLargeMsg after sendLargeMsg 4188160 <4180020> 8140 - FAILED
> > sending 4189184 - 1 seconds
> > getting - 2 seconds
> > getLargeMsg after sendLargeMsg 4189184 <4181044> 8140 - FAILED
> > sending 4190208 - 1 seconds
> > getting - 1 seconds
> > getLargeMsg after sendLargeMsg 4190208 <4190208> 0 - PASSED
> > sending 4191232 - 1 seconds
> > getting - 1 seconds
> > getLargeMsg after sendLargeMsg 4191232 <4183093> 8139 - FAILED
> > sending 4192256 - 1 seconds
> > getting - 1 seconds
> > getLargeMsg after sendLargeMsg 4192256 <4184117> 8139 - FAILED
> > sending 4193280 - 1 seconds
> > getting - 2 seconds
> > getLargeMsg after sendLargeMsg 4193280 <4185141> 8139 - FAILED
> > sending 4194304 - 1 seconds
> > getting - 2 seconds
> > getLargeMsg after sendLargeMsg 4194304 <4186170> 8134 - FAILED
> > ------------------------------------
> > second run
> > ------------------------------------
> > sending 4187136 - 1 seconds
> > getting - 2 seconds
> > getLargeMsg after sendLargeMsg 4187136 <4178996> 8140 - FAILED
> > sending 4188160 - 1 seconds
> > getting - 2 seconds
> > getLargeMsg after sendLargeMsg 4188160 <4180020> 8140 - FAILED
> > sending 4189184 - 1 seconds
> > getting - 2 seconds
> > getLargeMsg after sendLargeMsg 4189184 <4181392> 7792 - FAILED
> > sending 4190208 - 1 seconds
> > getting - 2 seconds
> > getLargeMsg after sendLargeMsg 4190208 <4182069> 8139 - FAILED
> > sending 4191232 - 1 seconds
> > getting - 1 seconds
> > getLargeMsg after sendLargeMsg 4191232 <4183093> 8139 - FAILED
> > sending 4192256 - 1 seconds
> > getting - 1 seconds
> > getLargeMsg after sendLargeMsg 4192256 <4184117> 8139 - FAILED
> > sending 4193280 - 2 seconds
> > getting - 1 seconds
> > getLargeMsg after sendLargeMsg 4193280 <4185141> 8139 - FAILED
> > sending 4194304 - 1 seconds
> > getting - 2 seconds
> > getLargeMsg after sendLargeMsg 4194304 <4186170> 8134 - FAILED
> > 
> > 
> > In your tests do you check the return message to make sure that it is the
> > correct size or even better compare the actual message?
> > 
> > I haven't had a chance yet to look at the Axis2 transport code for any
> > clues.
> > 
> > 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
> > 
> > 
> >                                                                            
> >              damitha kumarage                                              
> >              <damitha@opensour                                             
> >              ce.lk>                                                     To 
> >                                        Apache AXIS C Developers List       
> >              13/10/2004 10:17          <axis-c-dev@ws.apache.org>        
 
> >                                                                         cc 
> >                                                                            
> >              Please respond to                                     Subject 
> >               "Apache AXIS C           Re: AXISCPP-89 and Transport2       
> >              Developers List"                                              
> >                                                                            
> >                                                                            
> >                                                                            
> >                                                                            
> >                                                                            
> > 
> > 
> > 
> > 
> > Hi Samisa,sanjaya
> > 
> > I tested with some large string arrays in linux and the results are
> > attached.
> > It seems by testing with sending 2.5MB arrays 100 times, using xerces is
> > about 30% fast than using the expat parser(see attached results). This
> > is very strange since I remember long time back this was quite the
> > opposite. May be after improvement by sanjaya sometime back resulted in
> > this change.
> > 
> > I also send a 225MB array(parser is xerces. expat fails on more than
> > 4mb). I set for 10 runs but server fails after 2 runs. It takes about
> > 244 seconds to complete a run(see attached)
> > 
> > Sanjaya, is it possible to run these tests in windows using large-arrays
> > test?. I used axis2 transport for all tests.
> > 
> > thanks
> > damitha
> > 
> > 
> > 
> > 
> > On Fri, 2004-10-08 at 18:43, Samisa Abeysinghe wrote:
> > > Cool. Thanks for the info. So my guess work on a fix is also false :-)
> > >
> > > BTW: If you have time, please do a test to see the max limit.
> > > You could use test program in tests/client/performance/time/
> > >
> > > Thanks,
> > > Samisa...
> > >
> > > --- sanjaya singharage <sanjayas@opensource.lk> wrote:
> > >
> > > > Actually its a false alarm. I had sent the string without being null
> > > > terminated after being memset. I managed to send upto 5000 bytes with
> > the
> > > > new transport.
> > > >
> > > > sorry about this.
> > > >
> > > > sanjaya.
> > > >
> > > > ----- Original Message -----
> > > > From: "Samisa Abeysinghe" <samisa_abeysinghe@yahoo.com>
> > > > To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
> > > > Sent: Friday, October 08, 2004 2:09 PM
> > > > Subject: Re: AXISCPP-89 and Transport2
> > > >
> > > >
> > > > > > It is a bug with deserialization process.
> > > > > Correction: serialization process.
> > > > >
> > > > > Also, it is worth to look at if Windows handle the uion used in Param
> > > > class properly.
> > > > >
> > > > > Samisa...
> > > > >
> > > > > --- Samisa Abeysinghe <samisa_abeysinghe@yahoo.com> wrote:
> > > > >
> > > > > > This is not really a bug with transport.
> > > > > >
> 
=== message truncated ===



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

Mime
View raw message