Using ACF10 you can disable the request timeout by setting the value to 0.
For example:
Using this on Lucee throws an exception (stack trace below). I am using
Lucee 4.5.1.000. Should a new feature request be submitted to JIRA for this
compatibility?
Stack Trace:
timeout must be a postive number at lucee.commons.lock.KeyLock.lock(Unknown> Source):-1 at lucee.runtime.PageContextImpl.initApplicationContext(Unknown
Source):-1 at lucee.runtime.listener.ModernAppListener._onRequest(Unknown
Source):-1 at lucee.runtime.listener.MixedAppListener.onRequest(Unknown
Source):-1 at lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.engine.CFMLEngineImpl.serviceCFML(Unknown Source):-1 at
lucee.loader.servlet.CFMLServlet.service(Unknown Source):-1 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:725):725 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291):291
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52):52
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239):239
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219):219
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106):106
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142):142
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79):79
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610):610
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88):88
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516):516
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1086):1086
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659):659
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223):223
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1558):1558
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515):1515
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142):1142
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617):617
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61):61
at java.lang.Thread.run(Thread.java:745):745
I don’t think this is ACF 10 or greater specific, I think that has been the
case for many years. I would therefore say yes it is a compatibility issue,
but whether or not it is agreed that it is something that should be “fixed”
is another matter. My personal feeling is having an “unlimited” timeout
option is a terrible idea. Why would you not set some sort of limit, even
if it was 86400 (1 day)?
Using ACF10 you can disable the request timeout by setting the value to 0.
For example:
Using this on Lucee throws an exception (stack trace below). I am using
Lucee 4.5.1.000. Should a new feature request be submitted to JIRA for this
compatibility?
Stack Trace:
timeout must be a postive number at
lucee.commons.lock.KeyLock.lock(Unknown Source):-1 at
lucee.runtime.PageContextImpl.initApplicationContext(Unknown Source):-1 at
lucee.runtime.listener.ModernAppListener._onRequest(Unknown Source):-1 at
lucee.runtime.listener.MixedAppListener.onRequest(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.engine.CFMLEngineImpl.serviceCFML(Unknown Source):-1 at
lucee.loader.servlet.CFMLServlet.service(Unknown Source):-1 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:725):725 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291):291
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52):52
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239):239
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219):219
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106):106
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142):142
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79):79
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610):610
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88):88
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516):516
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1086):1086
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659):659
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223):223
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1558):1558
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515):1515
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142):1142
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617):617
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61):61
at java.lang.Thread.run(Thread.java:745):745
I agree, this is not the best approach. But for some long running tasks it
is easier to assign a value of 0 than some arbitrary high number (which is
exactly what I have done to get around this). Just thought I would mention
it here in case it is something that should be logged in JIRA.
Brian
On Mon, Mar 9, 2015 at 1:40 PM, Andrew Dixon <@Andrew_Dixon> wrote:
I don’t think this is ACF 10 or greater specific, I think that has been
the case for many years. I would therefore say yes it is a compatibility
issue, but whether or not it is agreed that it is something that should be
“fixed” is another matter. My personal feeling is having an “unlimited”
timeout option is a terrible idea. Why would you not set some sort of
limit, even if it was 86400 (1 day)?
On 9 March 2015 at 18:32, Brian Love <@Brian_Love> wrote:
Using ACF10 you can disable the request timeout by setting the value to
0. For example:
Using this on Lucee throws an exception (stack trace below). I am using
Lucee 4.5.1.000. Should a new feature request be submitted to JIRA for this
compatibility?
Stack Trace:
timeout must be a postive number at
lucee.commons.lock.KeyLock.lock(Unknown Source):-1 at
lucee.runtime.PageContextImpl.initApplicationContext(Unknown Source):-1 at
lucee.runtime.listener.ModernAppListener._onRequest(Unknown Source):-1 at
lucee.runtime.listener.MixedAppListener.onRequest(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.engine.CFMLEngineImpl.serviceCFML(Unknown Source):-1 at
lucee.loader.servlet.CFMLServlet.service(Unknown Source):-1 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:725):725 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291):291
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52):52
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239):239
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219):219
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106):106
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142):142
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79):79
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610):610
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88):88
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516):516
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1086):1086
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659):659
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223):223
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1558):1558
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515):1515
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142):1142
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617):617
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61):61
at java.lang.Thread.run(Thread.java:745):745
On 9 March 2015 at 22:54, Brian Love <@Brian_Love> wrote:
Andrew:
I agree, this is not the best approach. But for some long running tasks
it is easier to assign a value of 0 than some arbitrary high number (which
is exactly what I have done to get around this). Just thought I would
mention it here in case it is something that should be logged in JIRA.
Brian
On Mon, Mar 9, 2015 at 1:40 PM, Andrew Dixon <@Andrew_Dixon> wrote:
I don’t think this is ACF 10 or greater specific, I think that has been
the case for many years. I would therefore say yes it is a compatibility
issue, but whether or not it is agreed that it is something that should be
“fixed” is another matter. My personal feeling is having an “unlimited”
timeout option is a terrible idea. Why would you not set some sort of
limit, even if it was 86400 (1 day)?
On 9 March 2015 at 18:32, Brian Love <@Brian_Love> wrote:
Using ACF10 you can disable the request timeout by setting the value to
0. For example:
Using this on Lucee throws an exception (stack trace below). I am using
Lucee 4.5.1.000. Should a new feature request be submitted to JIRA for this
compatibility?
Stack Trace:
timeout must be a postive number at
lucee.commons.lock.KeyLock.lock(Unknown Source):-1 at
lucee.runtime.PageContextImpl.initApplicationContext(Unknown Source):-1 at
lucee.runtime.listener.ModernAppListener._onRequest(Unknown Source):-1 at
lucee.runtime.listener.MixedAppListener.onRequest(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.engine.CFMLEngineImpl.serviceCFML(Unknown Source):-1 at
lucee.loader.servlet.CFMLServlet.service(Unknown Source):-1 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:725):725 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291):291
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52):52
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239):239
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219):219
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106):106
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142):142
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79):79
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610):610
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88):88
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516):516
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1086):1086
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659):659
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223):223
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1558):1558
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515):1515
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142):1142
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617):617
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61):61
at java.lang.Thread.run(Thread.java:745):745
On 9 March 2015 at 22:54, Brian Love <@Brian_Love <javascript:_e(%7B%7D,‘cvml’,‘@Brian_Love’);>> wrote:
Andrew:
I agree, this is not the best approach. But for some long running tasks
it is easier to assign a value of 0 than some arbitrary high number (which
is exactly what I have done to get around this). Just thought I would
mention it here in case it is something that should be logged in JIRA.
Brian
On Mon, Mar 9, 2015 at 1:40 PM, Andrew Dixon <@Andrew_Dixon <javascript:_e(%7B%7D,‘cvml’,‘@Andrew_Dixon’);>> wrote:
I don’t think this is ACF 10 or greater specific, I think that has been
the case for many years. I would therefore say yes it is a compatibility
issue, but whether or not it is agreed that it is something that should be
“fixed” is another matter. My personal feeling is having an “unlimited”
timeout option is a terrible idea. Why would you not set some sort of
limit, even if it was 86400 (1 day)?
On 9 March 2015 at 18:32, Brian Love <@Brian_Love <javascript:_e(%7B%7D,‘cvml’,‘@Brian_Love’);>> wrote:
Using ACF10 you can disable the request timeout by setting the value
to 0. For example:
Using this on Lucee throws an exception (stack trace below). I am
using Lucee 4.5.1.000. Should a new feature request be submitted to JIRA
for this compatibility?
Stack Trace:
timeout must be a postive number at
lucee.commons.lock.KeyLock.lock(Unknown Source):-1 at
lucee.runtime.PageContextImpl.initApplicationContext(Unknown Source):-1 at
lucee.runtime.listener.ModernAppListener._onRequest(Unknown Source):-1 at
lucee.runtime.listener.MixedAppListener.onRequest(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.engine.CFMLEngineImpl.serviceCFML(Unknown Source):-1 at
lucee.loader.servlet.CFMLServlet.service(Unknown Source):-1 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:725):725 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291):291
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52):52
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239):239
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219):219
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106):106
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142):142
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79):79
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610):610
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88):88
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516):516
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1086):1086
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659):659
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223):223
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1558):1558
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515):1515
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142):1142
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617):617
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61):61
at java.lang.Thread.run(Thread.java:745):745
On 9 March 2015 at 22:54, Brian Love <@Brian_Love> wrote:
Andrew:
I agree, this is not the best approach. But for some long running tasks
it is easier to assign a value of 0 than some arbitrary high number (which
is exactly what I have done to get around this). Just thought I would
mention it here in case it is something that should be logged in JIRA.
Brian
On Mon, Mar 9, 2015 at 1:40 PM, Andrew Dixon <@Andrew_Dixon> wrote:
I don’t think this is ACF 10 or greater specific, I think that has
been the case for many years. I would therefore say yes it is a
compatibility issue, but whether or not it is agreed that it is something
that should be “fixed” is another matter. My personal feeling is having an
“unlimited” timeout option is a terrible idea. Why would you not set some
sort of limit, even if it was 86400 (1 day)?
On 9 March 2015 at 18:32, Brian Love <@Brian_Love> wrote:
Using ACF10 you can disable the request timeout by setting the value
to 0. For example:
Using this on Lucee throws an exception (stack trace below). I am
using Lucee 4.5.1.000. Should a new feature request be submitted to JIRA
for this compatibility?
Stack Trace:
timeout must be a postive number at
lucee.commons.lock.KeyLock.lock(Unknown Source):-1 at
lucee.runtime.PageContextImpl.initApplicationContext(Unknown Source):-1 at
lucee.runtime.listener.ModernAppListener._onRequest(Unknown Source):-1 at
lucee.runtime.listener.MixedAppListener.onRequest(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.engine.CFMLEngineImpl.serviceCFML(Unknown Source):-1 at
lucee.loader.servlet.CFMLServlet.service(Unknown Source):-1 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:725):725 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291):291
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52):52
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239):239
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219):219
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106):106
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142):142
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79):79
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610):610
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88):88
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516):516
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1086):1086
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659):659
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223):223
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1558):1558
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515):1515
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142):1142
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617):617
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61):61
at java.lang.Thread.run(Thread.java:745):745
I don’t know if you want reports of other inconsistencies between ACF10 and
Lucee. I checked the Railo Language_And_Syntax_Differences wiki page and
didn’t find reference the different attributes for where ACF10 uses “result” and Lucee uses “returnvariable”.
I’d be happy to contribute to any documentation once it becomes available,
or to submit another JIRA ticket.
BrianOn Fri, Mar 13, 2015 at 10:53 AM, Michael Offner <@Michael_Offner> wrote:
Fyi we decided to support this and it is already implemented in the latest
release.
On 9 March 2015 at 22:54, Brian Love <@Brian_Love> wrote:
Andrew:
I agree, this is not the best approach. But for some long running tasks
it is easier to assign a value of 0 than some arbitrary high number (which
is exactly what I have done to get around this). Just thought I would
mention it here in case it is something that should be logged in JIRA.
Brian
On Mon, Mar 9, 2015 at 1:40 PM, Andrew Dixon <@Andrew_Dixon> wrote:
I don’t think this is ACF 10 or greater specific, I think that has
been the case for many years. I would therefore say yes it is a
compatibility issue, but whether or not it is agreed that it is something
that should be “fixed” is another matter. My personal feeling is having an
“unlimited” timeout option is a terrible idea. Why would you not set some
sort of limit, even if it was 86400 (1 day)?
On 9 March 2015 at 18:32, Brian Love <@Brian_Love> wrote:
Using ACF10 you can disable the request timeout by setting the value
to 0. For example:
Using this on Lucee throws an exception (stack trace below). I am
using Lucee 4.5.1.000. Should a new feature request be submitted to JIRA
for this compatibility?
Stack Trace:
timeout must be a postive number at
lucee.commons.lock.KeyLock.lock(Unknown Source):-1 at
lucee.runtime.PageContextImpl.initApplicationContext(Unknown Source):-1 at
lucee.runtime.listener.ModernAppListener._onRequest(Unknown Source):-1 at
lucee.runtime.listener.MixedAppListener.onRequest(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.engine.CFMLEngineImpl.serviceCFML(Unknown Source):-1 at
lucee.loader.servlet.CFMLServlet.service(Unknown Source):-1 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:725):725 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291):291
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52):52
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239):239
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219):219
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106):106
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142):142
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79):79
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610):610
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88):88
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516):516
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1086):1086
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659):659
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223):223
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1558):1558
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515):1515
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142):1142
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617):617
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61):61
at java.lang.Thread.run(Thread.java:745):745
I was not aware of this difference (returmvariable<->result), when we added
this action the same action was simply not existing in ACF. Please raise a
ticket for this and every other aspect you are aware of not documented
difference to acf. We then can decide to address the issues or document it.
In that case we simply add “result” as an alias for “returnvariable”.
MichaAm Freitag, 13. März 2015 schrieb Brian Love :
Danke, Micha.
I don’t know if you want reports of other inconsistencies between ACF10
and Lucee. I checked the Railo Language_And_Syntax_Differences wiki page
and didn’t find reference the different attributes for where ACF10 uses “result” and Lucee uses “returnvariable”.
I’d be happy to contribute to any documentation once it becomes available,
or to submit another JIRA ticket.
Brian
On Fri, Mar 13, 2015 at 10:53 AM, Michael Offner <@Michael_Offner <javascript:_e(%7B%7D,‘cvml’,‘@Michael_Offner’);>> wrote:
Fyi we decided to support this and it is already implemented in the
latest release.
On 9 March 2015 at 22:54, Brian Love <@Brian_Love> wrote:
Andrew:
I agree, this is not the best approach. But for some long running
tasks it is easier to assign a value of 0 than some arbitrary high number
(which is exactly what I have done to get around this). Just thought I
would mention it here in case it is something that should be logged in JIRA.
Brian
On Mon, Mar 9, 2015 at 1:40 PM, Andrew Dixon <@Andrew_Dixon> wrote:
I don’t think this is ACF 10 or greater specific, I think that has
been the case for many years. I would therefore say yes it is a
compatibility issue, but whether or not it is agreed that it is something
that should be “fixed” is another matter. My personal feeling is having an
“unlimited” timeout option is a terrible idea. Why would you not set some
sort of limit, even if it was 86400 (1 day)?
On 9 March 2015 at 18:32, Brian Love <@Brian_Love> wrote:
Using ACF10 you can disable the request timeout by setting the value
to 0. For example:
Using this on Lucee throws an exception (stack trace below). I am
using Lucee 4.5.1.000. Should a new feature request be submitted to JIRA
for this compatibility?
Stack Trace:
timeout must be a postive number at
lucee.commons.lock.KeyLock.lock(Unknown Source):-1 at
lucee.runtime.PageContextImpl.initApplicationContext(Unknown Source):-1 at
lucee.runtime.listener.ModernAppListener._onRequest(Unknown Source):-1 at
lucee.runtime.listener.MixedAppListener.onRequest(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.engine.CFMLEngineImpl.serviceCFML(Unknown Source):-1 at
lucee.loader.servlet.CFMLServlet.service(Unknown Source):-1 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:725):725 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291):291
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52):52
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239):239
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219):219
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106):106
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142):142
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79):79
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610):610
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88):88
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516):516
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1086):1086
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659):659
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223):223
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1558):1558
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515):1515
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142):1142
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617):617
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61):61
at java.lang.Thread.run(Thread.java:745):745
OK, I submitted a low-priority bug ticket for this incompatibility with
ACF10.
BrianOn Fri, Mar 13, 2015 at 10:37 PM, Michael Offner <@Michael_Offner> wrote:
I was not aware of this difference (returmvariable<->result), when we
added this action the same action was simply not existing in ACF. Please
raise a ticket for this and every other aspect you are aware of not
documented difference to acf. We then can decide to address the issues or
document it. In that case we simply add “result” as an alias for
“returnvariable”.
Micha
Am Freitag, 13. März 2015 schrieb Brian Love :
Danke, Micha.
I don’t know if you want reports of other inconsistencies between ACF10
and Lucee. I checked the Railo Language_And_Syntax_Differences wiki page
and didn’t find reference the different attributes for where ACF10 uses “result” and Lucee uses “returnvariable”.
I’d be happy to contribute to any documentation once it becomes available,
or to submit another JIRA ticket.
Brian
On Fri, Mar 13, 2015 at 10:53 AM, Michael Offner <@Michael_Offner> wrote:
Fyi we decided to support this and it is already implemented in the
latest release.
On 9 March 2015 at 22:54, Brian Love <@Brian_Love> wrote:
Andrew:
I agree, this is not the best approach. But for some long running
tasks it is easier to assign a value of 0 than some arbitrary high number
(which is exactly what I have done to get around this). Just thought I
would mention it here in case it is something that should be logged in JIRA.
Brian
On Mon, Mar 9, 2015 at 1:40 PM, Andrew Dixon <@Andrew_Dixon> wrote:
I don’t think this is ACF 10 or greater specific, I think that has
been the case for many years. I would therefore say yes it is a
compatibility issue, but whether or not it is agreed that it is something
that should be “fixed” is another matter. My personal feeling is having an
“unlimited” timeout option is a terrible idea. Why would you not set some
sort of limit, even if it was 86400 (1 day)?
On 9 March 2015 at 18:32, Brian Love <@Brian_Love> wrote:
Using ACF10 you can disable the request timeout by setting the
value to 0. For example:
Using this on Lucee throws an exception (stack trace below). I am
using Lucee 4.5.1.000. Should a new feature request be submitted to JIRA
for this compatibility?
Stack Trace:
timeout must be a postive number at
lucee.commons.lock.KeyLock.lock(Unknown Source):-1 at
lucee.runtime.PageContextImpl.initApplicationContext(Unknown Source):-1 at
lucee.runtime.listener.ModernAppListener._onRequest(Unknown Source):-1 at
lucee.runtime.listener.MixedAppListener.onRequest(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at
lucee.runtime.engine.CFMLEngineImpl.serviceCFML(Unknown Source):-1 at
lucee.loader.servlet.CFMLServlet.service(Unknown Source):-1 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:725):725 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291):291
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52):52
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239):239
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206):206
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219):219
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106):106
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142):142
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79):79
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610):610
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88):88
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:516):516
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1086):1086
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:659):659
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223):223
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1558):1558
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1515):1515
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142):1142
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617):617
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61):61
at java.lang.Thread.run(Thread.java:745):745
My personal feeling is having an “unlimited” timeout option is a terrible
idea. Why would you not set some sort of limit, even if it was 86400 (1
day)?
Because semantically what you’re saying here is that it’s OK for that
request to run for 23h59m, but not OK for it to run for 24h1m. And that
“24h” is somehow meaningful to the request in question. But this is
probably not what you actually mean. What you probably mean is that you
don’t want the request to timeout.
Because, for whatever reason, that was your decision.
What your kinda suggesting is that using 999999999 or HIGH-VALUES or
Integer.MAX_VALUE to circumvent a timeout occurring is actually better than
saying “just don’t do it”.
Whether or not - application-design-wise - one should have
really-really-really long-running requests is a valid consideration. But
not in the context of this particular situation. If the language provides a
runtime mechanism for duration-limiting a request, it also stands to reason
it would have a mechanism to specifically not duration-limit one.
And, yes, I note that this has been “made so” already: nice one Micha et
al. I was answering your theoretical question here.On Monday, 9 March 2015 19:40:30 UTC, Andrew Dixon wrote: