Request Timeout (was:Lucee and the future)

Inside the “Request Timeout” thread was a discussion going on that was
pointing out that a request timeout cannot be catched by a try/catch, what
seems possible in ACF.
In my opinion this is a bug in ACF here here is my explanation why:

“Like i said, a request timeout is like pulling the plug, i assume you do
not pull the plug on your computer when you are done working, this has the
risk to destroy open file when they are in a transition. You only pull the
plug when the computer is frozen.With running requests it is exactly the
same, a request timeout always comes with the risk to destroy something,
maybe the request was just writing a file that then is only halfway done or
you have open streams that not get closed properly anymore …so you should
avoid request timeouts at any coast and never ever try to deal with them.if
a request timeout occurs, you need to find out why and solve that
problem.that is btw exactly the same as caching runtimeexcpetions in java,
that smells!”

The reason i’m writing all of this is because something else come to my
mind we discussed some time ago, sometimes it is maybe impossible to “fix”
a code segment that leads to a request timeout. Simply because that code
segment, for example, is dealing with external resources, you have no
influence on how long it takes for them to get done.

I had that problem in the Lucee admin when calling the ExtensionProvider to
get information from them. So i did the following (simplified):

// call the extension provider (maybe takes some time)
thread name=“getData” {
request.data=getDataFromExtensionProvider();
}

// give the thread a chance to finish
end=getTickCount()*10000;// now + 10 seconds
do {
sleep(100);// take a nap
}while(getData.status!=“completed” && getTickcount()>end); // wait until
the thread is done or we waited more than 10 seconds

if(getData.status!=“completed”) return request.data;
throw “not able to get data”;

So the idea is to do a new tag to does exactly this:
timeout timespan=“#createTimeSpan(0,0,0,10)#” result=“res” {
data=getDataFromExtensionProvider();
}
if(res.status==“completed”) return data;
throw “not able to get data”;

So you have a code block where you can define how long Lucee maximal can
spend time on it and stopping only that block if you want.
So you can avoid a request timeout by using this tag for time sensitive
code fragments.

What do you think?

Micha

Sounds OK.

Feels like it’s a bit of a bandaid to fix a bigger issue though.

If my request timeout is set to 60 seconds and I have to look at 6 external
sources, I have to do the maths on how long each has, plus the main
requests likely time. 60 / 10, +/- a second. I can’t do that kind of maths!

Does onRequestEnd run on a request timeout? Could there be a way to pass
something to onRequestTimeout from the new proposed timeout tag? That way
the cleanup code stays with the initial code but the responsibility for
running in is moved to the request life cycle.

Just thinking out loud.

AdrianOn 12 February 2015 at 09:13, Michael Offner <@Michael_Offner> wrote:

Inside the “Request Timeout” thread was a discussion going on that was
pointing out that a request timeout cannot be catched by a try/catch, what
seems possible in ACF.
In my opinion this is a bug in ACF here here is my explanation why:

“Like i said, a request timeout is like pulling the plug, i assume you do
not pull the plug on your computer when you are done working, this has the
risk to destroy open file when they are in a transition. You only pull the
plug when the computer is frozen.With running requests it is exactly the
same, a request timeout always comes with the risk to destroy something,
maybe the request was just writing a file that then is only halfway done or
you have open streams that not get closed properly anymore …so you should
avoid request timeouts at any coast and never ever try to deal with them.if
a request timeout occurs, you need to find out why and solve that
problem.that is btw exactly the same as caching runtimeexcpetions in java,
that smells!”

The reason i’m writing all of this is because something else come to my
mind we discussed some time ago, sometimes it is maybe impossible to “fix”
a code segment that leads to a request timeout. Simply because that code
segment, for example, is dealing with external resources, you have no
influence on how long it takes for them to get done.

I had that problem in the Lucee admin when calling the ExtensionProvider
to get information from them. So i did the following (simplified):

// call the extension provider (maybe takes some time)
thread name=“getData” {
request.data=getDataFromExtensionProvider();
}

// give the thread a chance to finish
end=getTickCount()*10000;// now + 10 seconds
do {
sleep(100);// take a nap
}while(getData.status!=“completed” && getTickcount()>end); // wait until
the thread is done or we waited more than 10 seconds

if(getData.status!=“completed”) return request.data;
throw “not able to get data”;

So the idea is to do a new tag to does exactly this:
timeout timespan=“#createTimeSpan(0,0,0,10)#” result=“res” {
data=getDataFromExtensionProvider();
}
if(res.status==“completed”) return data;
throw “not able to get data”;

So you have a code block where you can define how long Lucee maximal can
spend time on it and stopping only that block if you want.
So you can avoid a request timeout by using this tag for time sensitive
code fragments.

What do you think?

Micha


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBwyM%3DddD%3DbCr5WhzO0ngGDc7e-McoNAsB0ag8s8iv69DQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBwyM%3DddD%3DbCr5WhzO0ngGDc7e-McoNAsB0ag8s8iv69DQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

I was thinking about closures as event handler, but in my opinion there is
simply no need, this is for the user happening in the same thread and you
end in any case after the tag.

Sure, I kinda like it as an alternative, but not overly fussed.

However, for a new ‘tag’, I think having a return value specified as a
variable in an attribute should be avoided as discussed in plenty of
places. I’d personally prefer a try catch style syntax if sticking with
tags:

timeout timespan=timeoutValue {
// your timeout protected code here
} exired {
// your cleanup code here
}

I think that this, or something like it, is cleaner than:

timeout timespan=timeoutValue result=“timeoutResult” {
// your timeout protected code here
}

if ( !timeoutResult.success ) {
// your cleanup code here
}On 12 February 2015 at 12:41, Michael Offner <@Michael_Offner> wrote:

I was thinking about closures as event handler, but in my opinion there is
simply no need, this is for the user happening in the same thread and you
end in any case after the tag.

From the flow it is very similar to cflock.

Micha

Am Donnerstag, 12. Februar 2015 schrieb Dominic Watson :

I like the general idea of arbitrary timeouts. Not sure on the syntax
though. How about something along these lines?

timeout timespan=mytimeout {
a bunch of code
} ontimeout {
// stuff to do when the timeout is hit
} oncomplete {
// stuff to do when complete w/ no timeout
}

or:

executeWithin( timespan, executionClosure,
timeoutExceptionHandlingClosure );

On 12 February 2015 at 09:13, Michael Offner <@Michael_Offner> wrote:

Inside the “Request Timeout” thread was a discussion going on that was
pointing out that a request timeout cannot be catched by a try/catch, what
seems possible in ACF.
In my opinion this is a bug in ACF here here is my explanation why:

“Like i said, a request timeout is like pulling the plug, i assume you
do not pull the plug on your computer when you are done working, this has
the risk to destroy open file when they are in a transition. You only pull
the plug when the computer is frozen.With running requests it is exactly
the same, a request timeout always comes with the risk to destroy
something, maybe the request was just writing a file that then is only
halfway done or you have open streams that not get closed properly anymore
…so you should avoid request timeouts at any coast and never ever try to
deal with them.if a request timeout occurs, you need to find out why and
solve that problem.that is btw exactly the same as caching
runtimeexcpetions in java, that smells!”

The reason i’m writing all of this is because something else come to my
mind we discussed some time ago, sometimes it is maybe impossible to “fix”
a code segment that leads to a request timeout. Simply because that code
segment, for example, is dealing with external resources, you have no
influence on how long it takes for them to get done.

I had that problem in the Lucee admin when calling the ExtensionProvider
to get information from them. So i did the following (simplified):

// call the extension provider (maybe takes some time)
thread name=“getData” {
request.data=getDataFromExtensionProvider();
}

// give the thread a chance to finish
end=getTickCount()*10000;// now + 10 seconds
do {
sleep(100);// take a nap
}while(getData.status!=“completed” && getTickcount()>end); // wait until
the thread is done or we waited more than 10 seconds

if(getData.status!=“completed”) return request.data;
throw “not able to get data”;

So the idea is to do a new tag to does exactly this:
timeout timespan=“#createTimeSpan(0,0,0,10)#” result=“res” {
data=getDataFromExtensionProvider();
}
if(res.status==“completed”) return data;
throw “not able to get data”;

So you have a code block where you can define how long Lucee maximal can
spend time on it and stopping only that block if you want.
So you can avoid a request timeout by using this tag for time sensitive
code fragments.

What do you think?

Micha


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBwyM%3DddD%3DbCr5WhzO0ngGDc7e-McoNAsB0ag8s8iv69DQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBwyM%3DddD%3DbCr5WhzO0ngGDc7e-McoNAsB0ag8s8iv69DQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAEYvUxmtmDv1SNFFJjjnfGduXZciPrGfe4aKQHRr8jvm-1akAQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAEYvUxmtmDv1SNFFJjjnfGduXZciPrGfe4aKQHRr8jvm-1akAQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBy_rVfTYOnh4%3DbX6A_txCu7KtwV8p6XBxU5b4T0NxxqjQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBy_rVfTYOnh4%3DbX6A_txCu7KtwV8p6XBxU5b4T0NxxqjQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn
http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

I like the general idea of arbitrary timeouts. Not sure on the syntax
though. How about something along these lines?

timeout timespan=mytimeout {
a bunch of code
} ontimeout {
// stuff to do when the timeout is hit
} oncomplete {
// stuff to do when complete w/ no timeout
}

or:

executeWithin( timespan, executionClosure, timeoutExceptionHandlingClosure
);On 12 February 2015 at 09:13, Michael Offner <@Michael_Offner> wrote:

Inside the “Request Timeout” thread was a discussion going on that was
pointing out that a request timeout cannot be catched by a try/catch, what
seems possible in ACF.
In my opinion this is a bug in ACF here here is my explanation why:

“Like i said, a request timeout is like pulling the plug, i assume you do
not pull the plug on your computer when you are done working, this has the
risk to destroy open file when they are in a transition. You only pull the
plug when the computer is frozen.With running requests it is exactly the
same, a request timeout always comes with the risk to destroy something,
maybe the request was just writing a file that then is only halfway done or
you have open streams that not get closed properly anymore …so you should
avoid request timeouts at any coast and never ever try to deal with them.if
a request timeout occurs, you need to find out why and solve that
problem.that is btw exactly the same as caching runtimeexcpetions in java,
that smells!”

The reason i’m writing all of this is because something else come to my
mind we discussed some time ago, sometimes it is maybe impossible to “fix”
a code segment that leads to a request timeout. Simply because that code
segment, for example, is dealing with external resources, you have no
influence on how long it takes for them to get done.

I had that problem in the Lucee admin when calling the ExtensionProvider
to get information from them. So i did the following (simplified):

// call the extension provider (maybe takes some time)
thread name=“getData” {
request.data=getDataFromExtensionProvider();
}

// give the thread a chance to finish
end=getTickCount()*10000;// now + 10 seconds
do {
sleep(100);// take a nap
}while(getData.status!=“completed” && getTickcount()>end); // wait until
the thread is done or we waited more than 10 seconds

if(getData.status!=“completed”) return request.data;
throw “not able to get data”;

So the idea is to do a new tag to does exactly this:
timeout timespan=“#createTimeSpan(0,0,0,10)#” result=“res” {
data=getDataFromExtensionProvider();
}
if(res.status==“completed”) return data;
throw “not able to get data”;

So you have a code block where you can define how long Lucee maximal can
spend time on it and stopping only that block if you want.
So you can avoid a request timeout by using this tag for time sensitive
code fragments.

What do you think?

Micha


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBwyM%3DddD%3DbCr5WhzO0ngGDc7e-McoNAsB0ag8s8iv69DQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBwyM%3DddD%3DbCr5WhzO0ngGDc7e-McoNAsB0ag8s8iv69DQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn
http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

In my opinion the request timeout is a bandaid, because when a request
timeout is happening it is already to late.
Your math is the wrong way around, you should define how long a certain
code block needs to execute, not the entire request. When you do a estimate
for work that need to be done, you do not first define how long it takes
overall and than break this to pieces, no you do it the other way around,
the calculated time for the single pices gives you the complete estimate.

This timeout tag has nothing to do with the request timeout, it does not
end the, so there is no need to pass something to a specific event handler.

MichaAm Donnerstag, 12. Februar 2015 schrieb Adrian Lynch :

Sounds OK.

Feels like it’s a bit of a bandaid to fix a bigger issue though.

If my request timeout is set to 60 seconds and I have to look at 6
external sources, I have to do the maths on how long each has, plus the
main requests likely time. 60 / 10, +/- a second. I can’t do that kind of
maths!

Does onRequestEnd run on a request timeout? Could there be a way to pass
something to onRequestTimeout from the new proposed timeout tag? That way
the cleanup code stays with the initial code but the responsibility for
running in is moved to the request life cycle.

Just thinking out loud.

Adrian

On 12 February 2015 at 09:13, Michael Offner <@Michael_Offner <javascript:_e(%7B%7D,‘cvml’,‘@Michael_Offner’);>> wrote:

Inside the “Request Timeout” thread was a discussion going on that was
pointing out that a request timeout cannot be catched by a try/catch, what
seems possible in ACF.
In my opinion this is a bug in ACF here here is my explanation why:

“Like i said, a request timeout is like pulling the plug, i assume you
do not pull the plug on your computer when you are done working, this has
the risk to destroy open file when they are in a transition. You only pull
the plug when the computer is frozen.With running requests it is exactly
the same, a request timeout always comes with the risk to destroy
something, maybe the request was just writing a file that then is only
halfway done or you have open streams that not get closed properly anymore
…so you should avoid request timeouts at any coast and never ever try to
deal with them.if a request timeout occurs, you need to find out why and
solve that problem.that is btw exactly the same as caching
runtimeexcpetions in java, that smells!”

The reason i’m writing all of this is because something else come to my
mind we discussed some time ago, sometimes it is maybe impossible to “fix”
a code segment that leads to a request timeout. Simply because that code
segment, for example, is dealing with external resources, you have no
influence on how long it takes for them to get done.

I had that problem in the Lucee admin when calling the ExtensionProvider
to get information from them. So i did the following (simplified):

// call the extension provider (maybe takes some time)
thread name=“getData” {
request.data=getDataFromExtensionProvider();
}

// give the thread a chance to finish
end=getTickCount()*10000;// now + 10 seconds
do {
sleep(100);// take a nap
}while(getData.status!=“completed” && getTickcount()>end); // wait until
the thread is done or we waited more than 10 seconds

if(getData.status!=“completed”) return request.data;
throw “not able to get data”;

So the idea is to do a new tag to does exactly this:
timeout timespan=“#createTimeSpan(0,0,0,10)#” result=“res” {
data=getDataFromExtensionProvider();
}
if(res.status==“completed”) return data;
throw “not able to get data”;

So you have a code block where you can define how long Lucee maximal can
spend time on it and stopping only that block if you want.
So you can avoid a request timeout by using this tag for time sensitive
code fragments.

What do you think?

Micha


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+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBwyM%3DddD%3DbCr5WhzO0ngGDc7e-McoNAsB0ag8s8iv69DQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBwyM%3DddD%3DbCr5WhzO0ngGDc7e-McoNAsB0ag8s8iv69DQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAH368SRjD%2B_BHLvEFAB8qEbjEg-EH-PSO0NxmsnYkBZA1GzdbQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAH368SRjD%2B_BHLvEFAB8qEbjEg-EH-PSO0NxmsnYkBZA1GzdbQ%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

I’m getting mixed messages Micha. “Consistent with the existing syntax”.
“We want to create a new syntax to move away from the baggage of the old
syntax”.

Yeah. Dom, are you like me in that for all these new features, you’re only
considering them or .lucee, not CFML?

Perhaps threads need to be more clear about that. Or Lucee needs to be more
clear about how they are considering where new features will be homed.

@Adam, love the idea of an onRequestTimeout application lifecycle event
that might allow some kind of recovery.

I think Micha’s right in that the options for recovery might be minimal.
But at least having the option to ignore the timeout or raise a specific
exception, or log something specific would be nice. And not beyond the
realms of what is reasonable in the given situation.On Saturday, 14 February 2015 01:20:49 UTC+13, Dominic Watson wrote:


Adam

Ruby stdlib timeout:

Just throws an error on the timeout (or returns the value of the codeblock

  • which would not make sense in the cfml tag context, though it would in
    the function with closures context).On 13 February 2015 at 13:01, Dominic Watson <@Dominic_Watson> wrote:

try( timeout=CreateTimeSpan( 0, 0, 0, 1 ) ) {

}
catch(timeout e){
dump(“shit happens”);
}

Is very interesting indeed! Not entirely sure about it (seems a little
like making one thing do two things). But definitely interesting. My
initial thought was a new construct similar to try catch:

executeWithinTimeout timespan {
// code to do stuff with
} timeout( t ){
// error handling
}

I wonder if there are any other language examples to steal from? … goes
to look on the interwebs…

On 13 February 2015 at 12:57, Michael Offner <@Michael_Offner> wrote:

between the lines …

Micha

On Fri, Feb 13, 2015 at 1:27 PM, Dominic Watson < @Dominic_Watson> wrote:

@Micha, for me, I don’t like the idea of having a return value from the
timeout

like i said that is a different topic and not about “timeout”, it is
about that script tags can be handled as expressions.

  • especially not in having to define the variable that gets the result
    in an attribute.

you still have to decide waht you are doing with the return value …
like with a function call as well…

What would be in that returned value? Just success / failure?

what makes sense…

If so, either throwing an error or having some try / catch style syntax
would remain consistent and give a cleaner syntax I think.

when i think about, this is similar to try/catch, so i could even think
about the following

try(timeout:createTimeSpan(0,0,0,1)) {

}
catch(timeout e){
dump(“shit happens”);
}

when i think about i like that a lot!
it’s a little bit more complicated to implement (needs some parser
ajustments), but it is worth doing it!

I would also argue that for consistency, both a tag and a function
could/should be implemented. For the function with closure, you would
rightly need to ensure that other functionality across the board was using
a similar syntax and that you had nailed the roadmap for that so as to keep
consistency. And FWIW, the function name executeWithin() is not clear
enough, perhaps executeWithinTimeout( timeout=485, code=closure ).

executeWithinTimeout is to long

On 13 February 2015 at 12:20, Dominic Watson <@Dominic_Watson wrote:

I’m getting mixed messages Micha. “Consistent with the existing
syntax”. “We want to create a new syntax to move away from the baggage of
the old syntax”. Another option, that would also be consistent with
existing syntax:

try {
timeout timespan=myTimeout throwontimeout=true {
// code to execute within myTimeout
}
} catch( timeout e ){}

@Adam, love the idea of an onRequestTimeout application lifecycle event
that might allow some kind of recovery.

On 13 February 2015 at 09:55, Michael Offner <@Michael_Offner> wrote:

between the lines …

Micha

On Fri, Feb 13, 2015 at 2:32 AM, Adam Cameron <@Adam_Cameron1> wrote:

On Thursday, 12 February 2015 23:23:35 UTC+13, Dominic Watson wrote:

executeWithin( timespan, executionClosure,
timeoutExceptionHandlingClosure );

This. Not the version Micha suggested, which was goddawful. Any
syntax suggestion like Micha’s is going to result in me thinking of this:
Adam Cameron's Dev Blog: CFML: the evolution of functionality

thanks for the inspiring words :wink:
this is consistent with the current syntax (see cflock), i always try
to see the biiger picture and try to be pragmatic in my solutions.

so let’s look at my example again:

timeout timespan=“#createTimeSpan(0,0,0,10)#” result=“res” {
data=getDataFromExtensionProvider();
}

and this is how cflocks works today (what is very similar from the
purpose, that is the reason i have used it as a template)

lock timeout=“#createTimeSpan(0,0,0,10)#” name=“whatever” {
data=getDataFromExtensionProvider();
}

like you can see this is consistent with the existing syntax, my
example was not about the syntax, it was about the idea for the tag timeout

i could also use the ACF syntax instead

timeout(timespan=“#createTimeSpan(0,0,0,10)#”, result=“res”) {
data=getDataFromExtensionProvider();
}

But that makes no difference. We discussed once that we could add the
possibility that script tags can return values, so that means you could do
something like this

res=timeout(timespan=“#createTimeSpan(0,0,0,10)#”) {
data=getDataFromExtensionProvider();
}

i would like to merge script tags with BIFs in the future, but that is
an other discussion and i try to not mix things up…
In my opionion adding a closure in that case is simply a overhead …

That said, there’s two different things afoot here.

Secondly, there’s this “code timeout” idea which you’re discussing
the solution for above. I think you’ve nailed the syntax above, Dom.

this syntax forces me to have my executed code in a separated scope

Firstly there’s recovery from out-of-control requests. I don’t think
the current solutions are correct, but unlike Alan BlueDragon, I do think
it’s the job of the system to pay attention to. And unlike Railo/Lucee, I
think it’s the application’s job to possibly tidy-up after.

that is my point, a request timeout has nothing to do with “tidy-up
after”
it is “hell something is very wrong here, you need to do something!
Please let that never ever happen again! Please!”
When you have a request timeout in your log you have to solve it,
because it can harm your system! You dont deal with it in your code!
When you have rats in your house you try to get rid of them, not make
a arragement with them!

I’ve not given this much thought, but I was wondering about an
additional handler in the application framework (in Application.cfc, but
might need to be in Server.cfc?):

public boolean function onTimeoutReached(context);

this way we embrace people to let request timeout happen and accept
them as part of a normal program flow. what is the complete wrong message!
No rats in my house.

Returning true from this would let the request continue, at least for
another timeout period, before firing onTimeoutReached() again. Returning
false would end the request (onRequestEnd() fires). Raising an exception in
this would cause onError() to fire.

I dunno what the context argument would contain, but something that
would allow the handler to possibly deal with whatever is going on at the
time the timeout was reached.

it is to late to deal with it, you maybe have open streams to whatever
(files, datasources, external services …) and you have no clue about it.
There are millions of possibilities that can cause a request timeout!
Let’s say the request was just writing a file, not only that this file
is only half way done, even worse the stream to this file is still open and
maybe blocked (under windows for sure!) for any other request until the
system is restarted.
the request timeout cannot clean up, it is a hammer!

Thoughts?


Adam


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/6c80ab26-435f-4a9a-9de1-47722060c2b0%40googlegroups.com
https://groups.google.com/d/msgid/lucee/6c80ab26-435f-4a9a-9de1-47722060c2b0%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEByB6HsDcxKHz88FYOtXbv1Mu6X7CBEeiSCBRD-3ct5tww%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEByB6HsDcxKHz88FYOtXbv1Mu6X7CBEeiSCBRD-3ct5tww%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAEYvUxkP2D3srM_3NjkdW8YMYswO%3DR8BaFm1PzxE3q1g58b-_w%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAEYvUxkP2D3srM_3NjkdW8YMYswO%3DR8BaFm1PzxE3q1g58b-_w%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBzPnXsZgv4kB66ANKeyUSy4U5PjiwsHBb0aH5FUgAFsrw%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBzPnXsZgv4kB66ANKeyUSy4U5PjiwsHBb0aH5FUgAFsrw%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn
http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

between the lines …

Micha

executeWithin( timespan, executionClosure, timeoutExceptionHandlingClosure
);

This. Not the version Micha suggested, which was goddawful. Any syntax
suggestion like Micha’s is going to result in me thinking of this:
Adam Cameron's Dev Blog: CFML: the evolution of functionality

thanks for the inspiring words :wink:
this is consistent with the current syntax (see cflock), i always try to
see the biiger picture and try to be pragmatic in my solutions.

so let’s look at my example again:

timeout timespan=“#createTimeSpan(0,0,0,10)#” result=“res” {
data=getDataFromExtensionProvider();
}

and this is how cflocks works today (what is very similar from the purpose,
that is the reason i have used it as a template)

lock timeout=“#createTimeSpan(0,0,0,10)#” name=“whatever” {
data=getDataFromExtensionProvider();
}

like you can see this is consistent with the existing syntax, my example
was not about the syntax, it was about the idea for the tag timeout …
i could also use the ACF syntax instead

timeout(timespan=“#createTimeSpan(0,0,0,10)#”, result=“res”) {
data=getDataFromExtensionProvider();
}

But that makes no difference. We discussed once that we could add the
possibility that script tags can return values, so that means you could do
something like this

res=timeout(timespan=“#createTimeSpan(0,0,0,10)#”) {
data=getDataFromExtensionProvider();
}

i would like to merge script tags with BIFs in the future, but that is an
other discussion and i try to not mix things up…
In my opionion adding a closure in that case is simply a overhead …

That said, there’s two different things afoot here.

Secondly, there’s this “code timeout” idea which you’re discussing the
solution for above. I think you’ve nailed the syntax above, Dom.

this syntax forces me to have my executed code in a separated scope …

Firstly there’s recovery from out-of-control requests. I don’t think the
current solutions are correct, but unlike Alan BlueDragon, I do think
it’s the job of the system to pay attention to. And unlike Railo/Lucee, I
think it’s the application’s job to possibly tidy-up after.

that is my point, a request timeout has nothing to do with “tidy-up after”
it is “hell something is very wrong here, you need to do something! Please
let that never ever happen again! Please!”
When you have a request timeout in your log you have to solve it, because
it can harm your system! You dont deal with it in your code!
When you have rats in your house you try to get rid of them, not make a
arragement with them!

I’ve not given this much thought, but I was wondering about an additional
handler in the application framework (in Application.cfc, but might need to
be in Server.cfc?):

public boolean function onTimeoutReached(context);

this way we embrace people to let request timeout happen and accept them as
part of a normal program flow. what is the complete wrong message! No rats
in my house.

Returning true from this would let the request continue, at least for
another timeout period, before firing onTimeoutReached() again. Returning
false would end the request (onRequestEnd() fires). Raising an exception in
this would cause onError() to fire.

I dunno what the context argument would contain, but something that would
allow the handler to possibly deal with whatever is going on at the time
the timeout was reached.

it is to late to deal with it, you maybe have open streams to whatever
(files, datasources, external services …) and you have no clue about it.
There are millions of possibilities that can cause a request timeout!
Let’s say the request was just writing a file, not only that this file is
only half way done, even worse the stream to this file is still open and
maybe blocked (under windows for sure!) for any other request until the
system is restarted.
the request timeout cannot clean up, it is a hammer!On Fri, Feb 13, 2015 at 2:32 AM, Adam Cameron <@Adam_Cameron1> wrote:

On Thursday, 12 February 2015 23:23:35 UTC+13, Dominic Watson wrote:

Thoughts?


Adam


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/6c80ab26-435f-4a9a-9de1-47722060c2b0%40googlegroups.com
https://groups.google.com/d/msgid/lucee/6c80ab26-435f-4a9a-9de1-47722060c2b0%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

@Micha, for me, I don’t like the idea of having a return value from the
timeout - especially not in having to define the variable that gets the
result in an attribute.

What would be in that returned value? Just success / failure? If so, either
throwing an error or having some try / catch style syntax would remain
consistent and give a cleaner syntax I think.

I would also argue that for consistency, both a tag and a function
could/should be implemented. For the function with closure, you would
rightly need to ensure that other functionality across the board was using
a similar syntax and that you had nailed the roadmap for that so as to keep
consistency. And FWIW, the function name executeWithin() is not clear
enough, perhaps executeWithinTimeout( timeout=485, code=closure ).On 13 February 2015 at 12:20, Dominic Watson <@Dominic_Watson> wrote:

I’m getting mixed messages Micha. “Consistent with the existing syntax”.
“We want to create a new syntax to move away from the baggage of the old
syntax”. Another option, that would also be consistent with existing syntax:

try {
timeout timespan=myTimeout throwontimeout=true {
// code to execute within myTimeout
}
} catch( timeout e ){}

@Adam, love the idea of an onRequestTimeout application lifecycle event
that might allow some kind of recovery.

On 13 February 2015 at 09:55, Michael Offner <@Michael_Offner> wrote:

between the lines …

Micha

On Fri, Feb 13, 2015 at 2:32 AM, Adam Cameron <@Adam_Cameron1> wrote:

On Thursday, 12 February 2015 23:23:35 UTC+13, Dominic Watson wrote:

executeWithin( timespan, executionClosure,
timeoutExceptionHandlingClosure );

This. Not the version Micha suggested, which was goddawful. Any syntax
suggestion like Micha’s is going to result in me thinking of this:
Adam Cameron's Dev Blog: CFML: the evolution of functionality

thanks for the inspiring words :wink:
this is consistent with the current syntax (see cflock), i always try to
see the biiger picture and try to be pragmatic in my solutions.

so let’s look at my example again:

timeout timespan=“#createTimeSpan(0,0,0,10)#” result=“res” {
data=getDataFromExtensionProvider();
}

and this is how cflocks works today (what is very similar from the
purpose, that is the reason i have used it as a template)

lock timeout=“#createTimeSpan(0,0,0,10)#” name=“whatever” {
data=getDataFromExtensionProvider();
}

like you can see this is consistent with the existing syntax, my example
was not about the syntax, it was about the idea for the tag timeout …
i could also use the ACF syntax instead

timeout(timespan=“#createTimeSpan(0,0,0,10)#”, result=“res”) {
data=getDataFromExtensionProvider();
}

But that makes no difference. We discussed once that we could add the
possibility that script tags can return values, so that means you could do
something like this

res=timeout(timespan=“#createTimeSpan(0,0,0,10)#”) {
data=getDataFromExtensionProvider();
}

i would like to merge script tags with BIFs in the future, but that is an
other discussion and i try to not mix things up…
In my opionion adding a closure in that case is simply a overhead …

That said, there’s two different things afoot here.

Secondly, there’s this “code timeout” idea which you’re discussing the
solution for above. I think you’ve nailed the syntax above, Dom.

this syntax forces me to have my executed code in a separated scope …

Firstly there’s recovery from out-of-control requests. I don’t think the
current solutions are correct, but unlike Alan BlueDragon, I do think
it’s the job of the system to pay attention to. And unlike Railo/Lucee, I
think it’s the application’s job to possibly tidy-up after.

that is my point, a request timeout has nothing to do with “tidy-up after”
it is “hell something is very wrong here, you need to do something!
Please let that never ever happen again! Please!”
When you have a request timeout in your log you have to solve it, because
it can harm your system! You dont deal with it in your code!
When you have rats in your house you try to get rid of them, not make a
arragement with them!

I’ve not given this much thought, but I was wondering about an
additional handler in the application framework (in Application.cfc, but
might need to be in Server.cfc?):

public boolean function onTimeoutReached(context);

this way we embrace people to let request timeout happen and accept them
as part of a normal program flow. what is the complete wrong message! No
rats in my house.

Returning true from this would let the request continue, at least for
another timeout period, before firing onTimeoutReached() again. Returning
false would end the request (onRequestEnd() fires). Raising an exception in
this would cause onError() to fire.

I dunno what the context argument would contain, but something that
would allow the handler to possibly deal with whatever is going on at the
time the timeout was reached.

it is to late to deal with it, you maybe have open streams to whatever
(files, datasources, external services …) and you have no clue about it.
There are millions of possibilities that can cause a request timeout!
Let’s say the request was just writing a file, not only that this file is
only half way done, even worse the stream to this file is still open and
maybe blocked (under windows for sure!) for any other request until the
system is restarted.
the request timeout cannot clean up, it is a hammer!

Thoughts?


Adam


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/6c80ab26-435f-4a9a-9de1-47722060c2b0%40googlegroups.com
https://groups.google.com/d/msgid/lucee/6c80ab26-435f-4a9a-9de1-47722060c2b0%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEByB6HsDcxKHz88FYOtXbv1Mu6X7CBEeiSCBRD-3ct5tww%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEByB6HsDcxKHz88FYOtXbv1Mu6X7CBEeiSCBRD-3ct5tww%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn
http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

try( timeout=CreateTimeSpan( 0, 0, 0, 1 ) ) {

}
catch(timeout e){
dump(“shit happens”);
}

Is very interesting indeed! Not entirely sure about it (seems a little like
making one thing do two things). But definitely interesting. My initial
thought was a new construct similar to try catch:

executeWithinTimeout timespan {
// code to do stuff with
} timeout( t ){
// error handling
}

I wonder if there are any other language examples to steal from? … goes
to look on the interwebs…On 13 February 2015 at 12:57, Michael Offner <@Michael_Offner> wrote:

between the lines …

Micha

On Fri, Feb 13, 2015 at 1:27 PM, Dominic Watson < @Dominic_Watson> wrote:

@Micha, for me, I don’t like the idea of having a return value from the
timeout

like i said that is a different topic and not about “timeout”, it is about
that script tags can be handled as expressions.

  • especially not in having to define the variable that gets the result in
    an attribute.

you still have to decide waht you are doing with the return value … like
with a function call as well…

What would be in that returned value? Just success / failure?

what makes sense…

If so, either throwing an error or having some try / catch style syntax
would remain consistent and give a cleaner syntax I think.

when i think about, this is similar to try/catch, so i could even think
about the following

try(timeout:createTimeSpan(0,0,0,1)) {

}
catch(timeout e){
dump(“shit happens”);
}

when i think about i like that a lot!
it’s a little bit more complicated to implement (needs some parser
ajustments), but it is worth doing it!

I would also argue that for consistency, both a tag and a function
could/should be implemented. For the function with closure, you would
rightly need to ensure that other functionality across the board was using
a similar syntax and that you had nailed the roadmap for that so as to keep
consistency. And FWIW, the function name executeWithin() is not clear
enough, perhaps executeWithinTimeout( timeout=485, code=closure ).

executeWithinTimeout is to long

On 13 February 2015 at 12:20, Dominic Watson <@Dominic_Watson> wrote:

I’m getting mixed messages Micha. “Consistent with the existing syntax”.
“We want to create a new syntax to move away from the baggage of the old
syntax”. Another option, that would also be consistent with existing syntax:

try {
timeout timespan=myTimeout throwontimeout=true {
// code to execute within myTimeout
}
} catch( timeout e ){}

@Adam, love the idea of an onRequestTimeout application lifecycle event
that might allow some kind of recovery.

On 13 February 2015 at 09:55, Michael Offner <@Michael_Offner> wrote:

between the lines …

Micha

On Fri, Feb 13, 2015 at 2:32 AM, Adam Cameron <@Adam_Cameron1> wrote:

On Thursday, 12 February 2015 23:23:35 UTC+13, Dominic Watson wrote:

executeWithin( timespan, executionClosure,
timeoutExceptionHandlingClosure );

This. Not the version Micha suggested, which was goddawful. Any syntax
suggestion like Micha’s is going to result in me thinking of this:
Adam Cameron's Dev Blog: CFML: the evolution of functionality

thanks for the inspiring words :wink:
this is consistent with the current syntax (see cflock), i always try
to see the biiger picture and try to be pragmatic in my solutions.

so let’s look at my example again:

timeout timespan=“#createTimeSpan(0,0,0,10)#” result=“res” {
data=getDataFromExtensionProvider();
}

and this is how cflocks works today (what is very similar from the
purpose, that is the reason i have used it as a template)

lock timeout=“#createTimeSpan(0,0,0,10)#” name=“whatever” {
data=getDataFromExtensionProvider();
}

like you can see this is consistent with the existing syntax, my
example was not about the syntax, it was about the idea for the tag timeout

i could also use the ACF syntax instead

timeout(timespan=“#createTimeSpan(0,0,0,10)#”, result=“res”) {
data=getDataFromExtensionProvider();
}

But that makes no difference. We discussed once that we could add the
possibility that script tags can return values, so that means you could do
something like this

res=timeout(timespan=“#createTimeSpan(0,0,0,10)#”) {
data=getDataFromExtensionProvider();
}

i would like to merge script tags with BIFs in the future, but that is
an other discussion and i try to not mix things up…
In my opionion adding a closure in that case is simply a overhead …

That said, there’s two different things afoot here.

Secondly, there’s this “code timeout” idea which you’re discussing the
solution for above. I think you’ve nailed the syntax above, Dom.

this syntax forces me to have my executed code in a separated scope …

Firstly there’s recovery from out-of-control requests. I don’t think
the current solutions are correct, but unlike Alan BlueDragon, I do think
it’s the job of the system to pay attention to. And unlike Railo/Lucee, I
think it’s the application’s job to possibly tidy-up after.

that is my point, a request timeout has nothing to do with “tidy-up
after”
it is “hell something is very wrong here, you need to do something!
Please let that never ever happen again! Please!”
When you have a request timeout in your log you have to solve it,
because it can harm your system! You dont deal with it in your code!
When you have rats in your house you try to get rid of them, not make a
arragement with them!

I’ve not given this much thought, but I was wondering about an
additional handler in the application framework (in Application.cfc, but
might need to be in Server.cfc?):

public boolean function onTimeoutReached(context);

this way we embrace people to let request timeout happen and accept
them as part of a normal program flow. what is the complete wrong message!
No rats in my house.

Returning true from this would let the request continue, at least for
another timeout period, before firing onTimeoutReached() again. Returning
false would end the request (onRequestEnd() fires). Raising an exception in
this would cause onError() to fire.

I dunno what the context argument would contain, but something that
would allow the handler to possibly deal with whatever is going on at the
time the timeout was reached.

it is to late to deal with it, you maybe have open streams to whatever
(files, datasources, external services …) and you have no clue about it.
There are millions of possibilities that can cause a request timeout!
Let’s say the request was just writing a file, not only that this file
is only half way done, even worse the stream to this file is still open and
maybe blocked (under windows for sure!) for any other request until the
system is restarted.
the request timeout cannot clean up, it is a hammer!

Thoughts?


Adam


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/6c80ab26-435f-4a9a-9de1-47722060c2b0%40googlegroups.com
https://groups.google.com/d/msgid/lucee/6c80ab26-435f-4a9a-9de1-47722060c2b0%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEByB6HsDcxKHz88FYOtXbv1Mu6X7CBEeiSCBRD-3ct5tww%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEByB6HsDcxKHz88FYOtXbv1Mu6X7CBEeiSCBRD-3ct5tww%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAEYvUxkP2D3srM_3NjkdW8YMYswO%3DR8BaFm1PzxE3q1g58b-_w%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAEYvUxkP2D3srM_3NjkdW8YMYswO%3DR8BaFm1PzxE3q1g58b-_w%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBzPnXsZgv4kB66ANKeyUSy4U5PjiwsHBb0aH5FUgAFsrw%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBzPnXsZgv4kB66ANKeyUSy4U5PjiwsHBb0aH5FUgAFsrw%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn
http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

I’m getting mixed messages Micha. “Consistent with the existing syntax”.
“We want to create a new syntax to move away from the baggage of the old
syntax”. Another option, that would also be consistent with existing syntax:

try {
timeout timespan=myTimeout throwontimeout=true {
// code to execute within myTimeout
}
} catch( timeout e ){}

@Adam, love the idea of an onRequestTimeout application lifecycle event
that might allow some kind of recovery.On 13 February 2015 at 09:55, Michael Offner <@Michael_Offner> wrote:

between the lines …

Micha

On Fri, Feb 13, 2015 at 2:32 AM, Adam Cameron <@Adam_Cameron1> wrote:

On Thursday, 12 February 2015 23:23:35 UTC+13, Dominic Watson wrote:

executeWithin( timespan, executionClosure, timeoutExceptionHandlingClosure
);

This. Not the version Micha suggested, which was goddawful. Any syntax
suggestion like Micha’s is going to result in me thinking of this:
Adam Cameron's Dev Blog: CFML: the evolution of functionality

thanks for the inspiring words :wink:
this is consistent with the current syntax (see cflock), i always try to
see the biiger picture and try to be pragmatic in my solutions.

so let’s look at my example again:

timeout timespan=“#createTimeSpan(0,0,0,10)#” result=“res” {
data=getDataFromExtensionProvider();
}

and this is how cflocks works today (what is very similar from the
purpose, that is the reason i have used it as a template)

lock timeout=“#createTimeSpan(0,0,0,10)#” name=“whatever” {
data=getDataFromExtensionProvider();
}

like you can see this is consistent with the existing syntax, my example
was not about the syntax, it was about the idea for the tag timeout …
i could also use the ACF syntax instead

timeout(timespan=“#createTimeSpan(0,0,0,10)#”, result=“res”) {
data=getDataFromExtensionProvider();
}

But that makes no difference. We discussed once that we could add the
possibility that script tags can return values, so that means you could do
something like this

res=timeout(timespan=“#createTimeSpan(0,0,0,10)#”) {
data=getDataFromExtensionProvider();
}

i would like to merge script tags with BIFs in the future, but that is an
other discussion and i try to not mix things up…
In my opionion adding a closure in that case is simply a overhead …

That said, there’s two different things afoot here.

Secondly, there’s this “code timeout” idea which you’re discussing the
solution for above. I think you’ve nailed the syntax above, Dom.

this syntax forces me to have my executed code in a separated scope …

Firstly there’s recovery from out-of-control requests. I don’t think the
current solutions are correct, but unlike Alan BlueDragon, I do think
it’s the job of the system to pay attention to. And unlike Railo/Lucee, I
think it’s the application’s job to possibly tidy-up after.

that is my point, a request timeout has nothing to do with “tidy-up after”
it is “hell something is very wrong here, you need to do something! Please
let that never ever happen again! Please!”
When you have a request timeout in your log you have to solve it, because
it can harm your system! You dont deal with it in your code!
When you have rats in your house you try to get rid of them, not make a
arragement with them!

I’ve not given this much thought, but I was wondering about an additional
handler in the application framework (in Application.cfc, but might need to
be in Server.cfc?):

public boolean function onTimeoutReached(context);

this way we embrace people to let request timeout happen and accept them
as part of a normal program flow. what is the complete wrong message! No
rats in my house.

Returning true from this would let the request continue, at least for
another timeout period, before firing onTimeoutReached() again. Returning
false would end the request (onRequestEnd() fires). Raising an exception in
this would cause onError() to fire.

I dunno what the context argument would contain, but something that would
allow the handler to possibly deal with whatever is going on at the time
the timeout was reached.

it is to late to deal with it, you maybe have open streams to whatever
(files, datasources, external services …) and you have no clue about it.
There are millions of possibilities that can cause a request timeout!
Let’s say the request was just writing a file, not only that this file is
only half way done, even worse the stream to this file is still open and
maybe blocked (under windows for sure!) for any other request until the
system is restarted.
the request timeout cannot clean up, it is a hammer!

Thoughts?


Adam


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/6c80ab26-435f-4a9a-9de1-47722060c2b0%40googlegroups.com
https://groups.google.com/d/msgid/lucee/6c80ab26-435f-4a9a-9de1-47722060c2b0%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEByB6HsDcxKHz88FYOtXbv1Mu6X7CBEeiSCBRD-3ct5tww%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEByB6HsDcxKHz88FYOtXbv1Mu6X7CBEeiSCBRD-3ct5tww%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn
http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

I like this construct, but instead of “within” I would use “timeout”,
which is consistent with cflock.

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/On 2/13/2015 6:51 AM, Dominic Watson wrote:

|> try (within=meta.timeout) {

return invocation.proceed();
} catch (TimeoutException e) {
// handle the timeout
}

|
|^^^^ +1 for ‘within’. That reads really naturally.
|


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk
http://www.pixl8.co.uk/• E: info@pixl8.co.uk mailto:info@pixl8.co.uk

Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8

CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is
intended solely for the addressee, is strictly confidential and may
also be subject to legal, professional or other privilege or may be
protected by work product immunity or other legal rules. If you are
not the addressee please do not read, print, re-transmit, store or act
in reliance on it or any attachments. Instead, please email it back to
the sender and then immediately permanently delete it. Pixl8
Interactive Ltd Registered in England. Registered number: 04336501.
Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB


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+unsubscribe@googlegroups.com
mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com
mailto:lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAEYvUxm6OgaYw4K4cpu88n9VOUQYhybRoUAD6aWODySnYL%2B0BA%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAEYvUxm6OgaYw4K4cpu88n9VOUQYhybRoUAD6aWODySnYL%2B0BA%40mail.gmail.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout.

I like the general idea of arbitrary timeouts. Not sure on the syntax
though. How about something along these lines?

timeout timespan=mytimeout {
a bunch of code
} ontimeout {
// stuff to do when the timeout is hit
} oncomplete {
// stuff to do when complete w/ no timeout
}

Oh… meant to point out that this syntax doesn’t need the oncomplete
block. The code to run “oncomplete” is simply the next line of code after
this statement.

Still: your closure example syntax is better.On Thursday, 12 February 2015 23:23:35 UTC+13, Dominic Watson wrote:


Adam

That is not about .lucee, that was about a new feature, remember what ever
happen, new feature are not affected by the dialect.

What does this mean?

still any kind of “recovery” from a request timeout is sending the wrong
message.

Just remember that whilst this is your opinion on the matter, there are
opinions which are at odds with this.On Saturday, 14 February 2015 01:49:02 UTC+13, Micha wrote:


Adam

Gotcha @micha. I think my main gripe though is that if you are to build new
features, use the best bits of the existing syntax and not continue with
the odd ones (i.e. declaring return values in attributes, especially when
that return value may not really be needed).

Re sending the wrong message on timeouts - programmers can set the request
timeout per request, why should they not then be able to decide what to do
when that limit has been reached before the execution is interrupted?
Indeed, if onError() is already invoked on request timeout, could you not
just as easily invoke a more specific onRequestTimeout()?On 13 February 2015 at 12:49, Michael Offner <@Michael_Offner> wrote:

That is not about .lucee, that was about a new feature, remember what ever
happen, new feature are not affected by the dialect.

still any kind of “recovery” from a request timeout is sending the wrong
message.

Micha

On Fri, Feb 13, 2015 at 1:20 PM, Dominic Watson < @Dominic_Watson> wrote:

I’m getting mixed messages Micha. “Consistent with the existing syntax”.
“We want to create a new syntax to move away from the baggage of the old
syntax”. Another option, that would also be consistent with existing syntax:

try {
timeout timespan=myTimeout throwontimeout=true {
// code to execute within myTimeout
}
} catch( timeout e ){}

@Adam, love the idea of an onRequestTimeout application lifecycle event
that might allow some kind of recovery.

On 13 February 2015 at 09:55, Michael Offner <@Michael_Offner> wrote:

between the lines …

Micha

On Fri, Feb 13, 2015 at 2:32 AM, Adam Cameron <@Adam_Cameron1> wrote:

On Thursday, 12 February 2015 23:23:35 UTC+13, Dominic Watson wrote:

executeWithin( timespan, executionClosure,
timeoutExceptionHandlingClosure );

This. Not the version Micha suggested, which was goddawful. Any syntax
suggestion like Micha’s is going to result in me thinking of this:
Adam Cameron's Dev Blog: CFML: the evolution of functionality

thanks for the inspiring words :wink:
this is consistent with the current syntax (see cflock), i always try to
see the biiger picture and try to be pragmatic in my solutions.

so let’s look at my example again:

timeout timespan=“#createTimeSpan(0,0,0,10)#” result=“res” {
data=getDataFromExtensionProvider();
}

and this is how cflocks works today (what is very similar from the
purpose, that is the reason i have used it as a template)

lock timeout=“#createTimeSpan(0,0,0,10)#” name=“whatever” {
data=getDataFromExtensionProvider();
}

like you can see this is consistent with the existing syntax, my example
was not about the syntax, it was about the idea for the tag timeout …
i could also use the ACF syntax instead

timeout(timespan=“#createTimeSpan(0,0,0,10)#”, result=“res”) {
data=getDataFromExtensionProvider();
}

But that makes no difference. We discussed once that we could add the
possibility that script tags can return values, so that means you could do
something like this

res=timeout(timespan=“#createTimeSpan(0,0,0,10)#”) {
data=getDataFromExtensionProvider();
}

i would like to merge script tags with BIFs in the future, but that is
an other discussion and i try to not mix things up…
In my opionion adding a closure in that case is simply a overhead …

That said, there’s two different things afoot here.

Secondly, there’s this “code timeout” idea which you’re discussing the
solution for above. I think you’ve nailed the syntax above, Dom.

this syntax forces me to have my executed code in a separated scope …

Firstly there’s recovery from out-of-control requests. I don’t think
the current solutions are correct, but unlike Alan BlueDragon, I do think
it’s the job of the system to pay attention to. And unlike Railo/Lucee, I
think it’s the application’s job to possibly tidy-up after.

that is my point, a request timeout has nothing to do with “tidy-up
after”
it is “hell something is very wrong here, you need to do something!
Please let that never ever happen again! Please!”
When you have a request timeout in your log you have to solve it,
because it can harm your system! You dont deal with it in your code!
When you have rats in your house you try to get rid of them, not make a
arragement with them!

I’ve not given this much thought, but I was wondering about an
additional handler in the application framework (in Application.cfc, but
might need to be in Server.cfc?):

public boolean function onTimeoutReached(context);

this way we embrace people to let request timeout happen and accept them
as part of a normal program flow. what is the complete wrong message! No
rats in my house.

Returning true from this would let the request continue, at least for
another timeout period, before firing onTimeoutReached() again. Returning
false would end the request (onRequestEnd() fires). Raising an exception in
this would cause onError() to fire.

I dunno what the context argument would contain, but something that
would allow the handler to possibly deal with whatever is going on at the
time the timeout was reached.

it is to late to deal with it, you maybe have open streams to whatever
(files, datasources, external services …) and you have no clue about it.
There are millions of possibilities that can cause a request timeout!
Let’s say the request was just writing a file, not only that this file
is only half way done, even worse the stream to this file is still open and
maybe blocked (under windows for sure!) for any other request until the
system is restarted.
the request timeout cannot clean up, it is a hammer!

Thoughts?


Adam


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/6c80ab26-435f-4a9a-9de1-47722060c2b0%40googlegroups.com
https://groups.google.com/d/msgid/lucee/6c80ab26-435f-4a9a-9de1-47722060c2b0%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEByB6HsDcxKHz88FYOtXbv1Mu6X7CBEeiSCBRD-3ct5tww%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEByB6HsDcxKHz88FYOtXbv1Mu6X7CBEeiSCBRD-3ct5tww%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAEYvUx%3DnhW5F62_rcnZHSacOD%3D1C1NH_-zc%3D0-UtKrx%3DXbW08w%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAEYvUx%3DnhW5F62_rcnZHSacOD%3D1C1NH_-zc%3D0-UtKrx%3DXbW08w%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBxe%3D1R%3DD3wYngaOyzQZLoRncAOp7yMLvB6h2bSwTKZ61w%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBxe%3D1R%3DD3wYngaOyzQZLoRncAOp7yMLvB6h2bSwTKZ61w%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn
http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB

executeWithin( timespan, executionClosure,
timeoutExceptionHandlingClosure );

Having surveyed all the suggestions made, and kept an open mind about
them, I still think this is the most natural, clean approach.
On Friday, February 13, 2015 at 2:19:58 PM UTC-6, Adam Cameron wrote:
On Friday, 13 February 2015 14:32:32 UTC+13, Adam Cameron wrote:
On Thursday, 12 February 2015 23:23:35 UTC+13, Dominic Watson wrote:

+1 for the try variant. Looks natural to me, and as far as I’m concerned would be the best fit. Other variants discussed look much too noisy to me.

Regarding the general question whether there should be a chance to handle a timeout in the code:
For me that would be a logical extension for exception handling. “Normally” timeouts shouldn’t occur and probably mostly are effects of a bug or bad code. Then we should better fix our code than trying to repair the effects. I can imagine situations though (e.g. connections to external services /resources) where timeouts might occur and could be “expexted”.
I don’t see why we shouldn’t get the chance to react here and go on gracefully in certain cases.

Christian

which one? there were a few of them…On 2/13/2015 1:21 PM, Christian Meis wrote:

+1 for the try variant. Looks natural to me, and as far as I’m concerned would be the best fit. Other variants discussed look much too noisy to me.

Regarding the general question whether there should be a chance to handle a timeout in the code:
For me that would be a logical extension for exception handling. “Normally” timeouts shouldn’t occur and probably mostly are effects of a bug or bad code. Then we should better fix our code than trying to repair the effects. I can imagine situations though (e.g. connections to external services /resources) where timeouts might occur and could be “expexted”.
I don’t see why we shouldn’t get the chance to react here and go on gracefully in certain cases.

Christian

That is not about .lucee, that was about a new feature, remember what ever
happen, new feature are not affected by the dialect.

still any kind of “recovery” from a request timeout is sending the wrong
message.

MichaOn Fri, Feb 13, 2015 at 1:20 PM, Dominic Watson <@Dominic_Watson> wrote:

I’m getting mixed messages Micha. “Consistent with the existing syntax”.
“We want to create a new syntax to move away from the baggage of the old
syntax”. Another option, that would also be consistent with existing syntax:

try {
timeout timespan=myTimeout throwontimeout=true {
// code to execute within myTimeout
}
} catch( timeout e ){}

@Adam, love the idea of an onRequestTimeout application lifecycle event
that might allow some kind of recovery.

On 13 February 2015 at 09:55, Michael Offner <@Michael_Offner> wrote:

between the lines …

Micha

On Fri, Feb 13, 2015 at 2:32 AM, Adam Cameron <@Adam_Cameron1> wrote:

On Thursday, 12 February 2015 23:23:35 UTC+13, Dominic Watson wrote:

executeWithin( timespan, executionClosure,
timeoutExceptionHandlingClosure );

This. Not the version Micha suggested, which was goddawful. Any syntax
suggestion like Micha’s is going to result in me thinking of this:
Adam Cameron's Dev Blog: CFML: the evolution of functionality

thanks for the inspiring words :wink:
this is consistent with the current syntax (see cflock), i always try to
see the biiger picture and try to be pragmatic in my solutions.

so let’s look at my example again:

timeout timespan=“#createTimeSpan(0,0,0,10)#” result=“res” {
data=getDataFromExtensionProvider();
}

and this is how cflocks works today (what is very similar from the
purpose, that is the reason i have used it as a template)

lock timeout=“#createTimeSpan(0,0,0,10)#” name=“whatever” {
data=getDataFromExtensionProvider();
}

like you can see this is consistent with the existing syntax, my example
was not about the syntax, it was about the idea for the tag timeout …
i could also use the ACF syntax instead

timeout(timespan=“#createTimeSpan(0,0,0,10)#”, result=“res”) {
data=getDataFromExtensionProvider();
}

But that makes no difference. We discussed once that we could add the
possibility that script tags can return values, so that means you could do
something like this

res=timeout(timespan=“#createTimeSpan(0,0,0,10)#”) {
data=getDataFromExtensionProvider();
}

i would like to merge script tags with BIFs in the future, but that is an
other discussion and i try to not mix things up…
In my opionion adding a closure in that case is simply a overhead …

That said, there’s two different things afoot here.

Secondly, there’s this “code timeout” idea which you’re discussing the
solution for above. I think you’ve nailed the syntax above, Dom.

this syntax forces me to have my executed code in a separated scope …

Firstly there’s recovery from out-of-control requests. I don’t think the
current solutions are correct, but unlike Alan BlueDragon, I do think
it’s the job of the system to pay attention to. And unlike Railo/Lucee, I
think it’s the application’s job to possibly tidy-up after.

that is my point, a request timeout has nothing to do with “tidy-up after”
it is “hell something is very wrong here, you need to do something!
Please let that never ever happen again! Please!”
When you have a request timeout in your log you have to solve it, because
it can harm your system! You dont deal with it in your code!
When you have rats in your house you try to get rid of them, not make a
arragement with them!

I’ve not given this much thought, but I was wondering about an
additional handler in the application framework (in Application.cfc, but
might need to be in Server.cfc?):

public boolean function onTimeoutReached(context);

this way we embrace people to let request timeout happen and accept them
as part of a normal program flow. what is the complete wrong message! No
rats in my house.

Returning true from this would let the request continue, at least for
another timeout period, before firing onTimeoutReached() again. Returning
false would end the request (onRequestEnd() fires). Raising an exception in
this would cause onError() to fire.

I dunno what the context argument would contain, but something that
would allow the handler to possibly deal with whatever is going on at the
time the timeout was reached.

it is to late to deal with it, you maybe have open streams to whatever
(files, datasources, external services …) and you have no clue about it.
There are millions of possibilities that can cause a request timeout!
Let’s say the request was just writing a file, not only that this file is
only half way done, even worse the stream to this file is still open and
maybe blocked (under windows for sure!) for any other request until the
system is restarted.
the request timeout cannot clean up, it is a hammer!

Thoughts?


Adam


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/6c80ab26-435f-4a9a-9de1-47722060c2b0%40googlegroups.com
https://groups.google.com/d/msgid/lucee/6c80ab26-435f-4a9a-9de1-47722060c2b0%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEByB6HsDcxKHz88FYOtXbv1Mu6X7CBEeiSCBRD-3ct5tww%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEByB6HsDcxKHz88FYOtXbv1Mu6X7CBEeiSCBRD-3ct5tww%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.


Pixl8 Interactive, 3 Tun Yard, Peardon Street, London
SW8 3HT, United Kingdom

T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: info@pixl8.co.uk
Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8CONFIDENTIAL
AND PRIVILEGED - This e-mail and any attachment is intended solely for the
addressee, is strictly confidential and may also be subject to legal,
professional or other privilege or may be protected by work product
immunity or other legal rules. If you are not the addressee please do not
read, print, re-transmit, store or act in reliance on it or any
attachments. Instead, please email it back to the sender and then
immediately permanently delete it. Pixl8 Interactive Ltd Registered in
England. Registered number: 04336501. Registered office: 8 Spur Road,
Cosham, Portsmouth, Hampshire, PO6 3EB


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAEYvUx%3DnhW5F62_rcnZHSacOD%3D1C1NH_-zc%3D0-UtKrx%3DXbW08w%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAEYvUx%3DnhW5F62_rcnZHSacOD%3D1C1NH_-zc%3D0-UtKrx%3DXbW08w%40mail.gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.