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]
