Function Takes More Than 4 Minutes To Return JSON

dev support
1

I have an unbelievably odd bug. I have a function that returns a long JSON string for an HTML page editor. A few pages are displaying an issue where the JSON string is generated fine, but it takes over 4 minutes to actually return it. The function basically gets the JSON string from the SQL DB and returns it. I put a dump right before my cfreturn and the dump is generated as quick as would be expected but the cfreturn takes over four minutes.

Now, the kicker. If I remove one character from the JSON, any character, it is returned fine. If I add any character, the JSON string is returned fine. There are no errors thrown, it works the same in Chrome or Safari, the Chrome Web Inspector Network tab says “Pending” for status. The request shows as complete in 40ms or so in FusionReactor even when it takes 4 minutes to display in the browser. No console errors in either browser. Can reproduce in Dev using the same JSON from Prod. When the JSON does finally render, I get the “Ensure that Tomcat is running on given host…” error message at first and then the rest of the JSON.

Other pages with different character lengths are displaying the same issue. I checked to make sure the character count wasn’t evenly divisible by 666 to make sure it wasn’t a Halloween developer prank. It’s not.

Any ideas what’s going on?

OS : Windows Server 2016 (10.0) 64bit
Java Version : 11.0.22 (Eclipse Adoptium) 64bit
Tomcat Version : Apache Tomcat/9.0.86
Lucee Version : Lucee 5.4.5.23

2

can you show some code with an example, so we can reproduce it?

3

Dumps of LARGE JSON objects are typically demanding.
Your mention of removing any character suggests a formatting incompatibility.
But without seeing the CODE… can’t help much…

4

I’ve oddly enough had a similar issue at some point, although it was with regular HTML.

Is gzip enabled on the webserver? If so try disabling it and see if the issue persist.

5

Thanks for the replies all. The code really is this simple, but hopefully you’ll find some useful information in here. The JSON is stored in the DB. I left the dump in because the dump shows that the function has completed except for the cfreturn.

There is a curly single quote in one of the JSON strings. We do have another JSON string with a number of curly quotes in it that works fine. Thinking about removing those when entered into the editor.


  <cffunction name="pagesJSON" access="remote" output="false" returntype="string" returnformat="JSON">
    <cfargument name="argPageID" type="numeric" required="true" default="">
    <cfquery name="local.qPage" datasource="#this.dsn#">
			SELECT TOP 1 *
			FROM pages
			WHERE ID = <cfqueryparam cfsqltype="cf_sql_integer" value="#arguments.argPageID#">
		</cfquery>
    <cfscript>
      local.pageJSON = {};
      local.pageJSON = local.qPage.pageJSON;
    </cfscript>
    <cfdump var="#local.pageJSON#" output="C:\myDump.html" format="html">
    <cfreturn local.pageJSON>
  </cffunction>
6

If you’re referring to the setting in Lucee, Settings > Output > Compression, no, we do not have that enabled.

7

I mean from the webserver itself, depending on what you are using that will vary.

If you want to confirm it’s even enabled before digging further, you will see the Header in the response using the Developer Tools in your browser as below:

image
image777Ă—319 15.5 KB

I see you are in Windows so perhaps in IIS if it’s installed and proxying to Tomcat, but I don’t think dynamic compression is on by default.

I haven’t used Tomcat in a few years, but it seems to be set with an attribute on the http connector (Apache Tomcat 9 Configuration Reference (9.0.91) - The HTTP Connector)

On commandbox with undertow it’s a simple setting - GZip Compression | CommandBox : CLI, Package Manager, REPL & More

8

Thanks for the follow up, we aren’t gzipping it anywhere.

9

open up the file that runs the code in notepadd++ or simular text editor

click view
show all characters.

You more than likely have an extra space someplace, either in your code output, or the output itself.

10

Thanks Terry. Checked and there are no extra spaces or characters in the code.

More info about the issue:

  • The code doing the processing has been in place for 7 years.
  • A complete install of Lucee 5.4.5.23 was made on May 22.
  • The issue was first reported on July 2.
  • It doesn’t affect all pages.
11

I have a question… what are you dumping the html for? is it possible that it’s causing some extra overhead?

12

That was just to check and see if the problem was inside the function or something external. It still takes about four minutes to process whether the dump is there or not.

13

Does the same happen when you access the Lucee port 8888 directly from the same machine(locally)? Just to rule any networking/firewall/webserver/connector stuff out.

14

Good call. Yeah, it loads fine there.

1 Like
15

have you configured Tomcat and Boncode to set the packetSize to its maximum value?

4 Likes
16

Andreas, you’re a lifesaver!!! That seems to have fixed it. Need to do some more testing but the original JSON that had issues is loading fine now.

4 Likes
17

Are there any potential side effects of making that change?

18

In my experience, none whatsoever.

2 Likes