[cfaussie] Re: Timeout not working on CFINVOKE?
OK, so I just looked a little closer, and I see that while both our stack traces show being in a socketread0, there's more to the story. When my code is stuck on the CFINVOKE, I see something different from you. For one thing, notice that at the bottom of my stack trace (below), I see the line of CFML that's executing (in my case, line 14 of invoke_web_service_that_waits.cfm). That's what's so great about FR's making these stack traces so easy. I can see exactly what line of code I'm executing when I ask for the stack trace. And it's what I'd expect, waiting for the invoked web service to respond. This is what it shows as I refresh the stack trace prior to the timeout I set. But I don't see any CF line number in your stack trace. It just ends with "(Unknown Source)". Did you not provide it all? Or is there no more? If there is no more, that may be interesting itself. More important, though, is that you'll notice our stack traces show different java methods being called. You read these from bottom up, from the source line of CFML to the various java methods it led to, which are often very deep. Mine reflects what happens when the CFINVOKE first leads to a coldfusion.tagext.lang.InvokeTag.doEndTag (2 lines above it, which shows CF was processing the "end" tag of the "cfinvoke"), and then ultimately a bunch of methods in the apache axis client, then ultimately some java network IO: at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:183) at java.io.BufferedInputStream.read(BufferedInputStream.java:201) - locked <0x14236310> (a java.io.BufferedInputStream) at org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket(HTTPSender.j ava:583) at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:143) at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java: 32) at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165) at org.apache.axis.client.Call.invokeEngine(Call.java:2765) at org.apache.axis.client.Call.invoke(Call.java:2748) at org.apache.axis.client.Call.invoke(Call.java:2424) at org.apache.axis.client.Call.invoke(Call.java:2347) at org.apache.axis.client.Call.invoke(Call.java:1804) at loadtest.Web_service_that_waitsCfcSoapBindingStub.waitfor_pre8(Web_service_t hat_waitsCfcSoapBindingStub.java:178) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at coldfusion.xml.rpc.ServiceProxy.invokeImpl(ServiceProxy.java:223) at coldfusion.xml.rpc.ServiceProxy.invoke(ServiceProxy.java:143) at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:1594) at coldfusion.tagext.lang.InvokeTag.doEndTag(InvokeTag.java:388) at coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:1916) at cfinvoke_web_service_that_waits2ecfm1489952292.runPage(C:\inetpub\wwwroot\lo adtest\invoke_web_service_that_waits.cfm:14) Yours, though, starts out looking at org.apache.xerces.impl.XMLEntityManager, which is the XML parser, and ultimately go through some com.sun.net.ssl.internal.ssl methods. So where mine was indeed waiting for the cfinvoke, yours is not. It may be in the processing of XML being sent as a result, but even that's a guess since we don't see it saying for sure that this is code invoked by the call to CFINVOKE. Let's hear your thoughts in reply. And I hope those watching aren't too annoyed by all this. I realize it may seem like gibberish to some. Hopefully others are getting some useful discoveries from the discussion. I've already heard one note off-line in appreciation. But apologies to those who think it too deep. At least the subject is clear enough that you can just skip the messages if you really want to. Just trying to help, Matthew and others. Again, this is the sort of stuff I do on a daily basic, though normally it's done over a shared desktop session (using Connect, or WebEx, etc.) where I'm in effect "looking over the shoulder" of the person with the problem, all done remotely, over port 80 (no firewall hole needed) and without a "remoting in" to their box. Usually this stuff takes just minutes or a couple of hours to sort out (and to explain so the person is more self-sufficient for future similar problems). In this case, email has taken a lot longer, but it's all been free. :-) /charlie -Original Message- From: cfaussie@googlegroups.com [mailto:cfaus...@goo
[cfaussie] Re: JRUN hanging
Well, before you get too excited, be careful that you're not misunderstanding the report. The memory reported there is NOT for the current request, but rather for the entire CF server. So that number alone isn't too meaningful. But if it ROSE by 32 meg when you ran a request, that would be different (but even then you can't be positive that a given request caused the rise. Other things can be running to increase memory besides the request you're running.) Rather than view the memory in the stack trace, to observe how it's changing over time, I'd recommend instead you watch either the graphical interface they offer for the memory graph, or view the info in the resource-x.log file, both of which report it at 5 second intervals. But if that indeed is a stack trace of the call to the web service, notice the top line which says: java.net.SocketInputStream.socketRead0(Native Method) That would be the kind of thing (a native method) that CF's request timeout feature can't interrupt normally, but again I have confirmed that in my test where the TIMEOUT of a CFINVOKE webservice call works, it is indeed timing out while sitting in that same state. My assertion is that CF has added some additional timeout callback mechanism in such a case, which it doesn't do as a matter of course on other code. Makes sense to me. The question is why it doesn't timeout for you--but that will be the thing to confirm now. When you have a request that you see runs long, and you KNOW it has a timeout, if you sit there refreshing the stack trace, does it remain in this socketread0 method beyond that timeout time? It doesn't for me. :-) /charlie -Original Message- From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On Behalf Of Matthew Sent: Wednesday, January 07, 2009 11:32 PM To: cfaussie Subject: [cfaussie] Re: JRUN hanging Hi Charlie, Out of interest (while I await a hung server) I've configured FR 2.0.4 on my dev PC and run a couple of calls to the web service whilst I watch them in FR. I was alarmed to see that my single request was costing 32MB of memory (32,438KB) This snapshot was taken at about the 30th second (the whole request finished after 55s). Here is the top part of the "Thread Stack Trace": Thread Stack Trace Trace Time: 15:26:34.224 08-Jan-2009 Request ID: 25 Script Name: http://foo Started: 15:26:04.177 08-Jan-2009 Exec Time:30047ms Memory Used: (6%)32,438KB Memory Free: 472,457KB Thread ID:jrpp-8 Priority: 5 Hashcode: 30900283 "jrpp-8" prio=5 tid=0x03c5f468 nid=0x3c4 runnable [559d000..559fd90] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA12275) at com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA12275) at com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA12275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275) - locked <0x158afd20> (a java.lang.Object) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275) at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA12275) - locked <0x158afc88> (a com.sun.net.ssl.internal.ssl.AppInputStream) at java.io.BufferedInputStream.read1(BufferedInputStream.java:220) at java.io.BufferedInputStream.read(BufferedInputStream.java:277) - locked <0x158afad8> (a java.io.BufferedInputStream) at java.io.FilterInputStream.read(FilterInputStream.java:111) at org.apache.xerces.impl.XMLEntityManager$RewindableInputStream.read (Unknown Source) Cheers Matthew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[cfaussie] Re: Timeout not working on CFINVOKE?
Hi guys, I've installed FR 2.0.4 on my dev machine to show you how the CFINVOIKE will not time out. I ran the sample code in my original post (this time with a 6 sec timeout just to be different) but it ran for 57s. Here is the "Thread Stack Trace" taken at about 25th second: Thread Stack Trace Trace Time: 15:36:18.993 08-Jan-2009 Request ID: 27 Script Name: http://dev/untitled.cfm Started: 15:35:54.353 08-Jan-2009 Exec Time:24640ms Memory Used: (7%)36,032KB Memory Free: 468,863KB Thread ID:jrpp-9 Priority: 5 Hashcode: 18823801 "jrpp-9" prio=5 tid=0x08dbc860 nid=0xef8 runnable [a69e000..a69fd90] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA12275) at com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA12275) at com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA12275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275) - locked <0x14be2d18> (a java.lang.Object) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275) at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA12275) - locked <0x14be2db8> (a com.sun.net.ssl.internal.ssl.AppInputStream) at java.io.BufferedInputStream.fill(BufferedInputStream.java:183) at java.io.BufferedInputStream.read1(BufferedInputStream.java:222) at java.io.BufferedInputStream.read(BufferedInputStream.java:277) - locked <0x14c10a90> (a java.io.BufferedInputStream) at java.io.FilterInputStream.read(FilterInputStream.java:111) at org.apache.xerces.impl.XMLEntityManager$RewindableInputStream.read (Unknown Source) Cheers Matthew On Jan 8, 12:55 pm, "charlie arehart" wrote: > No worries. Just a couple of quick replies: > > > @Charlie; > > 1. Sorry I did miss your joke. > > No, no. The point was I wasn't making a joke (in my reference to clean air > in Goulburn for Matt). When you said to MrB that there were fires, I wanted > to clarify that my earlier comment wasn't a joke. I lived in Canberra and > really to recall fondly the clean air in rural NSW. > > > 2. I'll aim to type FusionReactor correctly from now (these things > > annoy me as well especially when you're looking for a CF job and you > > have to type "Cold Fusion" and you end up with jobs like "Cold > > calling" :)). > > Yeah, wasn't being pedantic. More that if one doesn't spell it right, > sometimes it affects the results of searches, so was just pointing out the > distinction. > > > 3. I've already updated to v.2.0.4 (thanks for the pointer anyway). > > Cool. > > > 4. I will turn on Crash Protection Alert. > > Very cool: and don't do "abort and notify". Just notify. I persuaded to > change that in 3.01 to make notify the default/first listed item in the > dropdown. > > > 5. Sorry about blaming you for "bad" recordings. Perhaps it's just > > that I listen to a lot of the ones you introduce. I should have > > clarified that it is rare that the recording misses the start and to > > be honest I think it was only once that the speaker wasn't talking > > into the mike properly (I think it was the "Design Patterns" from 2nd > > Oct 08). Anyway, forget the negative comment, the recordings are great > > and thanks for collating them so cleanly. > > OK, so just wanted to be clear, since the CF meetup recordings are just a > subset of all the UGTV. But if you mean the CFmeetup meetings, yes, some > speakers aren't as clear as others. I meet them before the meeting to check > that, and if they lapse again during the talk people will complain. > Sometimes, though, it just can't be helped if there's either a network or > mic issue on their end. If I detect that during the advanced prep with them, > I would strive to get them to fix it before the meeting, for sure. > > But no problem offering the feedback. Always welcome. > > /charlie --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[cfaussie] Re: JRUN hanging
Hi Charlie, Out of interest (while I await a hung server) I've configured FR 2.0.4 on my dev PC and run a couple of calls to the web service whilst I watch them in FR. I was alarmed to see that my single request was costing 32MB of memory (32,438KB) This snapshot was taken at about the 30th second (the whole request finished after 55s). Here is the top part of the "Thread Stack Trace": Thread Stack Trace Trace Time: 15:26:34.224 08-Jan-2009 Request ID: 25 Script Name: http://foo Started: 15:26:04.177 08-Jan-2009 Exec Time:30047ms Memory Used: (6%)32,438KB Memory Free: 472,457KB Thread ID:jrpp-8 Priority: 5 Hashcode: 30900283 "jrpp-8" prio=5 tid=0x03c5f468 nid=0x3c4 runnable [559d000..559fd90] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA12275) at com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA12275) at com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA12275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275) - locked <0x158afd20> (a java.lang.Object) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275) at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA12275) - locked <0x158afc88> (a com.sun.net.ssl.internal.ssl.AppInputStream) at java.io.BufferedInputStream.read1(BufferedInputStream.java:220) at java.io.BufferedInputStream.read(BufferedInputStream.java:277) - locked <0x158afad8> (a java.io.BufferedInputStream) at java.io.FilterInputStream.read(FilterInputStream.java:111) at org.apache.xerces.impl.XMLEntityManager$RewindableInputStream.read (Unknown Source) Cheers Matthew On Jan 8, 12:33 pm, "charlie arehart" wrote: > No, you can't with FR get any sort of profile of what lines were slowest > within a request. Only the CF8 Server monitor has the depth of insight to > report that. What I had been referring to is if you can catch the request > WHILE it's running, in which case you can get a stack trace by clicking a > button to the left of the request, while you see it running. > > One other thing: you refer to my earlier suggestion as "browsing to the > WSDL", but to be clear, I wasn't proposing that (though not a bad idea). I > was proposing actually running the web service, by adding the method > attribute and passing in any needed simple arguments. But the fact that you > sometimes can't even get back the WSDL alone is certainly worrisome, and > something to bring to the attention of whoever runs the server being called. > This is just like how an end user would call any of us if our servers > weren't responding to their requests. :-) > > /charlie > > -Original Message- > From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On Behalf > > Of Matthew > Sent: Wednesday, January 07, 2009 8:04 PM > To: cfaussie > Subject: [cfaussie] Re: JRUN hanging > > 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 > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[cfaussie] Re: Timeout not working on CFINVOKE?
No worries. Just a couple of quick replies: > @Charlie; > 1. Sorry I did miss your joke. No, no. The point was I wasn't making a joke (in my reference to clean air in Goulburn for Matt). When you said to MrB that there were fires, I wanted to clarify that my earlier comment wasn't a joke. I lived in Canberra and really to recall fondly the clean air in rural NSW. > 2. I'll aim to type FusionReactor correctly from now (these things > annoy me as well especially when you're looking for a CF job and you > have to type "Cold Fusion" and you end up with jobs like "Cold > calling" :)). Yeah, wasn't being pedantic. More that if one doesn't spell it right, sometimes it affects the results of searches, so was just pointing out the distinction. > 3. I've already updated to v.2.0.4 (thanks for the pointer anyway). Cool. > 4. I will turn on Crash Protection Alert. Very cool: and don't do "abort and notify". Just notify. I persuaded to change that in 3.01 to make notify the default/first listed item in the dropdown. > 5. Sorry about blaming you for "bad" recordings. Perhaps it's just > that I listen to a lot of the ones you introduce. I should have > clarified that it is rare that the recording misses the start and to > be honest I think it was only once that the speaker wasn't talking > into the mike properly (I think it was the "Design Patterns" from 2nd > Oct 08). Anyway, forget the negative comment, the recordings are great > and thanks for collating them so cleanly. OK, so just wanted to be clear, since the CF meetup recordings are just a subset of all the UGTV. But if you mean the CFmeetup meetings, yes, some speakers aren't as clear as others. I meet them before the meeting to check that, and if they lapse again during the talk people will complain. Sometimes, though, it just can't be helped if there's either a network or mic issue on their end. If I detect that during the advanced prep with them, I would strive to get them to fix it before the meeting, for sure. But no problem offering the feedback. Always welcome. /charlie --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[cfaussie] Re: JRUN hanging
No, you can't with FR get any sort of profile of what lines were slowest within a request. Only the CF8 Server monitor has the depth of insight to report that. What I had been referring to is if you can catch the request WHILE it's running, in which case you can get a stack trace by clicking a button to the left of the request, while you see it running. One other thing: you refer to my earlier suggestion as "browsing to the WSDL", but to be clear, I wasn't proposing that (though not a bad idea). I was proposing actually running the web service, by adding the method attribute and passing in any needed simple arguments. But the fact that you sometimes can't even get back the WSDL alone is certainly worrisome, and something to bring to the attention of whoever runs the server being called. This is just like how an end user would call any of us if our servers weren't responding to their requests. :-) /charlie -Original Message- From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On Behalf Of Matthew Sent: Wednesday, January 07, 2009 8:04 PM To: cfaussie Subject: [cfaussie] Re: JRUN hanging 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[cfaussie] Re: Timeout not working on CFINVOKE?
@Charlie; 1. Sorry I did miss your joke. 2. I'll aim to type FusionReactor correctly from now (these things annoy me as well especially when you're looking for a CF job and you have to type "Cold Fusion" and you end up with jobs like "Cold calling" :)). 3. I've already updated to v.2.0.4 (thanks for the pointer anyway). 4. I will turn on Crash Protection Alert. 5. Sorry about blaming you for "bad" recordings. Perhaps it's just that I listen to a lot of the ones you introduce. I should have clarified that it is rare that the recording misses the start and to be honest I think it was only once that the speaker wasn't talking into the mike properly (I think it was the "Design Patterns" from 2nd Oct 08). Anyway, forget the negative comment, the recordings are great and thanks for collating them so cleanly. I continue to eagerly await a "hang". Cheers Matthew On Jan 8, 12:02 pm, "charlie arehart" wrote: > So my quip about clean NSW air was made without any knowledge of fires. > Bummer. I wasn't being sarcastic. :-( > > As for FusionReactor (it's spelled without a space, like CF), the 2.0 > version will work. But you can upgrade to 2.04 to get all the fixes and > enhancements. More, including the steps and the update file itself, at: > > http://www.fusion-reactor.com/support/kb/FRS-190.cfm > > You can also learn what changed since 2.0 at: > > 2.04 release noteshttp://www.fusion-reactor.com/support/kb/FRS-162.cfm > > 2.03 release noteshttp://www.fusion-reactor.com/support/kb/FRS-159.cfm > > As for the challenge that "it'll probably be a few days before we get a hang > scenario again", be sure to consider the Crash Protection Alert notification > feature, so you get sent the email when too many threads hang up. It will > have the thread dump in the email, which is great, so at least you don't > have to "be there" when it happens. :-) > > Finally, about the UGTV, thanks for the kind regards. But you say, "please > do your best to catch the recordings from the start plus make sure the > speakers talk clearly into the mike." I'm wondering: if you're referring to > recordings on the UGTV site, I don't control those at all. I created it > (carehart.org/ugtv/) simply as a repository to provide a place to point to > (and search for/browse) presentations that others have made. > > Now, among those pointed to are the CF Meetup recorded presos > (coldfusionmeetup.com), and I do run that (though again it's other speakers > generally),but I do always start the recording at the point I introduce the > speaker, so I'm really thinking you're referring to other UGTV talks created > by others. I'm afraid I really can't control them. :-( > > /charlie > > -Original Message- > From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On Behalf > > Of Matthew > Sent: Wednesday, January 07, 2009 5:12 PM > To: cfaussie > Subject: [cfaussie] Re: Timeout not working on CFINVOKE? > > @MrBuzzy, thanks for making the effort to reply. I thought there were > fires near Goulburn? You've explained precisely what I've always > thought has been the problem but as Charlie has rightly suggested I > should get the proof via a monitoring tool to be sure. I'm trying to > get Fusion Reactor installed (we've got the licence for v2.0.0 so I > hope that still does the job), it'll probably be a few days before we > get a hang scenario again but once it happens I'll report back. I > appreciate your help. > > @Charlie, thanks to MrB you now understand my issue however I will get > the evidence for further discussion. By the way, this is a little OT > but thanks a million for the huge effort of running UGTV. I rarely > make a live session (usually due to the time difference) however I > often go to the site and view the recordings. Please keep it up and > please do your best to catch the recordings from the start plus make > sure the speakers talk clearly into the mike. Thanks a million > again!!! > > Cheers > Matthew > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[cfaussie] Re: JRUN hanging
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" 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 -~--~~~~--~~--~--~---
[cfaussie] Re: Timeout not working on CFINVOKE?
So my quip about clean NSW air was made without any knowledge of fires. Bummer. I wasn't being sarcastic. :-( As for FusionReactor (it's spelled without a space, like CF), the 2.0 version will work. But you can upgrade to 2.04 to get all the fixes and enhancements. More, including the steps and the update file itself, at: http://www.fusion-reactor.com/support/kb/FRS-190.cfm You can also learn what changed since 2.0 at: 2.04 release notes http://www.fusion-reactor.com/support/kb/FRS-162.cfm 2.03 release notes http://www.fusion-reactor.com/support/kb/FRS-159.cfm As for the challenge that "it'll probably be a few days before we get a hang scenario again", be sure to consider the Crash Protection Alert notification feature, so you get sent the email when too many threads hang up. It will have the thread dump in the email, which is great, so at least you don't have to "be there" when it happens. :-) Finally, about the UGTV, thanks for the kind regards. But you say, "please do your best to catch the recordings from the start plus make sure the speakers talk clearly into the mike." I'm wondering: if you're referring to recordings on the UGTV site, I don't control those at all. I created it (carehart.org/ugtv/) simply as a repository to provide a place to point to (and search for/browse) presentations that others have made. Now, among those pointed to are the CF Meetup recorded presos (coldfusionmeetup.com), and I do run that (though again it's other speakers generally),but I do always start the recording at the point I introduce the speaker, so I'm really thinking you're referring to other UGTV talks created by others. I'm afraid I really can't control them. :-( /charlie -Original Message- From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On Behalf Of Matthew Sent: Wednesday, January 07, 2009 5:12 PM To: cfaussie Subject: [cfaussie] Re: Timeout not working on CFINVOKE? @MrBuzzy, thanks for making the effort to reply. I thought there were fires near Goulburn? You've explained precisely what I've always thought has been the problem but as Charlie has rightly suggested I should get the proof via a monitoring tool to be sure. I'm trying to get Fusion Reactor installed (we've got the licence for v2.0.0 so I hope that still does the job), it'll probably be a few days before we get a hang scenario again but once it happens I'll report back. I appreciate your help. @Charlie, thanks to MrB you now understand my issue however I will get the evidence for further discussion. By the way, this is a little OT but thanks a million for the huge effort of running UGTV. I rarely make a live session (usually due to the time difference) however I often go to the site and view the recordings. Please keep it up and please do your best to catch the recordings from the start plus make sure the speakers talk clearly into the mike. Thanks a million again!!! Cheers Matthew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[cfaussie] Re: Timeout not working on CFINVOKE?
@MrBuzzy, thanks for making the effort to reply. I thought there were fires near Goulburn? You've explained precisely what I've always thought has been the problem but as Charlie has rightly suggested I should get the proof via a monitoring tool to be sure. I'm trying to get Fusion Reactor installed (we've got the licence for v2.0.0 so I hope that still does the job), it'll probably be a few days before we get a hang scenario again but once it happens I'll report back. I appreciate your help. @Charlie, thanks to MrB you now understand my issue however I will get the evidence for further discussion. By the way, this is a little OT but thanks a million for the huge effort of running UGTV. I rarely make a live session (usually due to the time difference) however I often go to the site and view the recordings. Please keep it up and please do your best to catch the recordings from the start plus make sure the speakers talk clearly into the mike. Thanks a million again!!! Cheers Matthew On Jan 8, 5:31 am, "charlie arehart" wrote: > Wow, all that on a mobile. What a trooper. :-) Must be that clean NSW air > there in Goulburn. > > Fair enough on the confirmation of another instance of CFINVOKE of a > webservice with a timeout not doing so. Would love to get to the bottom of > things I really do wonder if the hangup's in the waiting (which my test seems > to suggest it's not) or in some processing. I realize you say it was " > waiting for the java.net class", so maybe you're really saying you saw that. > I just wonder if necessarily that's the case for Matthew. The beauty of the > stack trace is that it will tell us, exactly, without guesses. That will be > good to hear. > > Enjoy the holiday. > > /charlie > > -Original Message- > From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On Behalf > Of MrBuzzy > Sent: Wednesday, January 07, 2009 10:42 AM > To: cfaussie@googlegroups.com > Subject: [cfaussie] Re: Timeout not working on CFINVOKE? > > Oh man why do the good conversations always happen when I'm > holidaying. I've just driven 700kms up to Golburn and it's about > 130am. > > These quick words aren't well thouht through so I sooologise in > advance for that. And I'm on a mobile phone. I don't really have time > to back track, so please allow me to just append my opinions and hit > the hey :) > > My experience has been as follows; > > 1. To agree with Charlie, cfinvoke timeout will and can time out. It's > not broken. > > However this is not always the case. > > 2. There are definitely situations where it WILL NOT do so. I've seen > it with my own eyes, and I have used FusionReactor to provide the > proof, which Charlie suggested Matthew does and I think that's an > excellent suggestion. > > To summarize my 'proof' > - I have seen cold fusion PAGE requests that are still 'running' after > 300,000+ seconds. Yep in CFB.0.1 > - do a stack trace on one of these running pages and the page thread > is clearly stuck waiting in the guts of a cfinvoke, waiting for a > websevice request to complete. (Charlie, if I read you correctly, you > are asserting that this is not possible because the cfinvoke timeout > WILL save the day. I wish that was the case!) > > (To be clear, I'm not bagging CF, in my case I am quite sure the > non-cf webservice is to blame). > > In a nut shell this is what occurs; > We call a web service which knowingly takes a while to run (could be > minutes and varies). > For what ever reason the Web Service does not complete it's work or > maybe it does. > Not another single packet is sent back to CF and CF is left hanging, > waiting for the java.net class to give us a sign of what's happening. > So why does the WS send nothing back? Not sure maybe apache timed it > out. Maybe a firewall did something to the long running request. Many > possibilities. > (I've heard grumbles that CF is not using http 1.1 and it might all > work better if it used that keepalive thingy. And might be totally > wrong info too) > > Zackster, I have implemented almost exactly what you suggested using > cfthread and it can work, but just shifts the problem (with minor > benefits). > The net effect is that the end user may be shielded from a hung > browser request, but instead the hung thread will be there in a > cfthread. Eventually the cfthread pool will run out of available > threads I guess. > > When I'm back in Melbourne I'd be happy to provide more info on this > one if the conversation is still alive :) > > Ouchies sore thumbs now. > > Ps: don't even get me started on timeouts and parsing of the wsdl. > Whole different problem. > > Pps: there is also a KB article about setting the timeouts directly on > the underlying Axis objects. But I can't remener what problem that > solves. > > G'night! > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@go
[cfaussie] Re: Timeout not working on CFINVOKE?
Wow, all that on a mobile. What a trooper. :-) Must be that clean NSW air there in Goulburn. Fair enough on the confirmation of another instance of CFINVOKE of a webservice with a timeout not doing so. Would love to get to the bottom of things I really do wonder if the hangup's in the waiting (which my test seems to suggest it's not) or in some processing. I realize you say it was " waiting for the java.net class", so maybe you're really saying you saw that. I just wonder if necessarily that's the case for Matthew. The beauty of the stack trace is that it will tell us, exactly, without guesses. That will be good to hear. Enjoy the holiday. /charlie -Original Message- From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On Behalf Of MrBuzzy Sent: Wednesday, January 07, 2009 10:42 AM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: Timeout not working on CFINVOKE? Oh man why do the good conversations always happen when I'm holidaying. I've just driven 700kms up to Golburn and it's about 130am. These quick words aren't well thouht through so I sooologise in advance for that. And I'm on a mobile phone. I don't really have time to back track, so please allow me to just append my opinions and hit the hey :) My experience has been as follows; 1. To agree with Charlie, cfinvoke timeout will and can time out. It's not broken. However this is not always the case. 2. There are definitely situations where it WILL NOT do so. I've seen it with my own eyes, and I have used FusionReactor to provide the proof, which Charlie suggested Matthew does and I think that's an excellent suggestion. To summarize my 'proof' - I have seen cold fusion PAGE requests that are still 'running' after 300,000+ seconds. Yep in CFB.0.1 - do a stack trace on one of these running pages and the page thread is clearly stuck waiting in the guts of a cfinvoke, waiting for a websevice request to complete. (Charlie, if I read you correctly, you are asserting that this is not possible because the cfinvoke timeout WILL save the day. I wish that was the case!) (To be clear, I'm not bagging CF, in my case I am quite sure the non-cf webservice is to blame). In a nut shell this is what occurs; We call a web service which knowingly takes a while to run (could be minutes and varies). For what ever reason the Web Service does not complete it's work or maybe it does. Not another single packet is sent back to CF and CF is left hanging, waiting for the java.net class to give us a sign of what's happening. So why does the WS send nothing back? Not sure maybe apache timed it out. Maybe a firewall did something to the long running request. Many possibilities. (I've heard grumbles that CF is not using http 1.1 and it might all work better if it used that keepalive thingy. And might be totally wrong info too) Zackster, I have implemented almost exactly what you suggested using cfthread and it can work, but just shifts the problem (with minor benefits). The net effect is that the end user may be shielded from a hung browser request, but instead the hung thread will be there in a cfthread. Eventually the cfthread pool will run out of available threads I guess. When I'm back in Melbourne I'd be happy to provide more info on this one if the conversation is still alive :) Ouchies sore thumbs now. Ps: don't even get me started on timeouts and parsing of the wsdl. Whole different problem. Pps: there is also a KB article about setting the timeouts directly on the underlying Axis objects. But I can't remener what problem that solves. G'night! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[cfaussie] Re: Timeout not working on CFINVOKE?
Oh man why do the good conversations always happen when I'm holidaying. I've just driven 700kms up to Golburn and it's about 130am. These quick words aren't well thouht through so I sooologise in advance for that. And I'm on a mobile phone. I don't really have time to back track, so please allow me to just append my opinions and hit the hey :) My experience has been as follows; 1. To agree with Charlie, cfinvoke timeout will and can time out. It's not broken. However this is not always the case. 2. There are definitely situations where it WILL NOT do so. I've seen it with my own eyes, and I have used FusionReactor to provide the proof, which Charlie suggested Matthew does and I think that's an excellent suggestion. To summarize my 'proof' - I have seen cold fusion PAGE requests that are still 'running' after 300,000+ seconds. Yep in CFB.0.1 - do a stack trace on one of these running pages and the page thread is clearly stuck waiting in the guts of a cfinvoke, waiting for a websevice request to complete. (Charlie, if I read you correctly, you are asserting that this is not possible because the cfinvoke timeout WILL save the day. I wish that was the case!) (To be clear, I'm not bagging CF, in my case I am quite sure the non-cf webservice is to blame). In a nut shell this is what occurs; We call a web service which knowingly takes a while to run (could be minutes and varies). For what ever reason the Web Service does not complete it's work or maybe it does. Not another single packet is sent back to CF and CF is left hanging, waiting for the java.net class to give us a sign of what's happening. So why does the WS send nothing back? Not sure maybe apache timed it out. Maybe a firewall did something to the long running request. Many possibilities. (I've heard grumbles that CF is not using http 1.1 and it might all work better if it used that keepalive thingy. And might be totally wrong info too) Zackster, I have implemented almost exactly what you suggested using cfthread and it can work, but just shifts the problem (with minor benefits). The net effect is that the end user may be shielded from a hung browser request, but instead the hung thread will be there in a cfthread. Eventually the cfthread pool will run out of available threads I guess. When I'm back in Melbourne I'd be happy to provide more info on this one if the conversation is still alive :) Ouchies sore thumbs now. Ps: don't even get me started on timeouts and parsing of the wsdl. Whole different problem. Pps: there is also a KB article about setting the timeouts directly on the underlying Axis objects. But I can't remener what problem that solves. G'night! On 07/01/2009, charlie arehart wrote: > > Sure, happy to help. Apologies, at least, to those who don't like long > emails. But challenges like this can require this kind of back and forth to > narrow things down. > > Let's start with your first point, "I know you've run tests to prove to > yourself that a CFINVOKE web service call will timeout but it's not the case > for me (nor MrBuzzy). Perhaps you ran the test to call another CF web > service (even a local CF web service)". > > Well, no, the whole point I was making was that if you WERE calling a local > one, I could see the confusion (as the caller would timeout, but the called > page would not). No, I was testing a call from one CF page invoking a remote > web service. And it shouldn't matter what the destination web service is > written in. The point is that I proved that the CFINVOKE webservice with a > TIMEOUT does indeed stop, and get that timed out error. It so happens that I > was calling a CF page on a remote server, and so I used FR to confirm that > the called web service method (which I'd forced to go to sleep) does indeed > continue to process on the remote server. > > I made my assertion despite what you and Mr B said because I wanted to make > sure folks didn't conclude that what you said was indeed the way it always > is. And while I countered Mr B (whose writing I always respect and enjoy), > it was because I sensed he was speaking more from recollection, and with the > "old chestnut" being that CF itself couldn't stop pages with its overall > timeout. That is indeed true, and a frequent source of confusion for people. > But he was agreeing with you that the CFINVOKE webservice TIMEOUT didn't > work, and I knew (and proved once more before writing you guys) that it did. > > So we still have doubt about your observation. You say you sometimes get the > webservice timeout. What about that? And my most substantial question is: > are you viewing something that shows you what requests are running when > things hang up? And of those, are you viewing the stack trace to see exactly > what line of code the request is "hung" on? > > As for your confirmation that the CFTIMER shows that the timeout didn't > take, here's another thought: exactly what version of CF 7 are you running? > 7? 7.01? 7.02? Any cumulative hotfixe
