Mailing-List: contact axis-c-user-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C User List" <axis-c-user@ws.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <47D5076D.8050602@wso2.com>
Date: Mon, 10 Mar 2008 15:33:25 +0530
From: Samisa Abeysinghe <samisa@wso2.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Apache AXIS C User List <axis-c-user@ws.apache.org>
Subject: Re: Core dumps in Axis libraries
References: <H00000a00022aa7f.1205140213.dakghar.aylus.com@MHS>
In-Reply-To: <H00000a00022aa7f.1205140213.dakghar.aylus.com@MHS>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Raghavendra SM wrote:
> As expected, when I put a delay of about 50 milliseconds between the 
> requests there is no dump.
>
> But we would still like to know the following,
> + Isn't Axis capable of handling such huge bombardment of requests (of 
> the order of 1000's) one after another without any delay between the 
> requests? Has anyone tried such client before?
>   

Yes it is supposed to. We have done performance testing that proved that 
Axis2/C can serve more than 300 rps.

> + Can we make out anything out of the valgrind report or the axis logs 
> that were attached?
>   

Unfortunately not. When valgrind runs, it makes the system slow, that 
prevents the system crashing in situations like that you are 
experiencing. To solve this kind of a problem, it is a must that you 
provide us with some sample code that can be used to reproduce the 
problem. Without having a way to re-produce the situation, there is no 
way to fix this problem - it could well be a problem in Axis2/C as well 
as it could also be in the code that you use.

Samisa...


> Regards,
> ~raghav
>  
>
> -----Original Message-----
> From: Senaka Fernando [mailto:senaka@wso2.com] 
> Sent: Thursday, March 06, 2008 4:22 PM
> To: Apache AXIS C User List
> Subject: RE: Core dumps in Axis libraries
>
> Hi Raghav,
>
> Can you please try this with --enable-guthilla=yes, and send the 
> dump.log,
> and also the appropriate log_files generated by the server/client.
>
> There also can be issues with your "condition variable" being used in
> multiple threads.
>
> It also seems that if you pause between your requests you might get this
> solved. According to what you say, when you increase the log_level,
> obviously you waste some time there which might be the solution rather.
> You can use the AXIS2_SLEEP() and AXIS2_USLEEP() inside Axis2/C to pause
> between requests. You can get an idea on how to use these functions by
> taking a look at the Axis2/C user_guide/client samples.
>
> Regards,
> Senaka
>
>   
>> Thanks,
>>
>> As suggested, I tried using axis2c-1.3.0 both with and without
>> --enable-guthilla=yes. But I still see different dumps consistently.
>> Please find the attached file with back-traces.
>>
>> Are you using the same service client instance from multiple threads?
>>     
>>>>> We have a axis thread pool with default number of threads and a set
>>>>>           
>> of our own threads(about 10, lets call them "database threads").
>> + On receiving a HTTP soap request, axis thread invokes the 
>>     
> appropriate
>   
>> function that is bound to our logic.
>> + Now, the axis thread requests a "database thread" to perform the
>> appropriate query and waits on a condition variable.
>> + our "db thread" performs the necessary query and signals on that
>> condition variable so that axis thread shall take the control over.
>> + axis thread will create the om output and dispatch as usual.
>>
>> My doubts:
>> + does this design has any apparent drawback when there is a flurry of
>> back-to-back soap requests?
>> + Is there a need to increase the axis thread pool size? If yes, how 
>>     
> to
>   
>> do it?
>> + As told before, the dump is seen during a particular scenario only.
>> i.e: while trying to add a list of already existing users to my
>> database. For each user there is a SOAP request generated and the
>> requests are sequential, i.e the second request is sent only after the
>> response for previous request is received.
>> + if I increase the log level of my own module that uses axis2c, there
>> is no dump. On increasing the log level, my module writes quite a bit 
>>     
> of
>   
>> information to my log file.
>>
>> Your help is appreciated.
>>
>> Thanks & Regards,
>> ~raghav
>>
>>
>> -----Original Message-----
>> From: Samisa Abeysinghe [mailto:samisa@wso2.com]
>> Sent: Wednesday, March 05, 2008 7:25 PM
>> To: Apache AXIS C User List
>> Subject: Re: Core dumps in Axis libraries
>>
>> Raghavendra SM wrote:
>>     
>>> Thanks Manjula,
>>>
>>> But thats not a viable option for us. We would still want to continue
>>> using axis2C-1.0 for some more time.
>>>
>>> Are these dumps well known?
>>>       
>> No.
>>
>> Are you using the same service client instance from multiple threads?
>>
>> Samisa...
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>>     
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
>
>   


-- 
Samisa Abeysinghe 
Software Architect; WSO2 Inc.

http://www.wso2.com/ - "Oxygenating the Web Service Platform."


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org