Hi again Raghav, Forgot to mention.
This is of course if you use mod_axis2. If not I don't think this might affect you rather. Anyway the FastCGI issue may not be relevant at all. I came across that while googling for what could cause a SIGTERM in accept(2). Also, is "http_server_main.cpp" something that you've written on your own? If so, the issue might be in there sometimes. Regards, Senaka > Hi Raghav, > > Are you connecting to a fast CGI server? > > If so, I think that [1] would help. > > [1] http://search.cpan.org/src/JURACH/FCGI-ProcManager-0.17/ProcManager.pm > > Regards, > Senaka > >> 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? >> + Can we make out anything out of the valgrind report or the axis logs >> that were attached? >> >> Regards, >> ~raghav >> >> >> -----Original Message----- >> From: Senaka Fernando [mailto:[EMAIL PROTECTED] >> 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:[EMAIL PROTECTED] >>> 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: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
