Language suggestion: CFSetting[ extendRequestTimeout ]

language ideas
1

Right now, setting an absolute value for the current request timeout is easy:

setting
    requestTimeout = 30 // in seconds
;

This sets the timeout to 30-seconds regardless of where we are in the processing. And, for the most part, this is usually fine. But, for longer running tasks - or, workflows that are triggered in different ways - I think it could be useful for the CFSetting tag to have an “extend” version:

setting
    extendRequestTimeout = 5 // NOW + 5 seconds
;

This could allow some workflows to remain a bit more agnostic as to how they are getting called.

Thoughts? ( except for @AdamCameron who will tell me I’m wrong :stuck_out_tongue_winking_eye: )

7 Likes
2

Having seen the maiming of attempts at request timeout management that [my framework of “choice”] has foist upon me, I 100% agree with this.

It’s also very idiomatic I think, and just makes sense.

Sorry to let you down, mate. By agreeing with you, I mean.

2 Likes
3

… Nearly faints, grabs table for support

1 Like
4

definitely a problem, not really sure about extending the tag like that, one alternative simple approach would be to just support relative values, i.e.

setting requestTimeout = "+5"; // extend timeout by 5 seconds

in the meantime, you can just do this

<cfscript>
    dump(getPageContext().getRequestTimeout());
    setting requesttimeout=5;
    dump(getPageContext().getRequestTimeout());
    setting requesttimeout=10;
    dump(getPageContext().getRequestTimeout());
</cfscript>

image

2 Likes
5

I think the issue here is that (at least in the Adobe ColdFusion runtime) this is setting the absolute timeout. So, if you set it to 10 again, the overall page timeout won’t become “20 seconds”, it will just stay “10”.

Most of the time, this is fine! But, there are use-cases in which I would like to extend the time. A bit of this comes down to where I se the timeout - is it in the controller or in the business logic. Technically, timeout is a “web problem”, not a “business problem”. But, on the flip side, understanding how long a page might right is likely more coupled to the business logic.

6

Looks like I can do something like this in Lucee (based on your .getRequestTimeout() code):

<cfscript>
	/**
	* I EXTEND the request timeout by the given seconds using the native CFSettings tag.
	*/
	public void function requestExtendTimeout( required numeric timeoutInSeconds ) {

		var currentTimeout = ( getPageContext().getRequestTimeout() / 1000 );

		setting
			requestTimeout = ( currentTimeout + timeoutInSeconds )
		;

	}
</cfscript>

I’ll see if that works in ACF as well.

7

Meh, Adobe ColdFusion doesn’t have a getPageContext().getRequestTimeout() method.

8

I wrote up more of a note-to-self on this. Extending The Current Request Timeout In ColdFusion / CFML Ironically, the moment I wrote it, I found an article that I wrote from 2007 that was dealing with the exact same issue :cold_sweat: Too much to hold in my head.

9

Hey, Ben. As for ACF, you were very close. :slight_smile: It’s that in that getpagecontext(), there is then a getfusioncontext() which has many very interesting things, including what you seek (though slightly differently named), as:

getpagecontext().getfusioncontext().getCfSettingTimeout()

Let us know if that works for you.

10

@carehart so, I actually came across that (I was just dumping-out random properties). But, at least from what I saw, the getCFSettingTimeout() returns 0 if you haven’t explicitly used the CFSetting tag (ie, if you’re just using the Admin default value).

This value, however, appears to pick up the default value (was 60s in my CommandBox instance); or, whatever the explicitly set one was.

createObject( "java", "coldfusion.runtime.RequestMonitor" )
    .getRequestTimeout()
;

Of course, the downside with this one is that it’s 1) Not documented anywhere and 2) requires access to the Java objects (which I think is turned-off by default on some installs).

11

Thanks for the clarification, Ben. I’d thought the 0 was because I had the admin timeout unchecked (no timeout), so yes, when I did a cfsetting then that function I shared did report what I had used there.

So I agree, it’s not as useful, as-is. I did dig around quite a bit in that object’s functions (and objects those returned), and I didn’t find any other referring to getting the timeout info. I appreciate why the Java-based way is not as desirable to many. Same with an adminAPI way.

So it may well be that there’s no other way to obtain it. That does surprise me, though I have to admit I’d not sought to get the timeout programmatically before. Maybe someone else will know a way :slight_smile:

12

It’s not something that comes up a lot. I just have a case in which I’m using the same code in two different ways (once in a one-off run, and once inside a scheduled-task that executed in a loop). In the latter, I want to set the timeout to a higher value.

Maybe that flaw is more in how I’ve organized my code.