On Aug 22, 2011, at 11:38 AM, Chuck Hill wrote: > > On 2011-08-21, at 12:43 PM, Tim Worman wrote: > >> On Aug 21, 2011, at 11:52 AM, Chuck Hill wrote: >> >>> >>> On 2011-08-20, at 4:02 PM, Tim Worman wrote: >>> >>>> Back in January I started this discussion on this same topic: >>>> >>>> http://lists.apple.com/archives/webobjects-dev/2011/Jan/msg00224.html >>>> >>>>>> I have an app that, during the course of normal usage, is starting httpd >>>>>> processes on the server that instantly hit 100% CPU usage of one core. >>>>>> This can happen multiple times during times when the app is under >>>>>> heavier load. After some time I can have many httpd processes where TOP >>>>>> reports each using 100% of a core. When I try to log into the app and >>>>>> poke around to try and reproduce the issue, I am unable. >>>> >>>> This is an update to my original post hoping to see if there are anymore >>>> thoughts on origin. More recently, I have been able to reproduce the issue >>>> in my own usage of the app - something I wasn't able to do before. It >>>> seems to be easier to generate the issue now that there are more ajax >>>> requests. The methods executed by these requests are not intensive or long >>>> responses and should return a result in seconds. Some symptoms: >>>> >>>> - When the actions are executed, busy indicators properly spin while the >>>> browser awaits a response from the server. When the issue occurs, the >>>> response never comes. >>>> - while continuing to await a response there is concurrently an httpd >>>> process that pegs he processor at 100% >>>> - if I kill the process on the server, the browser immediately updates >>>> properly as if the request had run properly >>>> >>>> It's almost as if apache is somehow receiving an ill-formed request and >>>> chokes on it. The problem is, there are no errors in the console or >>>> anything strange in any apache logs. Has anyone ever seen behavior like >>>> this or have any ideas as to how I could analyze it further? >>> >>> I've seen something like this. It appeared that the woadaptor (i.e. >>> mod_webobjects) did not believe that it had received all of the response >>> from the application. The app had nothing more to send and so the >>> woadaptor just hung there waiting for data that would never come. I did >>> not track down why this happened, but it did seem to be load related. My >>> suspicion was that there is a concurrency bug in the woadaptor. >> >> I'm really at a loss about what to do about it. It's only gotten worse as >> I've included more ajax actions in my app - and, of course, I don't >> experience this behavior in development. I just deployed a major update to >> my app - pretty much unaware that a small problem was going to become a big >> problem with the new version. >> >> In one example, a have a calendar where clicking on a day simply calls an >> AjaxUpdate marking that date as selected to the calendar. The result also >> has to update the entire page though because other things on the page need >> to change in those circumstances. This alone can cause the issue - but not >> always. And it happens even when I'm the only logged in user - so the load >> isn't high. >> >> As one solution, I've considered rolling a custom apache instead of using >> Apple's. But since the server also runs shibboleth, the setup isn't exactly >> simple. But I'm really not sure how to ascertain if the problem is the >> woadaptor or how I can settle it. > > > You could try the CGI adaptor and see if that makes any difference. If it IS > a bug in mod_webobjects... that could be hard to find and fix.
Yeah, I'd say so. I don't even know C. :-) I'm gonna pursue some other things first - like a possible hardware issue, or other software. I'm going to try a deployment on another server and see if that has any effect - also without shibboleth. Is there any chance that an issue with the id's of page elements could cause an issue like this - say if they're dynamic and the response doesn't find a matching id? Tim Worman UCLA GSE&IS _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
