requesttimeout="0" throws exception on Lucee 4.5.1.000

166 views
Skip to first unread message

Brian Love

unread,
Mar 9, 2015, 2:32:01 PM3/9/15
to lu...@googlegroups.com
Using ACF10 you can disable the request timeout by setting the value to 0. For example:

<cfsetting requesttimeout="0">

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

Andrew Dixon

unread,
Mar 9, 2015, 3:40:30 PM3/9/15
to lu...@googlegroups.com
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)?

Kind regards,

Andrew
about.me
mso - Lucee - Member

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/657906a1-7c2c-46d3-8afc-1d67a3ef9666%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Brian Love

unread,
Mar 9, 2015, 6:54:32 PM3/9/15
to lu...@googlegroups.com
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

--
You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/Hfp2hbe9NsI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lucee+un...@googlegroups.com.

To post to this group, send email to lu...@googlegroups.com.

Andrew Dixon

unread,
Mar 10, 2015, 3:59:22 AM3/10/15
to lu...@googlegroups.com
For sure, stick it on the issue tracker as an issue, the Lucee team can then decide what to do with it:


Kind regards,

Andrew
about.me
mso - Lucee - Member

Brian Love

unread,
Mar 10, 2015, 1:43:06 PM3/10/15
to lu...@googlegroups.com

Michael Offner

unread,
Mar 13, 2015, 12:54:00 PM3/13/15
to lu...@googlegroups.com
Fyi we decided to support this and it is already implemented in the latest release.

Micha

Brian Love

unread,
Mar 13, 2015, 2:23:21 PM3/13/15
to lu...@googlegroups.com
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 <cfschedule action="list"> 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

Andrew Dixon

unread,
Mar 13, 2015, 3:44:24 PM3/13/15
to lu...@googlegroups.com
For clarity, it is in release 4.5.1.007 (https://bitbucket.org/lucee/lucee/wiki/4.5.1.007%20-%20Release%20Notes), which is a development release (bleeding edge) and available on that channel via the server admin updater. 

Kind regards,

Andrew
about.me
mso - Lucee - Member

Michael Offner

unread,
Mar 14, 2015, 12:37:49 AM3/14/15
to lu...@googlegroups.com
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

Brian Love

unread,
Mar 17, 2015, 1:02:48 PM3/17/15
to lu...@googlegroups.com
Micha:

OK, I submitted a low-priority bug ticket for this incompatibility with ACF10.


Brian

Adam Cameron

unread,
Mar 19, 2015, 4:46:55 AM3/19/15
to lu...@googlegroups.com


On Monday, 9 March 2015 19:40:30 UTC, Andrew Dixon wrote:
 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.

-- 
Adam
Reply all
Reply to author
Forward
0 new messages