Return-Path: Delivered-To: apmail-ws-axis-c-dev-archive@www.apache.org Received: (qmail 84436 invoked from network); 14 Oct 2004 03:58:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 14 Oct 2004 03:58:47 -0000 Received: (qmail 24800 invoked by uid 500); 14 Oct 2004 03:58:46 -0000 Delivered-To: apmail-ws-axis-c-dev-archive@ws.apache.org Received: (qmail 24772 invoked by uid 500); 14 Oct 2004 03:58:45 -0000 Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: List-Id: "Apache AXIS C Developers List" Reply-To: "Apache AXIS C Developers List" Delivered-To: mailing list axis-c-dev@ws.apache.org Received: (qmail 24759 invoked by uid 99); 14 Oct 2004 03:58:45 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from [66.218.78.144] (HELO web40607.mail.yahoo.com) (66.218.78.144) by apache.org (qpsmtpd/0.28) with SMTP; Wed, 13 Oct 2004 20:58:44 -0700 Message-ID: <20041014035843.22261.qmail@web40607.mail.yahoo.com> Received: from [202.162.29.14] by web40607.mail.yahoo.com via HTTP; Wed, 13 Oct 2004 20:58:43 PDT Date: Wed, 13 Oct 2004 20:58:43 -0700 (PDT) From: Samisa Abeysinghe Subject: Re: AXISCPP-89 and Transport2 To: Apache AXIS C Developers List In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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 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 > ce.lk> To > Apache AXIS C Developers List > 13/10/2004 10:17 > 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 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" > > > To: "Apache AXIS C Developers List" > > > 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 wrote: > > > > > > > > > This is not really a bug with transport. > > > > > > > > > > It is a bug with deserialization process. > > > > > > > > > > The problem happens in BasicTypeSerializer::serializeAsElement() > > > > > To be precise, when it does: > > > > > m_AuxStr = pStr; > > > > > where pStr is constructed using: > > > > > pStr = *((char**)(pValue)); > > > > > > > > > > I got the gut feel that somewhere in this section of the code, we > need a > > > cast to std string. > > > > > And I guess if we use > > > > > m_AuxStr = std::basic_string (pStr); > > > > > > > > > > If possible, please test this logic on windows. > > > > > > > > > > Samisa... > > > > > > > > > > --- sanjaya singharage wrote: > > > > > > > > > > > bug 89 still seems to exist on windows with the new transport. > > > > > > > > > > > > I simply used a string 2047 bytes long and a 2048 one in the > > > echoString from > > > > > > interop base sample. For 2047 it succeeds. For 2048 it fails. > > > > > > > > > > > > When 2048 bytes are sent..... > > > > > > > > > > > > > > > > === message truncated === > ATTACHMENT part 2 application/octet-stream name=result-expat > ATTACHMENT part 3 application/octet-stream name=result-xercesc > ATTACHMENT part 4 application/octet-stream name=result-xercesc-225 _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com