I've got Fusion Reactor 2.0.0 (this is the only licence we have) up and running and am looking at the "Request History". We've not had a hang yet but I just wanted to get familiar with the tool. I'm looking at the requests which are taking 45+ seconds and they are all pages which involve a call to the web service. The pages are not timing out so I'm not getting error logs showing where the timeout occured however is there anyway to see which lines of code are the slow bits? I'm trying to work out if the call to the web service is the slow bit or if it's the unpacking and trying to display the data which may be slow.
I'll report back what I'm seeing when the next hang happens. @Charlie: I've tried your idea of browsing to the WSDL while a hang is occuring and I've had mixed scenerios. Sometimes it won't come up, sometimes it comes up but when I try to submit to a method it times out, sometimes it doesn't time out but it does take ages. Anyway, once I get the next hang I'll be able to report back on what I see. Cheers Matthew On Jan 7, 2:48 pm, "charlie arehart" <charlie_li...@carehart.org> wrote: > Yes, Mark makes a good point. You are saying these are the same problems, > right? I didn't pick up on it earlier, but when you said that when things > hang, there's high cpu, that really does seem to point to a very different > problem. > > I'll go back to my previous point: I'd be VERY interested if you can confirm > that when things hang, whether the stack traces for running requests really > are doing the webservice call you say, because as Mark says, if CF's just > "waiting" for them to come back, that shouldn't take up much CPU. > > Or, thinking outside the box, maybe in fact this IS where CPU time is being > spent (and it may explain why the TIMEOUT isn't working). What if you find > that indeed CF is in fact running the CFINVOKE when things hang, but instead > of "just waiting" for the webservice result, what if the problem is that the > web service returns a HUGE amount of data for some reason. Perhaps there's > an error in the web service, or perhaps the variation depends on the kind of > data users request. Just as a CFQUERY could be written to bring back a > million records from a database (and user input might vary that result from > 1 to a million), so too could a web service call that basically returns > query-driven data that varies with user input. > > Or maybe it's not so much huge, but it's complex, and CF is spending time in > the Axis java code called by CFINVOKE trying to render the result, > converting it from whatever format it's served in to a form that CF can > process. That would reflect in it being "hung" on the CFINVOKE, and possibly > not interruptible because it's processing file system I/O. That's just a > guess. > > But all this again speaks to the value of logging the web service calls. If > you add in logging the input being passed, you may find that there's a > pattern where the requests that hang up pass in some value. That's just a > guess. I realize you may content that you know that there are times when it > hangs on something you think should bring back one record. > > But here's another idea: if you do log it, and you do get a situation where > CF hangs up that you think is due to the web service calls (indeed, even if > you get the stack trace and prove it), then I would recommend you go try to > browse the web service yourself, separately from that CF server. Some web > services can be called entirely in a browser, if the input arguments are > simple (as inhttp://url/service.wsdl?method=somemethod&inputarg1=value1). > Or if that can't work, setup a CF page that you run on a different server > (not the one that's hung), such as your laptop, and run the request there. > See if you get any back any input, to see what it looks like. > > Again, all just some ideas to consider. > > /charlie > > -----Original Message----- > From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On Behalf > > Of Mark Mandel > Sent: Tuesday, January 06, 2009 10:29 PM > To: cfaussie@googlegroups.com > Subject: [cfaussie] Re: JRUN hanging > > Honestly, I'd be surprised if it was the problem you described > (although I could be wrong), simply because it's maxing out the CPU, > which tends to lean towards and infinite loop. > > If it was simply locking at the point of the webservice, then there > would be no (or very little) CPU activity, but JRUN just wouldn't do > anything. > > Mark > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
