Intermittent malformed cfhttp result structure

[Kit Watson]

We have a <cfhttp> transaction running in a schedule task. The great majority of these POST operations are successful, and give us the response we expect. Intermittently, though, and without any discernible predictability, we get back in the result variable (specified in the result attribute of the <cfhttp> tag) a structure that does not contain a fileContent key/value, in spite of a '200 OK' statusCode. What we'd like to know is why there would ever be a result structure that did not include a fileContent key? We rigged up a test harness that performed the same exact operation as a standalone request, and even looped it, threaded and unthreaded, to test for any race conditions. In our harness, everything is beautiful; the result structure is always valid. As a scheduled task, however, we are seeing this missing key pop up every once in a while. Nothing really special going on in these transactions. We're simply posting XML in the body of the request to a web service, and getting XML back in the fileContent of the response. Has anyone else witnessed this undesirable behavior?

[Andrew Dixon]

Hi Kit,

Could it be the response is timing out and therefore there is nothing returned and as such no fileContent?

Kind regards,

Andrew

about.me - mso - Lucee Association Member

On 8 October 2015 at 22:53, Kit Watson <only...@gmail.com> wrote:

We have a <cfhttp> transaction running in a schedule task. The great majority of these POST operations are successful, and give us the response we expect. Intermittently, though, and without any discernible predictability, we get back in the result variable (specified in the result attribute of the <cfhttp> tag) a structure that does not contain a fileContent key/value, in spite of a '200 OK' statusCode. What we'd like to know is why there would ever be a result structure that did not include a fileContent key? We rigged up a test harness that performed the same exact operation as a standalone request, and even looped it, threaded and unthreaded, to test for any race conditions. In our harness, everything is beautiful; the result structure is always valid. As a scheduled task, however, we are seeing this missing key pop up every once in a while. Nothing really special going on in these transactions. We're simply posting XML in the body of the request to a web service, and getting XML back in the fileContent of the response. Has anyone else witnessed this undesirable behavior?

--
See Lucee at CFCamp Oct 22 & 23 2015 @ Munich Airport, Germany - Get your ticket NOW - http://www.cfcamp.org/
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/039cec5f-a2fc-459d-8715-73d4bdbe613e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kit Watson]

[Kit Watson]

No, it's most definitely not related to timing out. We have the <cfhttp> wrapped with GetTickCount polls, and none of these requests are coming back in any more than 200-300 ms.

Kit

[Kit Watson]

Does anyone else have any other ideas on this? I have provided a screen shot of a dump of the cfhttp result structure, and it shows that there is no fileContent key present, yet there is a '200 OK' statusCode. This does not happen all the time. In fact, in most cases there is indeed a fileContent key and value present, yet we have seen the StructKeyExists function return a False value in such a case. We are at a loss to explain for ourselves this unpredictable behavior under Lucee, and are wondering if this is a known issue, or if anyone else has experienced anything like it. Thank you!

[Paul Klinkenberg]

Hi Kit,

My first guess would be a scoping issue. Is the cfhttp tag within a cffunction, or is there a cfhttp variable within another scope, eg. request,url, form?

To rule this option out, you could add a result attribute to the cfhttp tag, eg. <cfhttp url="..." result="local.httpResult">, and then refer to "local.httpResult.fileContent". (replace local. with variables. if you're not inside a cffunction)

Kind regards,

Paul Klinkenberg

Op 19 okt. 2015, om 20:03 heeft Kit Watson <only...@gmail.com> het volgende geschreven:

Does anyone else have any other ideas on this? I have provided a screen shot of a dump of the cfhttp result structure, and it shows that there is no fileContent key present, yet there is a '200 OK' statusCode. This does not happen all the time. In fact, in most cases there is indeed a fileContent key and value present, yet we have seen the StructKeyExists function return a False value in such a case. We are at a loss to explain for ourselves this unpredictable behavior under Lucee, and are wondering if this is a known issue, or if anyone else has experienced anything like it. Thank you!

--
See Lucee at CFCamp Oct 22 & 23 2015 @ Munich Airport, Germany - Get your ticket NOW - http://www.cfcamp.org/
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/8d528321-1a23-451d-8e6e-34bcb53a89fe%40googlegroups.com.

[Kit Watson]

In this case, the cfhttp tag is used within a private cffunction of a CFC that has been instantiated into the Application scope. That cffunction is called from a public cffunction within the same CFC, which in turn is invoked through the persistent Application-scoped component object from many different spots in the app. We have looked at all possible scoping scenarios. We have used the special cfhttp variable, and also used our own result variable, scoped to the cffunction (because that result structure is not accessed anywhere else but in that cffunction). Still no change in behavior.