cfhttp appears to be not thread-safe

Description

When CFHTTP is used in multiple simultaneous threads, data is occasionally lost. Also tested with Lucee 5.1 (problem not reproduced there), but my 5.1 instance is running on a slow VM, so it's not clear if the 'success' is due to the problem being resolved in 5.1 or the VM environment not producing the magic timing.

attached code reproduces the problem most of the time (more reliably with 4.5.4) - you may want to add more URLs to the array - see comments at line 44 and 52 - both have 'join' calls [one for single-thread, the other for multi-thread]

Environment

Windows 7, dual-core CPU, Java 1.8.0_112

Attachments

1

Activity

Michael Offner 19 January 2017 at 08:24

this is not a bug, this is expected behaviour, but we plan to change the expected behaviour, for detail check this ticket

Michael Offner 19 January 2017 at 08:23

you can also set "localmode" to true with your function, see comments here for detail. Ticket is addressing this topic, so setting cfhttp,cfquery,... to local scope if exists.

Pothys - MitrahSoft 5 January 2017 at 11:28

I've analyzed this ticket a lot & found that Brad wood's gives the right solution for 4.5.x.x, & it seems, the issue has been already fixed with 5.x. I've added the test cases for this.

Pull request: https://github.com/lucee/Lucee/pull/154

Brad Wood 5 January 2017 at 04:34

Out of curiosity, what happens if instead of varring httpresults above, you actually change the cfhttp tag to have results="local.httpResults"?

It seems like httresults is still getting put in the variables scope. You can also test this by dumping out the local and variables scope after one of the http calls to confirm where the httpresults variable is living.

Tim Parker 5 January 2017 at 00:24
Edited

Update - the example above wasn't complete - the actual failure was happening a few lines later -

=======
changing the guts of this to:

... made the (occasional) crash (status_code does not exist in httpResults) go away - so it seems that the root of the problem was recycling the 'httpResults' variable

so... it seems that there may be a problem with CFHTTP not completely protecting input values - I'd argue that this should be fixed, but it clearly doesn't qualify as 'urgent'

Won't Fix

Details

Assignee

Reporter

Priority

New Issue warning screen

Before you create a new Issue, please post to the mailing list first https://dev.lucee.org

Once the issue has been verified, one of the Lucee team will ask you to file an issue

Affects versions

Created 28 December 2016 at 00:33
Updated 19 January 2017 at 08:24
Resolved 19 January 2017 at 08:24