Intermittent malformed cfhttp result structure

We have a 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 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?

https://lh3.googleusercontent.com/-lMJ1GVK3CCQ/VhbscqzzqqI/AAAAAAAAO2w/CoJgrO2ECI0/s1600/cfhttp_result.jpgOn Thursday, October 8, 2015 at 2:53:13 PM UTC-7, Kit Watson wrote:

We have a 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 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?

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 http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.orgOn 8 October 2015 at 22:53, Kit Watson <@Kit_Watson> wrote:

We have a 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 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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/039cec5f-a2fc-459d-8715-73d4bdbe613e%40googlegroups.com
https://groups.google.com/d/msgid/lucee/039cec5f-a2fc-459d-8715-73d4bdbe613e%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

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!

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. , and then refer to “local.httpResult.fileContent”. (replace local. with variables. if you’re not inside a cffunction)

Kind regards,

Paul KlinkenbergOp 19 okt. 2015, om 20:03 heeft Kit Watson <@Kit_Watson> 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/ 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+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/8d528321-1a23-451d-8e6e-34bcb53a89fe%40googlegroups.com https://groups.google.com/d/msgid/lucee/8d528321-1a23-451d-8e6e-34bcb53a89fe%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

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.On Tuesday, October 20, 2015 at 4:34:12 AM UTC-7, Paul Klinkenberg wrote:

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. , and then refer to
“local.httpResult.fileContent”. (replace local. with variables. if you’re
not inside a cffunction)

Kind regards,

Paul Klinkenberg