Similar to https://lucee.daemonite.io/t/lucee-returns-blank-pages/9273/48, running into blank pages randomly, although when it happens, it stays down for a given user until a Tomcat restart. Others may or may not see blank pages.*
*Report in that pages were blank and come back for some users, but not all. Still working out specifics.
IIS on Windows Server 2019, Lucee 5.3.10.97 standard install, MSSQL on a different box, Java 11.0.17, whichever Tomcat comes with said Lucee version, Boncode as connector to IIS.
–After a 1 to 3 day period, server starts returning blank 0 byte pages.
–Status is 200, and FusionReactor looks normal; requests are coming in and taking the appropriate amount of time to complete.
–the CMS we have is responding; the proper site/redirect occurs in the browser address bar based on binding order, and what I mentioned above; large pages take longer to ‘load’ both in FR and the browser load time matches what you experience if the pages were showing.
–a simple test.cfm page outside of the CMS also comes up blank, as well as Lucee admin using the IP/domain path (yes will make sure to block this if this box makes it to production)
–static html and assets are being served
–localhost Lucee admin is loading
–server CPU/RAM is good
–memory looks good within Lucee
–a restart of Tomcat brings everything back up
Most definitely a beginner in looking through logs, but nothing obvious stands out as errors yet, just normal responses leading up to the issue, although noticed a number of 98 byte responses leading up to the issue, which I’m digging into today. With the status being 200 and code running, no big red signs unfortunately.
Terry, is this with the goal of raising or lowering it? Or setting it if not set? And if the latter, do you think imposing a limit would stop blank pages?
My experience (with ACF) is that blank pages could happen when Adobe used to set a maxmetaspace and that limit was hit. Thankfully, they no longer set it from cf2021 and above–by default, at least. And so there is no fixed limit. (Java’s behavior since Java 8 introduced the setting, to replace the old maxpermsize).
Tomcat does not set it by default, so for Lucee most should find it’s not set. @beanboy, can you confirm what you have?
I have (much) more on the metaspace topic in a post here:
Or an abbreviated version here:
To beanboy’s original problem, he and I have done some investigation of his issue. We’ve considered more than he’s shared here, and I’ve also proposed some new things to consider. He’s in an info gathering mode, willing to hear any ideas. Rather than regurgitate all we’ve considered, I’ll pop in here to offer clarifications where i think it may help, as in this case.
My goal is to set a baseline and troubleshoot accordingly. Yes, the easy thing is to reboot the server, but that is a band aid rather than correcting the issue.
The “do not set” has already created result of no error. Now lets start placing constraints around the service to see exactly where it breaks if any in lucee.
When the issue does occur, it would be worth running a netsta -aon as well as viewing everything running on the server. $processes = Get-Process -Name w3wp
foreach ($process in $processes) { f:\procdump.exe -ma $process.ID }
Hi,
I will answer the question you asked in my topic, to know if I had found the source of the problem. I don’t want to send you in the wrong direction though.
I haven’t experienced any blank pages for several months. I cannot confirm or deny that it is due to the following changes:
- Adjusted error pages defined in IIS
- Removed the onError event in my application.cfc file. I now exclusively use FusionReactor
- Removed onSessionEnd event in my application.cfc file which made SQL queries on several databases.
It’s since the third point that I haven’t experienced any more white pages, except once, but that was while browsing Google, so nothing to do with our server or our application.
I hope you find where it comes from.
Thanks @TonyMonast for your reply. Also have isolated the issue as to what, not so much the why, yet. But will share shortly so that others may benefit in the future.