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 -~----------~----~----~----~------~----~------~--~---
