Access denied and cache?

Hi,

I had to make a fast correction on a lucee web application in production and I turned off the cache. Then it generate many errors like that on differents cfm pages :

Access is denied
StackTrace	
string	lucee.runtime.exp.NativeException: Access is denied 
at java.io.WinNTFileSystem.createFileExclusively(Native Method) 
at java.io.File.createNewFile(File.java:1012) 
at lucee.commons.io.res.type.file.FileResource.getOutputStream(FileResource.java:261) 
at lucee.commons.io.res.type.file.FileResource.getOutputStream(FileResource.java:254) 
at lucee.commons.io.IOUtil.copy(IOUtil.java:171) 
at lucee.runtime.compiler.CFMLCompilerImpl._compile(CFMLCompilerImpl.java:154) 
at lucee.runtime.compiler.CFMLCompilerImpl.compile(CFMLCompilerImpl.java:76) 
at lucee.runtime.PageSourceImpl._compile(PageSourceImpl.java:446) 
at lucee.runtime.PageSourceImpl.compile(PageSourceImpl.java:413) 
at lucee.runtime.PageSourceImpl.loadPhysical(PageSourceImpl.java:346) 
at lucee.runtime.PageSourceImpl.loadPageThrowTemplateException(PageSourceImpl.java:237) 
at lucee.runtime.component.ComponentLoader._search(ComponentLoader.java:307) 
at lucee.runtime.component.ComponentLoader._search(ComponentLoader.java:117) 
at lucee.runtime.component.ComponentLoader.searchComponent(ComponentLoader.java:79) 
at lucee.runtime.PageContextImpl.loadComponent(PageContextImpl.java:3247) 
at lucee.runtime.tag.Invoke.doComponent(Invoke.java:206) 
at lucee.runtime.tag.Invoke.doEndTag(Invoke.java:186) 
at scheduled_tasks450.ope_changements_prix_cfm$cf.call(/scheduled-tasks/ope_changements_prix.cfm:17) 
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:288) 
at 

I tried to load the pages that generated the error, and they were blank. My heart has stopped beating.

I had to restart TomCat/Lucee to resolve the issue. I already have the users defined in the conf/tomcat-users.xml as mentioned in another topic, even it’s not exactly the same error and situation.

Please help me! Is it because I turned off the cache while something hit the pages?

I disable the cache with a button in a cfm page. I use createObject('component','Administrator') and the updatePerformanceSettings(inspectTemplate = "never") or updatePerformanceSettings(inspectTemplate = "always") method. Maybe it’s the reason? Maybe I should use the administrator page (cfadmin) instead?

OS: Windows Server 2016 (10.0) 64bit
Java Version: 1.8.0_181 (Oracle Corporation) 64bit
Tomcat Version: Apache Tomcat/8.5.33
Lucee Version: Lucee 5.3.8.206

Is there a reason you’d set inspect templates to never? The error itself looks like a file system permissions error. Check the permissions on the Lucee web context directory.

Well, maybe never is overkill. I just want to make sure Lucee load the new code when I update the app. I’m used to Adobe Coldfusion with Trusted cache On and Off

What is exactly the Lucee web context directory? Is it the directory with this path? T:\inetpub\wwwroot\myappname\WEB-INF\lucee?

Thank you

Ok I just saw the web contexts in the cfadmin. It’s a path like : T:\inetpub\wwwroot\myapp. Do I need to look at the SYSTEM user rights on this directory? If so, it’s full rights.

The “once” setting checks once per request, which is fine. The web context folder is the web-inf/lucee folder.

Users SYSTEM and Creator owner has full control on T:\inetpub\wwwroot\myappname\WEB-INF\lucee directory.

This has happened twice since I launched my web application today. It seems to me that the first time, I also played with the Never and Always cache to change code in CFM and/or CFC pages.

Now I don’t dare to update anything in broad daylight.

I just noticed I didn’t anwer your question well. I set Inspect templates to Never for the Best performance like the cfadmin says :

Never (Best Performance)
When checked, any requested files found to currently reside in the template cache will not be inspected for potential updates. For sites where templates are not updated during the life of the server, this minimizes file system overhead.

Most of the time, my templates don’t change. I rarely update my cfm and cfc and when I do, I turn off the cache, hit the cfm or the cfc to test the new code, then turn on the cache.

I can’t say I’ve ever seen this before. Whatever is happening appears to be unique to your server. Can you provide the full stack trace? Often times there is a “CAUSED BY” section at the bottom of Java stacks that contains the root cause.

That code is simply this

IOUtil.copy(new ByteArrayInputStream(result.barr), classFile, true);

which copies the bytes from the class in memory into the file on disk. It appears to just be a straight up “access is denied” error coming from Java itself when Lucee tries to write the file.

Also, you are on the latest version of Lucee. Have you always seen this message, or did it specifically begin after a given upgrade of Lucee. That would be important information to determine if it’s a regression in a recent version or just something funky on your server.

Hi,

First, thank you for your time!

I worked for over 50 days to make the code of an Adobe Coldfusion 8 application compatible with Lucee on the version just before this one. I had never seen this error, but it must be said that during this development, I was not using the cache much and when I was turning it on and off, and off and on, nobody except me was using the Lucee app.

I temporarily no longer have access to a development server to try to reproduce the problem, but here is the dump I got. I don’t have access to the full stacktrace.

lucee.runtime.exp.NativeException: Access is denied at java.io.WinNTFileSystem.createFileExclusively(Native Method) at java.io.File.createNewFile(File.java:1012) at lucee.commons.io.res.type.file.FileResource.getOutputStream(FileResource.java:261) at lucee.commons.io.res.type.file.FileResource.getOutputStream(FileResource.java:254) at lucee.commons.io.IOUtil.copy(IOUtil.java:171) at lucee.runtime.compiler.CFMLCompilerImpl._compile(CFMLCompilerImpl.java:154) at lucee.runtime.compiler.CFMLCompilerImpl.compile(CFMLCompilerImpl.java:76) at lucee.runtime.PageSourceImpl._compile(PageSourceImpl.java:446) at lucee.runtime.PageSourceImpl.compile(PageSourceImpl.java:413) at lucee.runtime.PageSourceImpl.loadPhysical(PageSourceImpl.java:346) at lucee.runtime.PageSourceImpl.loadPageThrowTemplateException(PageSourceImpl.java:237) at lucee.runtime.component.ComponentLoader._search(ComponentLoader.java:307) at lucee.runtime.component.ComponentLoader._search(ComponentLoader.java:117) at lucee.runtime.component.ComponentLoader.searchComponent(ComponentLoader.java:79) at lucee.runtime.PageContextImpl.loadComponent(PageContextImpl.java:3247) at lucee.runtime.tag.Invoke.doComponent(Invoke.java:206) at lucee.runtime.tag.Invoke.doEndTag(Invoke.java:186) at application_cfc$cf.udfCall(/application.cfc:141) 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.onError(ModernAppListener.java:425) at lucee.runtime.listener.MixedAppListener.onError(MixedAppListener.java:138) at lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2488) 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 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) Caused by: java.io.IOException: Access is denied … 57 more

I really have the impression that it’s related to the change of cache / no cache at the same time that a page is called, because I noticed that it particularly affected the pages which were called every minute by scheduled tasks.

This error would make more sense to me if it only affected the files that I changed before playing with the cache, but it affects other files that already exist that haven’t changed at all and were already in the cache for a long time, like cfm pages called by scheduled tasks every minute.

I don’t really dare touch the production files or the cache anymore right now, when I would need to do some last minute fixes.

Thanks for the full stack trace. All that really shows is that the underlying exception type was java.io.IOException which is expected. FWIW, after doing a deployment, don’t change the cache setting, just click the Clear Page Pool Cache button on the same page in the admin to clear the in-memory cache which doesn’t touch the cache on disk.

1 Like

A big thank-you! You reassure me a lot! I will try it tonight during my updates. I have to admit, I’ve been pretty nervous lately. We went through a difficult period and we had to launch the Lucee version urgently and this will be our first application with this engine.

I’ll mark your answer as a solution after my tests tonight, if all goes well.

1 Like

Just a question. If this button clear only the in-memory cache, when does the cache on disk will be cleared?

I’m not aware of any manual action you can take that will clear the disk cache. Micha’s take on that was always, “Don’t worry about it, Lucee will handle it automatically”. The timestamp on the files is used to invalidate them when there is a newer version of the class file.

I tried the Clear Page Pool Cache button in the cfadmin Server and cfadmin Web without success. But while doing it, I noticed that in the cfadmin Server, the Cache was set at Never, and in the cfadmin Web, it was set at Always. For now, I set both at Once. I suppose it’s good enough and it let me update my files without the needs to clear the cache. I will see if it affects the performance.