Lucee returns blank pages

That’s not an “error” as you say. It’s an “INFO” message. It would appear a bot probably sent a badly formed cookie to your server. Nothing to worry about IMO.

Those interesting. Hard to say if they signal anything to be concerned about. You’d need to post to a Microsoft forum however, to get support on errors coming from the MS JDBC driver.

That’s certainly possible, but I can’t say I’ve ever seen that happen with Boncode myself. Usually when there is a connection issue, you get a Boncode error message or an IIS error message, not a white page.


This may be a silly question-- but have you checked the possibility that you actually just have a default error page that has no contents-- or an onError() method perhaps with a code path that outputs nothing? Can you tell from FR if the ALL requests to the server were returning a blank page during the incident, and were those requests also being logged in FusionReactor as hitting CF? What was their response code?

Hi!

Not a silly question at all. I have an onError in my application.cfc for the whole application. I catch all the errors. The code inside look like this :

  1. Send an email with cfmail with a dump of Except
  2. Inside a cftry, I collect more information, remove some for security reason, insert the error in the database, send another detailed email and redirect the user to a custom error page.
  3. If the cftry fail, I send another email with basic information.

During the incident, I received no email at all. I’m also assuming that if cfmail had failed in onError, users wouldn’t have gotten a blank page, unless the error page configured in Lucee is incorrect. It’s set at error-public.cfm.

I will remove the onError soon because Fusion Reactor cannot catch these errors. I need to find a way too to send me an email when an error occurred, but I didn’t find a way with the standard Fusion Reactor yet.

I did go in Metrics - Archived Metrics - Requests and selected the period during the incident. The response codes were 200, and several requests had 0 in the Bytes sent column, but not all. In this report, Bytes sent are the bytes sent by the browser to the server or the server to the browser?

My boss just informed me that the blank page incident happened again this weekend. He refreshed the page and sometimes he had the blank page, sometimes the expected content. It was random. He was forced to restart the server.

It is starting to be worrisome. I’ll see if we hire the services of a consultant to find the source of all this.

Apparently the second incident started around 9pm, at the same time I received this error message by email :

New request is not allowed to start because it should come with valid transaction descriptor.

lucee.runtime.exp.DatabaseException: New request is not allowed to start because it should come with valid transaction descriptor. at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:262) at com.microsoft.sqlserver.jdbc.TDSTokenHandler.onEOF(tdsparser.java:283) at com.microsoft.sqlserver.jdbc.TDSParser.parse(tdsparser.java:129) at com.microsoft.sqlserver.jdbc.TDSParser.parse(tdsparser.java:37) at com.microsoft.sqlserver.jdbc.TDSParser.parse(tdsparser.java:26) at com.microsoft.sqlserver.jdbc.SQLServerConnection$1ConnectionCommand.doExecute(SQLServerConnection.java:3248) at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:7375) at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:3206) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectionCommand(SQLServerConnection.java:3252) at com.microsoft.sqlserver.jdbc.SQLServerConnection.setAutoCommit(SQLServerConnection.java:3385) at lucee.runtime.db.DatasourceConnectionImpl.setAutoCommit(DatasourceConnectionImpl.java:409) at lucee.runtime.db.DatasourceManagerImpl.end(DatasourceManagerImpl.java:366) at lucee.runtime.db.DatasourceManagerImpl.end(DatasourceManagerImpl.java:345) at lucee.runtime.tag.Transaction.doFinally(Transaction.java:160) at scheduled_tasks450.ope_changements_prix_cfm$cf.call(/scheduled-tasks/ope_changements_prix.cfm:18) at lucee.runtime.PageContextImpl._doInclude(PageContextImpl.java:1034) at lucee.runtime.PageContextImpl._doInclude(PageContextImpl.java:926) at lucee.runtime.PageContextImpl.doInclude(PageContextImpl.java:907) at application_cfc$cf.udfCall(/application.cfc:289) at lucee.runtime.type.UDFImpl.implementation(UDFImpl.java:106) at lucee.runtime.type.UDFImpl._call(UDFImpl.java:344) at lucee.runtime.type.UDFImpl.call(UDFImpl.java:217) at lucee.runtime.ComponentImpl._call(ComponentImpl.java:684) at lucee.runtime.ComponentImpl._call(ComponentImpl.java:572) at lucee.runtime.ComponentImpl.call(ComponentImpl.java:1911) at lucee.runtime.listener.ModernAppListener.call(ModernAppListener.java:437) at lucee.runtime.listener.ModernAppListener._onRequest(ModernAppListener.java:216) at lucee.runtime.listener.MixedAppListener.onRequest(MixedAppListener.java:44) at lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2460) at lucee.runtime.PageContextImpl._execute(PageContextImpl.java:2450) at lucee.runtime.PageContextImpl.executeCFML(PageContextImpl.java:2421) at lucee.runtime.engine.Request.exe(Request.java:45) at lucee.runtime.engine.CFMLEngineImpl._service(CFMLEngineImpl.java:1179) at lucee.runtime.engine.CFMLEngineImpl.serviceCFML(CFMLEngineImpl.java:1125) at lucee.loader.engine.CFMLEngineWrapper.serviceCFML(CFMLEngineWrapper.java:102) at lucee.loader.servlet.CFMLServlet.service(CFMLServlet.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.intergral.fusionreactor.j2ee.filterchain.WrappedFilterChain.doFilter(WrappedFilterChain.java:134) at com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.doNext(FusionReactorRequestHandler.java:772) at com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.doHttpServletRequest(FusionReactorRequestHandler.java:344) at com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.doFusionRequest(FusionReactorRequestHandler.java:207) at com.intergral.fusionreactor.j2ee.filter.FusionReactorRequestHandler.handle(FusionReactorRequestHandler.java:809) at com.intergral.fusionreactor.j2ee.filter.FusionReactorCoreFilter.doFilter(FusionReactorCoreFilter.java:36) at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.intergral.fusionreactor.j2ee.filterchain.WrappedFilterChain.doFilter(WrappedFilterChain.java:71) at sun.reflect.GeneratedMethodAccessor37.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.intergral.fusionreactor.agent.filter.FusionReactorStaticFilter.doFilter(FusionReactorStaticFilter.java:54) at com.intergral.fusionreactor.agent.pointcuts.NewFilterChainPointCut$1.invoke(NewFilterChainPointCut.java:42) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:493) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342) at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:479) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748)

Either this error was caused by the blank pages incident, or the blank pages incident was caused by this error. But I tend to think that’s the first guess.

I don’t believe your understanding is correct. Firstly, the default error page configured in Lucee will ONLY kick in if you have no onError() method or if your onError() itself throws an error. Your onError() basically takes precedence over the server-level setting.

It sounds like you have no actual output in your onError(), which would result in a blank page. Unless you’re explicitly using writeOutput() or cfincluding a file, you’ll just see a white page. It’s up to you to output whatever you want the user to see when an error happens. My suggestion is to dump/abort the error after the cfmail for now until you figure out your SQL error. The fix may be simple, but I think you’re killing yourself by hiding the error messages right now.

Based on a precursory Google of the error message, it seems to be related to a bad state in a SQL connection, which due to connection pooling, may affect other requests trying to use the same connection. That may explain why a restart appears to “fix” the issue, since it’s just forcing a flush of your pooled DB connections. You’ll need to track down the bad query that is causing this and fix it.

1 Like

I understand this. Sorry sometimes I express myself badly. I do not speak native English too. What I wanted to say is that if I have an error in my code in the onError itself, like you said, that the error page configured in the Lucee server admin will kick in, and a possibility could have been that this error page in Lucee was not found or a blank page. And that’s what users see. But I suppose it’s something else.

It’s true. That could very well explain the blank pages. Except that I find it hard to understand why the cfmail in the onError wouldn’t run.

I was thinking of removing the onError in a few days, but I believe it would be better if I remove it ASAP. This would allow Fusion Reactor to catch the errors and it would confirm and eliminate the hypothesis that it comes from the onError which does not return anything. OR I could just output something simple too like “An error occurred” and see what’s happens in the next blank pages incident.

I will take a look at the error I received just before the incident. It’s a scheduled task that run every minute. In fact, there is another error with another scheduled task at the same minute :

The function [qry_changements_automatiques] has an invalid return value , [Cannot cast Object type [user defined function (qry_changements_automatiques)] to a value of type [query]]

As these two scheduled tasks have been running for weeks on Lucee and years on ACF, I would be quite surprised if these scheduled tasks were the source of the incident, but I will check anyway.

Thank you for your patience and your help. It’s very appreciated.

Tony, I’ll assume by “initial memory spool” you’re referring to the “initial memory pool” as indicated in the Tomcat Service configuration UI, and that you’re running Tomcat or Lucee as a Windows service. Even so, note that the maxmetaspacesize arg (if there) will be in the “java options” field of that service config tool, and note that there’s a slider if there are more args than you see in the box on the screen.

But assuming you still confirm there is none, again I only proposed that because of the seeming “blank pages” you were getting. I see that in comments here since your response to me here, there’s a possibility that the “blank” output may be due to an issue in your error handler. We’ll see how that sorts out.

One other thing, you said in reply to Brad later also that you found no out of memory errors in any Lucee or other logs. Just to clarify, you’d want to look for the phrase without spaces, outofmemory…and yes, if you did run out of metaspace, you should find an outofmemory error in some tomcat or Lucee log. (Some things depend on how you installed/implemented Lucee.)

Yes, I confirm there is nothing about maxmetaspacesize in the Java options in the Java tab of the Tomcat Service configuration and the value I’m talking about is the fields : Initial memory pool and Maximum memory pool.

As soon I’m back on foot (busy week and I’m sick over the top), I will remove the onError to let Fusion Reactor capture all the errors. I am still amazed that I have never had any problem with my onError in the past, even with Lucee, and that suddenly it would be problematic and that in addition the error email was no longer sent. But I have other motives for removing it, so I might as well do it anyway. What puzzles me though, is that if this is a problem with onError, it implies that there are random errors occurring in my application, and that I find strange. Everything had been stable for several weeks. Before I rack my brains too much and do scenarios, I have to remove this onError and I’ll be fixed.

I remember that I opened each log files and I scrolled everyline to find any word about memory. And the memory graphs looked normal.

Hi!

While preparing the ground for eliminating the onError in the application.cfc file, I performed tests on the development server. I had to properly configure the error pages in IIS, especially the 500. It was then that I noticed that in the Error pages module in IIS, for the server itself (not the website), the error 500 pointed to an empty htm file. It was then that I remembered that last summer, while preparing the migration from ACF to Lucee, I had started working on these error pages to do tests and hide from users as much detail as possible concerning the errors. I then tested an empty html page and was called to work on something else. Then several months later, we had to urgently migrate our ACF application to Lucee which was not completely ready. So we copied this server to make a production one, but obviously in a hurry, I didn’t think of rechecking this part. And since error catching worked well with onError, I didn’t have any further questions.

So my plan is to restore the default 500 error pages in IIS, remove the onError in application.cfc, and let Fusion Reactor catch the errors.

I suspect that for some reason IIS was throwing a 500 error, caused by Lucee or not, and the default 500 html page for the server was showing … html page that is … blank. That would explain everything from the lack of execution of cfmail in onError to the blank page, and why I seem to be the only one with this kind of unique problem.

It would be embarrassing if that was the blank page problem, but I would be reassured at the same time. It will still be necessary to find out what causes the 500 errors, but still … I will keep you informed.

2 Likes

Hi,

I decided to take the plunge tonight. I created a custom html page for the IIS error 500, both for the server level and the website level, and removed onError from the application.cfc file. Behavior in the app is the same as it was before, except I no longer get email with error details, but at least I can see the error details in Fusion Reactor. I spoke with a Fusion Reactor rep to suggest they add an email notification feature when X number of errors occur in a T time lapse, and he will bring the idea to the team.

Very happy with this change and it will help me see more clearly when random errors occur like lately.

By the way, good call bdw429s about the default error page. When you told me that, I hadn’t thought of looking at the 500 error page set at the IIS root level. The error page for the website in IIS was not empty, but the one in the IIS root level yes. It was quite by chance that I came across it, but your suspicions were founded. It wasn’t a silly question.

1 Like

Glad you finally have resolved things.

As for your desire for FR, I’ll note that for those using FR Cloud (available free with FR Ultimate and Enterprise editions) at least, it can already be configured to alert you by email when the rate of errors exceeds a given value over a given time interval. That’s one of about 60 different metrics that FR Cloud offers in its alert check options.

Perhaps your interest is in the traditional FR (on-prem) alerting, which has only 4 things it can alert on. They’ve long been reluctant to add more, as the FR agent runs within the jvm along with Lucee or CF. But perhaps you may get them to add this one. :slight_smile: The 4th one (for cpu) was added just recently, in fact (the first new alert in many years). They are indeed responsive, and responsible about it.

It’s good to know! Thank you for the info.

Hi,

It’s still preliminary and I haven’t been able to personally witness today’s new blank page incident, but it may well be that the issue is neither with Lucee nor with our web server. It could be from a script like Google Tag Manager or one from Google. During today’s blank page incident, I was told that the browser was loading and waiting for a script from a Google domain name. It is not impossible that a Google script, which is loaded in the head of the page, is having trouble at X time and causing blank pages to load. This is not consistent with restarting Lucee which seemed to resolve the issue (we didn’t restart Lucee today as it happened just with one user), but it would be consistent with the fact that no error message was generated on the server side nor any trace in the logs. And that if the user reloaded the page, the content would come back. We will be keeping an eye on this. I also informed my coworker to notify me when this happens so that I can check what the browser is loading and not loading.

As this is a random situation that happens in a very isolated way, it is difficult to reproduce the problem and / or to always be present when it occurs. So we have to eliminate hypothesis by hypothesis.

Hi,

The blank page syndrome just happened on our development server. I called up a page with my browser and it was not responding at all. I waited a bit and opened two more tabs to two more pages, and got two blank pages. I cannot right click on these pages to see more details like the source code, and if I save the file as a text file it is completely empty. And if I save it in html, I only have this but it is probably Firefox that adds it.

<html><head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8"></head><body></body></html>

I haven’t seen anything about loading a script from Google, so I don’t believe this assumption anymore.

I don’t have Fusion Reactor on our dev server, gonna look to take the Developer license (edit : Dev license activated. I will be ready for the next time).

I added Bytes sent and Bytes received in the IIS logs too. Next time, I will be able to see if it’s IIS that send empty files.

@TonyMonast this is really, really strange, but interesting stuff to read (sorry for saying that, but it’s interresting). I hope very much, that you’ll find out the cause of your issue soon. This is just a bunch of ideas that come to my mind about what would be my next steps to check…

  1. You’ve said that the pages are probably created by Firefox. I would make sure that this is the case by doing an direct “curl” to the blank pages URL? Is the response really empty? How does the complete response payload look like? Are any IIS or Tomcat server headers present?

  2. You’ve said your using IIS, but I don’t see you mentioning anything about looking into MS event viewer. Sometimes IIS logs interresting stuff to the event logger, especially on errors. Did you take o look into that? Any specific errors and descriptions there?

  3. By default, IIS sends error information to remote IPs differently than to its own local IP. If you have some kind of unusual settings e g. an IIS custom error settings on IIS, IIS could try setting an error depending on the 50x.x error code to a static, but unavailable custom template. if you retrieve the URL from the servers local browser, you may be able to see IIS dynamic error content page with detailed information.

  4. Are you using boncode as a connector? Did you try using it with debugging enabled? What happens there?

It is indeed interesting, but quite unpleasant. Fortunately, that doesn’t happen often. I wish I had only problems with my code, but the situation is a bit beyond me, just like my other Access denied problem when I update files. The white pages situation is virtually impossible to replicate. It’s random and it doesn’t last. Sometimes we refresh the page and the problem is gone, sometimes it does it one hit on two, sometimes we have to restart Lucee and other times it goes by itself without restarting anything. I would be rather surprised if these were several different issues.

On the development server, I still had an onError in the application.cfc with a dump of the error and a cfabort. I removed it while waiting to see if the problem will occur again.

<cffunction name="onError">
        <cfargument name="Exception" required=true />
        <cfargument type="String" name="EventName" required=true />
        <cfdump var="#Arguments.Exception#">
        <cfabort>
</cffunction>

The page loaded empty in Firefox. When you save a webpage in .txt format in Firefox, you get all the source code in a text file. When I did it with these 2 blank pages, the text file was empty (0 Ko). If I reload the page with Firefox, the content come back, so I can’t test it with cUrl. cUrl will probably return the content.

Gonna take a look at that.

The Error Pages module in IIS have all the default pages defined. I just modified the 500.htm page with basic html, nothing fancy.

I noticed that I only have en-US folder in t:\inetpub\custerr, but if the browser send a header for the language that don’t exists, IIS will fallback to the default one.

If the browser sends a request for an non-existing resource and the “Accept-Language” header has the value of “en-us,” the file that gets returned will be c:\inetpub\custerr\en-us\404.htm.

IIS will always fall back to the system language if the directory […] does not exist.

Yes we are using Boncode as a connector. I can enable the debugging on the dev server, but I suppose I should not enable it in the prod server? The problem too is I can’t reproduce the blank page like I want. It’s 100% random. And if it’s happens, sometime I just reload the page and the problem is gone. Gonna take a look at that.

Thank you for your help.

For now I just found a warning happening everyday :

The directory specified for caching compressed content t:\inetpub\temp\IIS Temporary Compressed Files\mydomainhere is invalid. Static compression is being disabled.

I changed the permissions/added users on this folder and I will follow it if it’s solved this warning, but It’s not related to the blank page because I don’t compress dynamic files, just static files.

Hi,

The blank page incident happened again this weekend at 12/19/2021 2:02:00 AM on our production server, There is no onError in the application.cfc and all errors pages in IIS are the default one. Our probe, which is making hits every minute to monitor the response of certain pages in our application, started returning empty pages. A restart of the web server was required and everything was back to normal. This morning, I looked at the errors in Lucee’s Log Viewer and there were a lot of errors that started around this period. The first error is this one, but happened every 5 seconds after that until the reboot at 02:36:37 AM, see the attachments.

application.logERROR 01:55:02, 19 déc, 2021Thread-44
"was not able to stop controller thread running for 75700157ms;java.lang.Throwable;java.lang.Throwable

    /application.cfc:260

at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at com.microsoft.sqlserver.jdbc.TDSChannel.read(IOBuffer.java:2054)
at com.microsoft.sqlserver.jdbc.TDSReader.readPacket(IOBuffer.java:6643)
at com.microsoft.sqlserver.jdbc.TDSReader.nextPacket(IOBuffer.java:6546)
at com.microsoft.sqlserver.jdbc.TDSReader.ensurePayload(IOBuffer.java:6524)
at com.microsoft.sqlserver.jdbc.TDSReader.peekTokenType(IOBuffer.java:6731)
at com.microsoft.sqlserver.jdbc.TDSParser.parse(tdsparser.java:61)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1628)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.processResults(SQLServerStatement.java:1302)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.processBatch(SQLServerStatement.java:1293)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.processExecuteResults(SQLServerStatement.java:1286)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement$PrepStmtExecCmd.processResponse(SQLServerPreparedStatement.java:530)
at com.microsoft.sqlserver.jdbc.TDSCommand.close(IOBuffer.java:7445)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.discardLastExecutionResults(SQLServerStatement.java:142)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.closeInternal(SQLServerStatement.java:653)
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.closeInternal(SQLServerPreparedStatement.java:328)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.$fr$close(SQLServerStatement.java:668)
at com.microsoft.sqlserver.jdbc.SQLServerStatement.close(SQLServerStatement.java)
at lucee.commons.db.DBUtil.closeEL(DBUtil.java:71)
at lucee.runtime.type.QueryImpl.execute(QueryImpl.java:331)
at lucee.runtime.type.QueryImpl.<init>(QueryImpl.java:235)
at lucee.runtime.tag.Query.executeDatasoure(Query.java:1134)
at lucee.runtime.tag.Query._doEndTag(Query.java:699)
at lucee.runtime.tag.Query.doEndTag(Query.java:565)
at cfc.myproject.client.transactions_paiements_cfc585$cf.udfCall(/cfc/myproject/client/transactions-paiements.cfc:269)
at lucee.runtime.type.UDFImpl.implementation(UDFImpl.java:106)
at lucee.runtime.type.UDFImpl._call(UDFImpl.java:344)
at lucee.runtime.type.UDFImpl.callWithNamedValues(UDFImpl.java:207)
at lucee.runtime.ComponentImpl._call(ComponentImpl.java:685)
at lucee.runtime.ComponentImpl._call(ComponentImpl.java:572)
at lucee.runtime.ComponentImpl.callWithNamedValues(ComponentImpl.java:1925)
at lucee.runtime.tag.Invoke.doComponent(Invoke.java:209)
at lucee.runtime.tag.Invoke.doEndTag(Invoke.java:186)
at application_cfc$cf.udfCall(/application.cfc:260)
at lucee.runtime.type.UDFImpl.implementation(UDFImpl.java:106)
at lucee.runtime.type.UDFImpl._call(UDFImpl.java:344)
at lucee.runtime.type.UDFImpl.call(UDFImpl.java:217)
at lucee.runtime.ComponentImpl._call(ComponentImpl.java:684)
at lucee.runtime.ComponentImpl._call(ComponentImpl.java:572)
at lucee.runtime.ComponentImpl.call(ComponentImpl.java:1911)
at lucee.runtime.listener.ModernAppListener.call(ModernAppListener.java:437)
at lucee.runtime.listener.ModernAppListener.onSessionEnd(ModernAppListener.java:362)
at lucee.runtime.type.scope.ScopeContext.clearUnusedMemoryScope(ScopeContext.java:961)
at lucee.runtime.type.scope.ScopeContext.clearUnused(ScopeContext.java:825)
at lucee.runtime.engine.Controler.control(Controler.java:346)
at lucee.runtime.engine.Controler.control(Controler.java:244)
at lucee.runtime.engine.Controler.access$000(Controler.java:58)
at lucee.runtime.engine.Controler$ControlerThread.run(Controler.java:113)

It’s still look related to the “OnSessionEnd” in application.cfc and my method in transactions_paiements.cfc. Either the blank pages problem is causing these errors, or these errors are causing the blank pages.

Lucee log viewer plugin (Partial logs, it’s started at 01:55:02 and the same error each 5 seconds)

Probe
The log of the probe show hits with 0 bytes received. But it’s not every hits with this problem. It’s random when the blank pages incident start.

I’m trying to see where it can come from…

What does eventviewer show?
Do you have a lot of 4227 error ids that correspond to your blank pages?

Hi!

Nothing in EventViewer about this incident. Where the 4227 number come from?

It would be in your system log and 4227 refers to port exhaustion.
The other id to look for 4231

I see errors like this and in most cases is a box who is trying to do too many network operations or clients are connecting and disconnecting from it at a rate that is faster than the default 3 minute timeout.

the other issue I would look at is your NIC (Virtual or otherwise) talking to the SQL server on another box across a populated network and not segmented by VLAN?
Do you have Jumbo frames enabled on both devices?