Lucee is sometimes logging to the wrong site

It was a fresh install on the new servers. Yes Tomcat was upgraded, the previous version was whatever was bundled with Lucee 5.3.8.201.

And I was wrong about there being little traffic on the old version. We did have these servers in production on 5.3.8 (unsure of the minor version). The issue only started happening when we switched to 5.3.9. (Tomcat was already upgraded before we switched to 5.3.9).

is it possible to try a 5.3.8.201 install upgraded in place to 5.3.9 (i.e. via the admin?) i.e. with the older version of tomcat?

In Server.xml

try updating this:

maxContexts="200"
timeBetweenContexts="2000"

to this:

maxContexts="2000"
timeBetweenContexts="1000"

clear the web-inf folder(s)
restart your lucee instance

I believe those parameters apply to mod_cfml, which we are not using.

You are correct that is for the mod_cfml implementation of lucee.

I need more coffee :slight_smile:

If apache is set to load balance or proxy pass, if so

I believe you are worker sharing, which the fix would be to look at httpd.conf and set shortest matching url first

https://httpd.apache.org/docs/2.4/mod/mod_proxy.html

is it possible to try a 5.3.8.201 install upgraded in place to 5.3.9 (i.e. via the admin?) i.e. with the older version of tomcat?

I’ve given this some thought but haven’t come up with a reasonably easy way to do this, since they are production servers.

you could set this up locally, just use site1.localhost, site2.localhost which all resolve to 127.0.0.1

JMeter can then access these .localhost sites so you can do some local testing, if you add host entries

here’s a sample jmeter to get you started

lucee-localhost.jmx (14.0 KB)

This happens using Lucee Express 5.3.9.166. It does not happen using 5.3.8.206.

Reproduction steps:

  1. Visit site1 (it will spin for ~10 seconds until it logs the error)
  • Logs to site1/WEB-INF/lucee/logs/application.log (expected)
  1. Visit site 2 (it will spin for a second until it logs the error)
  • Logs to site2/WEB-INF/lucee/logs/application.log (expected)
  1. Visit site1
  • Logs to site2/WEB-INF/lucee/logs/application.log (UNEXPECTED)
  1. Visit site2
  • Logs to site2/WEB-INF/lucee/logs/application.log (expected)

Subsequent errors on site1 are logged to site2. See log output at the end.

Configuration:
server.xml - added at end of file after default </Host>:

		<Host name="site1.localhost" appBase="webapps">
			<Context path="" docBase="C:\tmp\site1" />
		</Host>
		<Host name="site2.localhost" appBase="webapps">
			<Context path="" docBase="C:\tmp\site2" />
		</Host>

site1/Application.cfc

component output="false" {
	THIS.name = "site1";
	this.tag.log.file="application"; // leads to logging on wrong site
	this.tag.log.application="true";

	public function onError(exception, event) {
		writeLog(type="Information", text="site1 onError fired: Message:#exception.Message#");
		writeOutput("Doh!");
	}
}

site1/index.cfm

<cflog text="site1 hit #now()#">
<cfset foo = bar />
<cfoutput>
site1 hit #now()#
</cfoutput>

site2/Application.cfc

component output="false" {
	THIS.name = "site2";
	this.tag.log.file="application"; // leads to logging on wrong site
	this.tag.log.application="true";

	public function onError(exception, event) {
		writeLog(type="Information", text="site2 onError fired: Message:#exception.Message#");
		writeOutput("Doh!");
	}
}

site2/index.cfm

<cflog text="site2 hit #now()#">
<cfset foo = bar />
<cfoutput>
site2 hit #now()#
</cfoutput>

site1 application.log

"Severity","ThreadID","Date","Time","Application","Message"
"INFO","http-nio-8888-exec-1","11/08/2022","14:49:07","site1","site1 hit {ts '2022-11-08 14:48:47'}"
"INFO","http-nio-8888-exec-1","11/08/2022","14:49:17","site1","site1 onError fired: Message:variable [BAR] doesn't exist"

site2 application.log

"Severity","ThreadID","Date","Time","Application","Message"
"INFO","http-nio-8888-exec-2","11/08/2022","14:49:42","site2","site2 hit {ts '2022-11-08 14:49:20'}"
"INFO","http-nio-8888-exec-2","11/08/2022","14:49:42","site2","site2 onError fired: Message:variable [BAR] doesn't exist"
"INFO","http-nio-8888-exec-3","11/08/2022","14:49:46","site1","site1 hit {ts '2022-11-08 14:49:46'}"
"INFO","http-nio-8888-exec-3","11/08/2022","14:49:46","site1","site1 onError fired: Message:variable [BAR] doesn't exist"
"INFO","http-nio-8888-exec-4","11/08/2022","14:49:49","site2","site2 hit {ts '2022-11-08 14:49:49'}"
"INFO","http-nio-8888-exec-4","11/08/2022","14:49:49","site2","site2 onError fired: Message:variable [BAR] doesn't exist"
"INFO","http-nio-8888-exec-5","11/08/2022","14:50:34","site1","site1 hit {ts '2022-11-08 14:50:34'}"
"INFO","http-nio-8888-exec-5","11/08/2022","14:50:34","site1","site1 onError fired: Message:variable [BAR] doesn't exist"
4 Likes

great example, thanks, we’ll investigate [LDEV-4263] - Lucee

1 Like

@Phillyun cflog file attribute was deprecated. So can you please use this.tag.log.log=“application” instead of this.tag.log.file=“application”

1 Like

Will give it a try! Thanks

I read the docs twice … I need more coffee and less copy - apparently.
blinks in confused manner
:neutral_face:

2 Likes

good catch

2 Likes

please try 5.3.10.90, as per [LDEV-4263] - Lucee

I appreciate the link to LDEV-4263 … will re-check as time allows.

We’re sitting at ~400 instances / 100 files that need updating in our code to get rid of this misbehaving file attribute including 3rd party paid CFML.

the fix defaults back to named logs. if you can confirm it, we can backport to 5.3.9 i reckon

I cannot reproduce this (logging to wrong site) issue in
5.3.10.79-RC or 5.3.10.89-snapshot (so have not tried the 5.3.10.90-snapshot).

  • I do not see the logging issue in this .90-snapshot version.

@Zackster - I’ve reviewed the change / tried in our code and do want to point out the following observations:

  1. My new understanding is: passing log="application" is preferred over file="application" (but 5.3.10.90 handles file if you used it).
    Tracking the thread/history - this is because there’s caching/performance for log files specifically defined IN THE ADMIN.
  2. Code that uses a custom log file - MUST use the “file” attribute.
    I think this change should be reversed: https://lucee.daemonite.io/t/lucee-is-sometimes-logging-to-the-wrong-site/11364/18?u=phillyun

edit: and perhaps another example given for using log="application"

Example: file="site1" (will create a site1.log).
An attempt to pass log="site1" throws an error. Therefore the file attribute is (apparently) not deprecated (or maybe should not be deprecated? It would also introduce an ACF incompatibility if fully deprecated).

Lucee 5.3.10.90-SNAPSHOT Error (application)
Message The attribute log [site1log] does not exist, only the following log names are available: [application, datasource, deploy, exception, gateway, mail, mapping, memory, orm, remoteclient, requesttimeout, rest, scheduler, scope, search, thread, trace].
Stacktrace The Error Occurred in
/writeLog.cfm: line 17
called from C:\tmp\site1\Application.cfc: line 7
Java Stacktrace lucee.runtime.exp.ApplicationException: The attribute log [site1log] does not exist, only the following log names are available: [application, datasource, deploy, exception, gateway, mail, mapping, memory, orm, remoteclient, requesttimeout, rest, scheduler, scope, search, thread, trace].
at lucee.runtime.tag.Log.doStartTag(Log.java:231)
at writelog_cfm$cf.udfCall(/writeLog.cfm:17)
at lucee.runtime.type.UDFImpl.implementation(UDFImpl.java:112)
at lucee.runtime.type.UDFImpl._call(UDFImpl.java:350)
at lucee.runtime.type.UDFImpl.callWithNamedValues(UDFImpl.java:213)
at lucee.runtime.functions.system.CFFunction.call(CFFunction.java:109)
at application_cfc$cf$4.udfCall(/Application.cfc:7)
at lucee.runtime.type.UDFImpl.implementation(UDFImpl.java:112)
at lucee.runtime.type.UDFImpl._call(UDFImpl.java:350)
at lucee.runtime.type.UDFImpl.call(UDFImpl.java:223)
at lucee.runtime.ComponentImpl._call(ComponentImpl.java:696)
at lucee.runtime.ComponentImpl._call(ComponentImpl.java:584)
at lucee.runtime.ComponentImpl.call(ComponentImpl.java:1931)
at lucee.runtime.listener.ModernAppListener.call(ModernAppListener.java:444)
at lucee.runtime.listener.ModernAppListener.onError(ModernAppListener.java:432)
at lucee.runtime.listener.MixedAppListener.onError(MixedAppListener.java:138)
at lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2521)
at lucee.runtime.PageContextImpl._execute(PageContextImpl.java:2478)
at lucee.runtime.PageContextImpl.executeCFML(PageContextImpl.java:2449)
at lucee.runtime.engine.Request.exe(Request.java:45)
at lucee.runtime.engine.CFMLEngineImpl._service(CFMLEngineImpl.java:1216)
at lucee.runtime.engine.CFMLEngineImpl.serviceCFML(CFMLEngineImpl.java:1162)
at lucee.loader.engine.CFMLEngineWrapper.serviceCFML(CFMLEngineWrapper.java:97)
at lucee.loader.servlet.CFMLServlet.service(CFMLServlet.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
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:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:770)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415)
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:750)

that’s just a typo

we have backported the fix to 5.3.9.170

1 Like

Will give the latest 5.3.9.170 a go. Thank you for the quick backport work.

Re - typo

@Zackster It was a typo in my message, not the functionality. A custom log that isn’t defined in the admin cannot use the log attribute. The main point of my message still applies (log="customlog" will throw an error).