Per dev Lucee thread.

Bug: REST endpoints, using cfoutput, will NOT return data the first few times the endpoint is called; whereas cfreturn DOES return data every time consistently.

Repro:

Troubleshooting: I have exhaustively tested many combinations of settings and code, ensuring this was something with cfoutput inside REST context, before submitting to dev.lucee and then here per dev request. Settings tested include: static output, numeric output, try/catch, null cfreturn directive, cfthread, cfheader options, processing directive (suppress whitespace), cfscript, including a template which has cfoutput, buffering, output / return types, compiling and performance options, caching, RAM cache vs file cache, TRACE debugging on, reboots, etc.

Troubleshooting NOT DONE: Different Java versions, testing on Linux vs Windows server,

Details:
* The blank response happens on GET or POST / other verb endpoints.
* The blank responses return a 200 OK header, and do not generate any debug / error logs. (Known issue with REST logging at )

Logging:
The only logs returned for successful OR blank, with EVERYTHING set to trace level, is in the scope.log referencing scopes started / stopped:

Version differences:
* Versions 5.9.x and 5.10.x behave a little differently than 6.0.0. Versions 5.9.x and 5.10.x seem wildly inconsistent; after 2-4 blanks, you’ll get good data for 2-3 times or 10 seconds, after which we’re back to blanks; but sometimes “every other request” is blank.
* On 5.9.x and 5.10.x, testing across different endpoints – blanks / response on any given endpoint, does NOT affect the blank / response on a different endpoint, e.g. they seem “separated”. (Example: If I hit /api/v1/test a few times until I get a good response, then hit /api/v1/other, I may or may not get blank, it doesn’t correlate at all.

* Versions 6.0 however - it seems to return blank EXACTLY 1 TIME, after which it will consistently return data for up to 60 seconds – and the return behavior happens across all endpoints, e.g. so if I hit /api/v1/test, get a blank, and then for 60 seconds ANY endpoints I hit return data. This made it easy to write a “keep alive” script to just hit a misc endpoint every 50 seconds. These scheduled tasks showed in the scheduled.log, and testing with automated tools and manual showed it worked!

* This worked for about 1 hour; however, after about 1 hour of consistent work, the 6.0.0 branch started acting like the 5.x, with inconsistent cache timings and inconsistent returns