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...@googlegroups.com] On Behalf
Of Matthew
Sent: Wednesday, January 07, 2009 11:45 PM
To: cfaussie
Subject: [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



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

Reply via email to