http://coldfusion.com logo
Join Slack
Powered by
I'm curious if my sentiments on this ticket are sh...
# lucee
b
I'm curious if my sentiments on this ticket are shared by anyone else? https://luceeserver.atlassian.net/browse/LDEV-4074 Is a cftimeout tag useful or just unnecessary? I do like the 
onTimeout
convention, but I'd just as soon see that sort of thing added to cfthread directly. Precedent in the language however would make me want the timeout to raise an exception to match tags like cflock'd default behavior.
d
The only benefit I can see is not having to try and "join" the thread to wait for it to complete. However, I suspect this will cause way more confusion then anything else. Now I could be wrong, because I didn't go through the implementation code, but I suspect this still waits for external processes (like queries) to finish before timing out, which I think is the use case where someone might actually try to use this. If that's the case, I cannot see any value in it. But that's just my opinion.
b
not having to try and "join" the thread to wait for it to complete.
This is a valid point. The cftimeout tag is sync by nature. Here is the implementation https://github.com/lucee/Lucee/commit/27139ca38af10d5ac5bad32368311e683aa720e3#diff-5fb0077d519dcc3a7c896817c960[…]9cb81da2cd8799cb96cbfdb2349265R87
I suspect this still waits for external processes (like queries) to finish before timing out,
@dswitzer If you're saying it won't timeout properly when there is native code still running, that is not the case. The cftimeout tag basically runs the code in a thread, so it can simply give up and allow the parent thread to continue regardless of the status of the code inside of that thread.
now what that means is • it's possible the code inside the cftimeout tag may totally still be executing even after the main page continues • But that's basically the same as a cfthread tag FWIW • but Lucee will at least be able to gunaruntee not to block the main thread any longer than your specified timeout (or timespan-- eww)
I would have rather seen a 
timeout=seconds
than a 
timespan=createTimeSpan(...)
implemented. mostly because the realistic use case for this is going to be seconds, not hours, or days.
Here is an actual example from the test cases
Copy code
timeout timespan=0.001  {
   sleep(1000);
}
Where 
0.001
is 1 one thousandth of a single day. That's crap IMO. (A timespan is really just an integer equaling how many days. 1 = 1 day)
d
It does seem like the fact that an external process (like a query) could still be running, a problem. It would seem like you'd need to kill the thread at the timeout. While that won't necessarily stop the work something like the query's doing, I could see where maybe some operations might be creating a lock or something else that could lead to issues that the code is technically still running.
b
Fun fact, Micha played with a Lucee feature once to wrap ALL cfqueries in a thread behind the scenes so he could strictly enforce the query timeout. It had to roll it back (or at least make it not the default) because the overhead of all the extra threads on busy query-heavy apps was too much.
Micha also did the same thing once with actual HTTP request to run them in a separate thread so he could strictly enforce the page timeout. it also completely broke all monitoring tools like FR so he put it behind a feature flag and off by default
Lucee does wrap all CFHTTP calls in a thread so it can strictly enforce the http timeout. I guess that one never caused any issues, lol. It does make it much harder to track that code in Fusionreactor since none of the logic of making the actual htttp call is part of the main HTTP thread. Just a complexity of threading, really.
d
I agree it's odd that the 
timeout
wouldn't be in (milli)secounds. The 
timeout
is usually in seconds for other tags/functions, so that would make sense to keep in that way.
Open in Slack
PreviousNext
Powered by