variable [CFCATCH] doesn't exist

[gary gilbert]

Hi Folks,

fyi I will report this in jira as soon as they send me my password :)


We have an interesting issue that cfcatch does not exist inside a cfcatch block under certain circumstances, which certainly is a little strange.

The code block, extremely simplified, looks something like this.

<cfloop query="myquery">
   <cftry>
<!--- do a bunch of stuff here --->
       <cfcatch>
           <cfset stCatch = duplicate(cfcatch)> <!--- error occurs here --->
           <cfset logerror(stCatch.message,stCatch.detail)>
       </cfcatch>
</cftry>
</cfloop>

The biggest problem is that it only happens sometimes, and not all the time (at least what we can see), and generally under heavy load.

Regards,

Gary Gilbert
http://www.garyrgilbert.com/blog

[Paul Klinkenberg]

Hi Gary,

That's a nice find ;-)

I assume this is happening within a cached cfc?

Reason for the problem is that the cfcatch structure is set in the variables scope of the cfc, unless a <cfset var cfcatch = "' /> is set at the top of the function.

Now, when 2 errors are caught at about the same time, and one ends, then the variable variables.cfcatch is deleted. So, the second catch block does not have a cfcatch variable anymore.

Workaround is to add the var statement at the start of each fucntion which uses a cftry-cfcatch block.

Test code to prove this:

test.cfm:

<cfif not structKeyExists(application, "test_obj")>

<cfset application.test_obj = CreateObject("component", "test-cfcatch") />

</cfif>

<cfoutput>

<cfif not structKeyExists(url, "frame")>

<frameset rows="80%,20%" border="1">

<frame src="?frame=top" />

<frame src="?frame=bottom" />

</frameset>

<cfelseif url.frame eq "top">

#application.test_obj.test()#

<cfelse>

#application.test_obj.throwSilentError()#

</cfif>

</cfoutput>

test-cfcatch.cfc:

<cfcomponent>

<cffunction name="throwSilentError" access="public" returntype="void" output="yes">

throwing silent error...

<cfthread action="sleep" duration="2000" />

<cftry>

<cfthrow message="I'm an error" />

<cfcatch>

<!--- here we do nothing, but variables.cfcatch was available --->

</cfcatch>

<!--- now, variables.cfcatch does not exist anymore --->

</cftry>

done.

</cffunction>

<cffunction name="test" access="public" returntype="void" output="yes">

<cftry>

<cfthrow message="I'm an error" />

<cfcatch>

<cfthread action="sleep" duration="5000" />

<cfdump var="#cfcatch#" />

</cfcatch>

</cftry>

</cffunction>

</cfcomponent>

Hope it helps!

Paul Klinkenberg

www.coldfusiondeveloper.nl

[Judah McAuley]

By the by, what is the best place to put in a feature request at this
point, JIRA?

All implicitly created variables should be var scoped by the engine!!!!!

I had an unfortunate find in production where I was using cfhttp
struct returned by a cfhttp call and lo and behold, it wasn't thread
safe. Oy that was a headache. Easy fix by setting in the result
attribute but it sure wasn't obvious when the code was created.

Please, Railo, please...if a tag creates a variable on its own, put
the variable somewhere threadsafe.

Judah

[Paul Klinkenberg]

Yes, I totally agree!

Strangest thing is, that it IS var-scoped if a var-scoped variable with that name was already present. Looks like that has been coded on purpose...

Paul Klinkenberg

www.coldfusiondeveloper.nl

[Peter Boughton]

This is same behaviour as ACF - cfhttp/cfcatch/etc are not created in
function local scope unless there's already a 'var scoped' variable of
same name.

However, Railo also offers an admin setting to put all unscoped
variables in local scope, whether explicitly var scoped or not.
(Unless you're saying that even with this setting cfcatch/etc are not
being scoped, in which case that's a bug.)

--
Peter Boughton
//hybridchill.com
//sorcerers-isle.net

[Judah McAuley]

That's an excellent point, Peter, I had forgotten about that setting
as I'm doing part of my work with ACF and part with Railo and
therefore haven't done much Railo-specific stuff yet. I should make
sure that is turned on with my Railo install as I move more and more
of my code away from ACF.

Thanks,
Judah

[Judah McAuley]

The default behavior of ACF and Railo (and I presume OpenBD) is to
search through the scopes in a certain order looking for a variable of
a given name. So if a variable called cfcatch already existed in a
scope your current code had access to, I'm sure it would find it and
use it. If it doesn't find it in any scope, then it creates it. And if
you create a variable without an explicit scope, it defaults to the
variables scope.

I'm willing to bet that if you set up session.cfcatch in your
Application.cfc file, the cfcatch tag would put the results into your
session variable.

The problem really only manifests itself if you are using an
implicitly created variable in a method of a CFC that you share across
threads, like a cached service object. All the variables you declare
with the var keyword will be private to the method you are working in,
but the implicitly created variable (like the cfcatch struct) will get
scoped to variables and therefore rise up to the level of your cached
service object and no longer be thread safe.

Judah

[Peter Boughton]

(Ooops, didn't mean to mention cfcatch in previous message - that's
one that should probably always be locally scoped to it's own cfcatch
block, regardless of anything else.)

[gary gilbert]

Hi Paul,

Thats exactly what is happening, I have posted a jira ticket and will update the ticket with the excellent example code you provided. 

I honestly think its a bug in ACF as well, implicitly created variable should automatically be scoped to the local scope, I think its pretty silly to have to var scope a cfquery name.  But thats another story.

After discovering this and posting it to jira I put a var scoped cfcatch variable in the problem method.

Hopefully this will be fixed at some point :)


Gary Gilbert
http://www.garyrgilbert.com/blog

[Paul Klinkenberg]

Hi Judah and others,

It turns out that the cfcatch variable is added to the page without scope, so if you had a local 'var scoped' variable 'cfcatch', it would be overriding that one, and otherwise the cfcatch is added to the variables scope.

Check the code underneath. 

On Railo, the variable 'variables.cfcatch' will not exist anymore after the <cfcatch> tag.

Adobe CF on the other hand, does it the complete luxury way:

- it first checks if a variable called 'cfcatch' already exists. If it does, then it keeps the value of that variable in memory.

- then it sets the variable (either in 'var' or variables scope)

- after the cfcatch, the original value (if any) is re-added to the page.

I completely respect this approach; have just added this text to the JIRA ticket https://jira.jboss.org/jira/browse/RAILO-638

Regards,

Paul Klinkenberg

www.coldfusiondeveloper.nl

<cfapplication clientmanagement="yes" sessionmanagement="yes" />

<cfset variables.scopeNames_lst = "variables,url,form,session,client,application,request" />

<!--- create a cfcatch variable in each of the scopes, except the variables scope --->

<cfloop list="#variables.scopeNames_lst#" index="sScopeName">

<cfset structInsert(evaluate(sScopeName), "cfcatch", "", true) />

</cfloop>

<cfoutput>

<cfloop list="#variables.scopeNames_lst#" index="sScopeName">

<cftry>

Throwing an error

<cfthrow message="I'm an error!" />

<cfcatch>which is caught by cfcatch:

<cfdump var="#variables.cfcatch#" />

</cfcatch>

</cftry><br />

<cfloop list="#variables.scopeNames_lst#" index="sScopeName2">

structKeyExists(#sScopeName2#, "cfcatch") = #structKeyExists(evaluate(sScopeName2), "cfcatch")#<br />

</cfloop>

<cfdump var="#variables.cfcatch#" />

<hr />

</cfloop>

</cfoutput>

[Peter Boughton]

> Adobe CF on the other hand, does it the complete luxury way:
> - it first checks if a variable called 'cfcatch' already exists. If it does,
> then it keeps the value of that variable in memory.
> - then it sets the variable (either in 'var' or variables scope)
> - after the cfcatch, the original value (if any) is re-added to the page.

Yep, this is what my tired mind was trying to say last night - the
cfcatch is a special variable/scope that exists only within the
cfcatch block. (Which is different to the other tag-created
variables.)

I suspect that the original variable never actually goes away, and
with CF9 you could do local.cfcatch inside the cfcatch block to access
both of them together?

Well, except Gary has said on the Jira that will cause an error. :S

Gary... regarding the second part of your comment, CF9 implicitly
scoping stuff - does that definitely apply to non-cfcatch tag-created
variables? (cfhttp/others)

[gary gilbert]

As far as I know with cf9 implicit variables like http, cfquery and others are automatically created in the local scope, meaning you dont have to worry about them leaking out of the method.

Gary Gilbert
http://www.garyrgilbert.com/blog

[Michael Offner-Streit]

you can find the setting that use always the local scope for unscoped
variables in admin under Settings/Scope/Local scope mode
/railo-context/admin/web.cfm?action=server.scope

i personally hate it, that by default the variables scope is used and
not the local scope for unscoped variables, if you have no scope
definition always the nearest scope should be used.
CF5 has also broken here with the existing rules of CF, when macromedia
has indorduced functions with CF5 they have ignored that CF already had
a local scope concept with custom tags.
from that perspective function should have a local "variables" scope and
to access the outer variables scope you have to use "caller.", but this
is my personal opinion and the discussion comes some years to late ;-)

ACF9 still work the same way with cfhttp,cfmail or cfcatch as ACF8 does.
ACF9 still use the variables scope for unscoped none existing variables.

a other idea i have in mind is, that you can define this locale scope
mode setting also with every single cffunction
example:
<cffunction localscopemode="always|update">
any other idea here is more than welcome

@Gary
as far is i know railo work the same way as acf does with nested
cftry/cfcatch
this is a testcase we have for this:
<cftry>
<cfthrow message="a">
<cfcatch>
<cf_valueEquals left="#cfcatch.message#" right="a">
<cftry>
<cfcatch></cfcatch>
</cftry>
<cf_valueEquals left="#cfcatch.message#" right="a">
<cftry>
<cfthrow message="b">
<cfcatch>
<cf_valueEquals left="#cfcatch.message#" right="b">
</cfcatch>
</cftry>
<cf_valueEquals left="#cfcatch.message#" right="a">
</cfcatch>
</cftry>
you can see after the inner cftry/cfcatch is done, the old cfcatch is
available again

/MICHA

gary gilbert schrieb:

--
Michael Offner-Streit
CTO
Railo Technologies GmbH
michael...@railo.ch
www.getrailo.com

Mailing List (english): http://groups.yahoo.com/group/railo_talk/
Mailing List (german): http://de.groups.yahoo.com/group/railo/
Linked in: http://www.linkedin.com/e/gis/71368/0CF7D323BBC1
Issue Tracker: http://jira.jboss.org/jira/browse/RAILO
Blog: http://www.railo-technologies.com/blog

[gary gilbert]

My personal feeling on this whole thing is as follows:

1) if I create a variable then I should scope it correctly e.g. var scope
2) if a variable is created implicitly e.g. cfquery, cfhttp, cfsavecontent and others, then the variable should automatically be scoped to the local scope
3) obviously this behavior shouldnt break existing code where I've spent all that time scoping out everything and I mean everything!

Regards,

Gary Gilbert
http://www.garyrgilbert.com/blog

[Eric Cobb]

I don't like it defaulting to the variables scope either. I have Railo
set to always use the local scope (Thank you for this setting, by the
way!), but I've had problems with it causing apps like BlogCFC and Mura
CMS to break. No fault of Railo, just unscoped variables in the CFCs of
those apps.

Personally, I think ACF went about it the wrong way when they tried to
fix this problem in CF9. The introduction of the "local" scope is nice,
but what they should have done is just added a "defualtScope" attribute
to the cfcomponent tag and let it be either "local" or "variables".
That way you can choose how each CFC handles unscoped variables.

Actually, what they REALLY should have done is just add a setting in the
administrator like Railo has. :)

thanks,

eric cobb
ecar technologies, llc
http://www.cfgears.com

[Michael Offner-Streit]

i think you make a good point here, in a existing enviroment the setting
is to general, pherhaps we should have something like this in addion in
the railo admin
(only a first idea)

define where the following tags writes the resulting variables
[local | default scope] cfcatch
[local | default scope] cfmail
[local | default scope] cfpop
[local | default scope] cfhttp
[local | default scope] ...
and we should break with ACF here and set the checkbox by default to "local"

the only problem with that is that for example variables.cfcatch will
not exist, only cfcatch

what do you think?

/micha

Eric Cobb schrieb:

[gary gilbert]

Personally I think the idea of scoping variables inside a function, how shall I say....RETARDED (pardon my use of that word)

A variable declared inside of a function should be visible ONLY within the function and not leak outside of the function, who ever creates the function (explicit or implicit), and naturally should be thread safe.

I don't believe providing the ability to specify the behaviour of each tag to be a good idea, I don't even think it should be an option at all, it should just be done properly to begin with.  It shouldnt break any code if someone decides to declare a var scoped variable for their query. We should definitely break with ACF here thats a freaking hack and not a solution.


Gary Gilbert
http://www.garyrgilbert.com/blog

[Judah McAuley]

I'm going to agree with Gary here. If a variable is declared inside a
function, it should be local to that function. If it is declared
outside the function, at the level of the component, then I'm fine
with it being in the variables scope. If you, as a programmer, declare
a variable inside your function, purposefully not using the var
keyword and then accessing it from another function directly instead
of using a getter because it magically bubbles up to the variables
scope..well, you deserve to have your code broken.

Judah

[Andrea Campolonghi]

I have to say I like this idea but .... breaking ACF compatibility does not looks like a good idea to me...

Andrea

2010/3/10 Judah McAuley <judah....@gmail.com>

--
Andrea Campolonghi
and...@getrailo.org

[Judah McAuley]

In general, I would agree that ACF compatibility is a good thing. But
you also have to ask yourself...does anyone actually use this as a
feature? What would we be breaking?

I'm fine with variables scope as a default everywhere except inside
cffunction. If you declare a variable inside your function do you try
to access it from another function directly? Do you expect that two
threads accessing your component will be able to access a shared
variable inside that function? I really don't think that people tend
to build with this "functionality" in mind. Rather, the opposite is
true, which is why we have tools like Var Scoper which exist solely to
remedy this "feature" that Adobe put in place.

It might break some existing code, I agree. And I think that it is
reasonable to have an admin switch to revert to ACF compatibility if
you like. But this is the sort of compatibility that does far more
harm, from what I've seen, than good.

Cheers,
Judah

[Stefan]

I also think that the only code it would break is code that is broken
already but nobody has noticed it yet :)
I vote for making the ACF way optional instead of default.

[Michael Offner-Streit]

this already wrks in railo when you set "local scope mode" to "always", in this case always the local scope is invoked when no scope name is defined

/micha

Judah McAuley schrieb:

[Michael Offner-Streit]

We has also a hot discussion about this in the Railo Team and we was coming to the end, that we will support in addion to the local Scope Mode.
the possibility that you can define in whitch scope a tag writes its variables when not scoped, but this will not affect existing code, as long you do not change this settings.
this will looks somehow like this

example:
-----
define if the the following tags should writes its variables to local scopes, this works only for unscoped variable declaration (for example "variables.susi" will be written always to variables scope, independed of this defintion)
[ ] cfcatch
[ ] cfloop
[ ] cfmail
[ ] cfhttp
[ ] ...
-------

/micha

 



Michael Offner-Streit schrieb:

[Judah McAuley]

Yes, I appreciate this MIchael. I had actually forgotten about that
setting but was reminded of it in this thread earlier. I guess what I
am advocating for is that this be changed to the default behavior and
that compatibility with a broken ACF model is the non-default option.
I believe that this change would help prevent a lot of unintentional
headaches from trying to track down thread-safety issues in
applications under load.

Cheers,
Judah

[Peter Boughton]

On one hand, I agree with changing the default to be the sensible option.

On the other hand, I think this would break blogCFC, and possibly others too.

Even if the latest BlogCFC was updated (always use
"variables.instance" instead of just "instance"), it potentially
causes a bad experience for people switching to Railo from older
versions, which is something that at least needs to be taken into
consideration - the default Railo install (ideally) needs to work with
all major frameworks/applications.

This is perhaps another thing that would benefit from being a "helpful
hint" that first-run dashboard screen thing... has there been any
progress on that?

[Todd Rafferty]

3.2 or the 4.0 release will have the first-run dashboard. That being said, this doesn't belong there as it belongs in the wiki -- whatever the decision that comes out of this discussion.

Keep in mind, first run dashboard screen should be informational and pointing to links that should not / will not die / go away. If it's content that needs to be changed every other patch, then it's not the purpose of the dashboard. The wiki should hold up to date information.

Make sense?

--
~Todd Rafferty ** Volunteer Railo Open Source Community Manager ** http://getrailo.org/

[Todd Rafferty]

Correction, I meant to say, I personally don't think this belongs there. This isn't the opinion of Railo Technologies. Seeing that this is a community project (the first run dashboard), you tell me if you disagree with me.

[Paul Klinkenberg]

Hi all,

I'm glad to see this is being talked about!

Yesterday there was a CFUG in Amsterdam, and I briefly talked to Ben Forta about this. While he was talking about the features in CF Builder (beta 4 just released yesterday to adobe employees), I asked him if the builder would be checking/warning about unscoped variables in cffunctions. His reply was "No, but CF9 changed this behaviour with introducing the Local scope." "Yes, but variables like cfcatch and cfhttp are still in the variables scope when created, so can't CFBuilder then automagically create a <cfset var cfcatch="" /> within the cffunction?" "Yes, well, that's a good idea, but we have the ship the product at some point..." (this last line was used a lot btw ;-)

So it will probably take another year or so.

Back on subject, I'd suggest the following:

- add the option in the admin to choose if the cfcatch/cfhttp/etc variable must be set in local or variables scope

- when inside a cfcatch block, railo must first check if the var 'cfcatch' already existed, and if so, copy it, and re-set it after the cfcatch block. 

- keep storing the variable in the variables scope by default, just like ACF, for backwards compatibility. If you implement the rule above, no errors will be thrown at least by "cfcatch does not exist".

Regards,

Paul Klinkenberg

www.coldfusiondeveloper.nl

[gary gilbert]

Hi Paul,

if you attempt in cf9 to add a <cfset var cfcatch=''> in a function with a cfcatch block cf9 will error out telling you that you can't declare a local variable twice, whereas Railo will not.


Gary Gilbert
http://www.garyrgilbert.com/blog

[Michael Offner-Streit]

and when you write <cfset local.cfcatch=""> the genrated cfcatch is still in variables scope?!
in other words in cf9 it is not possible to prevent that cfcatch is not written to the variables scope, this is really a mess.

/micha




gary gilbert schrieb:

[Lyle Karstensen]

Please excuse my ignorance here but I am wondering when you would ever use this? Where in code would you set a variable called cfcatch like that? Just wondering if I have been missing something I should be doing.

Lyle Karstensen Jr.
Chief Executive Officer  (CEO)

Phone: 702.940.4200
Fax: 702.940.4201
Direct: 702.932.8200
Cell: 702.683.3666
Email: ly...@realistiq.com
Website: http://www.realistiq.com

-----Original Message-----
From: ra...@googlegroups.com [mailto:ra...@googlegroups.com] On Behalf Of gary gilbert
Sent: Thursday, March 11, 2010 11:12 PM
To: ra...@googlegroups.com
Subject: Re: [railo] variable [CFCATCH] doesn't exist

Hi Paul,

if you attempt in cf9 to add a <cfset var cfcatch=''> in a function with a cfcatch block cf9 will error out telling you that you can't declare a local variable twice, whereas Railo will not.

Gary Gilbert
http://www.garyrgilbert.com/blog

On Thu, Mar 11, 2010 at 9:19 PM, Paul Klinkenberg <pa...@ongevraagdadvies.nl> wrote:

Hi all,

I'm glad to see this is being talked about!
Yesterday there was a CFUG in Amsterdam, and I briefly talked to Ben Forta about this. While he was talking about the features in CF Builder (beta 4 just released yesterday to adobe employees), I asked him if the builder would be checking/warning about unscoped variables in cffunctions. His reply was "No, but CF9 changed this behaviour with introducing the Local scope." "Yes, but variables like cfcatch and cfhttp are still in the variables scope when created, so can't CFBuilder then automagically create a <cfset var cfcatch="" /> within the cffunction?" "Yes, well, that's a good idea, but we have the ship the product at some point..." (this last line was used a lot btw ;-)
So it will probably take another year or so.

Back on subject, I'd suggest the following:
- add the option in the admin to choose if the cfcatch/cfhttp/etc variable must be set in local or variables scope
- when inside a cfcatch block, railo must first check if the var 'cfcatch' already existed, and if so, copy it, and re-set it after the cfcatch block.
- keep storing the variable in the variables scope by default, just like ACF, for backwards compatibility. If you implement the rule above, no errors will be thrown at least by "cfcatch does not exist".


Regards,


Paul Klinkenberg

www.coldfusiondeveloper.nl <http://www.coldfusiondeveloper.nl/>

Op 11 mrt 2010, om 20:26 heeft Peter Boughton het volgende geschreven:

On one hand, I agree with changing the default to be the sensible option.

On the other hand, I think this would break blogCFC, and possibly others too.

Even if the latest BlogCFC was updated (always use
"variables.instance" instead of just "instance"), it potentially
causes a bad experience for people switching to Railo from older
versions, which is something that at least needs to be taken into
consideration - the default Railo install (ideally) needs to work with
all major frameworks/applications.


This is perhaps another thing that would benefit from being a "helpful
hint" that first-run dashboard screen thing... has there been any
progress on that?

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.733 / Virus Database: 271.1.1/2741 - Release Date: 03/12/10 01:42:00

[Paul Klinkenberg]

Hi Lyle, did you read the full post? I guess it will answer your
question :-)

Regards,

Paul klinkenberg

------------
Dit bericht is verstuurd via mijn iPhone, en is daarom wellicht
bondiger dan u van mij gewend bent.

Op 12 mrt 2010 om 17:27 heeft Lyle Karstensen <ly...@realistiq.com> het
volgende geschreven:\

[Lyle Karstensen]

I did read it and understand the issue but am not seeing why you would ever do this. I use cfcatch in my code all the time to gracefully handle errors and report them to the users but do not see a situation where I would ever set a variable called cfcatch. I am just wondering why users would do this in their code so that I might start doing it if the situation every comes up on my end. I am trying to be as efficient as possible and use as many best practices as possible.

[Judah McAuley]

The reason is that tags which implicitly create variables (cfcatch,
cfhttp, etc) create those variables unscoped. Unscoped variables, by
default, are scoped to the Variables scope. If you are doing this
inside of a CFC that is referenced by multiple threads, this is not
threadsafe. Doing <cfset var cfcatch = ''> would be a way of creating
a locally scoped (thread safe) variable that would hopefully then be
overwritten by the cfcatch in your your try/catch block.

Thank make more sense?

Judah

[Eric Cobb]

It's not so much that anyone is trying to set a variable called cfcatch,
but whenever you use cfcatch inside of a CFC ColdFusion/Railo stores the
cfcatch variable in the 'variables' scope of the CFC, instead of making
it local to the method that called it. The point was that you don't
have an option of putting the variables returned from cfcatch in the
'local' scope, it's always stored in the 'variables' scope.

This whole thing is really a debate over 'local' vs. 'variables' scopes,
when/why they're used (or shouldn't be used), and how ColdFusion/Railo
should handle those variables most efficiently.

I hope that clarifies the mud a little bit. :)

thanks,

eric cobb
ecar technologies, llc
http://www.cfgears.com

[gary gilbert]

Just to round this discussion out a bit.  This is really an edge case for us since it only happens under heavy load.  This happens occasionally in our CMS software and only happens with one particular customer, this customer has over 100 editors all hammering in content every day, the backend of the cms itself gets about 50k page views average per day on a normal day, thats 100% internal traffic as content is published to an external site.

Most of you will probably never see this bug pop up under normal circumstances but with that type of load we are getting with this particular customer it does tend to show up now and then.

@eric and Judah great explanations!


Gary Gilbert
http://www.garyrgilbert.com/blog

[Eric Cobb]

"this customer has over 100 editors all hammering in content every day, the backend of the cms itself gets about 50k page views average per day on a normal day"... 

Holy Smokes!  That is a testament to your CMS! Most of the clients I use a CMS with wouldn't generate 50k backend page views in a year!  :-)

thanks,

eric cobb
ecar technologies, llc
http://www.cfgears.com

[Paul Klinkenberg]

ROFL! WTF?! etc.
Does anybody have a direct line to Adobe, so we can pass this issue to them?

Paul

---

From: "Michael Offner-Streit" <michael...@railo.ch>
Sent: Friday, March 12, 2010 9:31 AM

To: ra...@googlegroups.com
Subject: Re: [railo] variable [CFCATCH] doesn't exist

and when you write <cfset local.cfcatch=""> the genrated cfcatch is still in variables scope?!
in other words in cf9 it is not possible to prevent that cfcatch is not written to the variables scope, this is really a mess.

/micha




gary gilbert schrieb:

Hi Paul,

if you attempt in cf9 to add a <cfset var cfcatch=''> in a function with a cfcatch block cf9 will error out telling you that you can't declare a local variable twice, whereas Railo will not.


Gary Gilbert
http://www.garyrgilbert.com/blog

On Thu, Mar 11, 2010 at 9:19 PM, Paul Klinkenberg <pa...@ongevraagdadvies.nl> wrote:

Hi all,

I'm glad to see this is being talked about!

Yesterday there was a CFUG in Amsterdam, and I briefly talked to Ben Forta about this. While he was talking about the features in CF Builder (beta 4 just released yesterday to adobe employees), I asked him if the builder would be checking/warning about unscoped variables in cffunctions. His reply was "No, but CF9 changed this behaviour with introducing the Local scope." "Yes, but variables like cfcatch and cfhttp are still in the variables scope when created, so can't CFBuilder then automagically create a <cfset var cfcatch="" /> within the cffunction?" "Yes, well, that's a good idea, but we have the ship the product at some point..." (this last line was used a lot btw ;-)

So it will probably take another year or so.

Back on subject, I'd suggest the following:

- add the option in the admin to choose if the cfcatch/cfhttp/etc variable must be set in local or variables scope

- when inside a cfcatch block, railo must first check if the var 'cfcatch' already existed, and if so, copy it, and re-set it after the cfcatch block. 

- keep storing the variable in the variables scope by default, just like ACF, for backwards compatibility. If you implement the rule above, no errors will be thrown at least by "cfcatch does not exist".

Regards,

Paul Klinkenberg

www.coldfusiondeveloper.nl

Op 11 mrt 2010, om 20:26 heeft Peter Boughton het volgende geschreven:

On one hand, I agree with changing the default to be the sensible option.

On the other hand, I think this would break blogCFC, and possibly others too.

Even if the latest BlogCFC was updated (always use
"variables.instance" instead of just "instance"), it potentially
causes a bad experience for people switching to Railo from older
versions, which is something that at least needs to be taken into
consideration - the default Railo install (ideally) needs to work with
all major frameworks/applications.


This is perhaps another thing that would benefit from being a "helpful
hint" that first-run dashboard screen thing... has there been any
progress on that?

[gary gilbert]

Direct line no, but the bugtracker seems to work fine (two of the bugs I have subitted have been marked as fixed), you just need to wait for 6 months or so before the next hotfix or updater comes up.

Gary Gilbert
http://www.garyrgilbert.com/blog

[Lyle Karstensen]

AHHHH.. That does make sense. I am not doing threading but I can see how that makes sense now. Thanks for the explanation.

[Stefan]

I am somewhat confused now with 'local' scope since ACF made a weird
version of 'this'.
I have no possibility to try it now, but will checking that option
break code such as this:

<cfcomponent>
<cfset compVar1 = "I am the Valrus">
<cfset ds = "database">
<cffunction ..>
<cfquery datasource="#ds#" ...>
</cfquery>
<cfoutput>#compVar1#</cfoutput>
</cffunction>
</cfcomponent>

Would I need to use this.ds, this.compVar1 inside the functions?
If so, I guess it breaks a lot of code because ACF's this was very
backwards and I doubt many used it.

[gary gilbert]

Dont forget that the this scope is also visible outside of the component

so in your example code lets call your component "thiscomponent"

<cfset mythis = createobject("component","thiscomponent")>

<cfset mythis.compVar1 = "I am the Walrus">
<cfset mythis.ds = "database2">

would set those values inside your component so calling your function would produce very different results that you expected, and yes you would prefix it with this.

component properties are set using the variables scope, they are global to all functions within the component but private to the component meaning they can not be influenced or directly referenced (without getters and setters) wereas the this scope is available all over the place.  At least thats how I remember it :) not sure if cf9 changed all that, I need to test it too...

Gary Gilbert
http://www.garyrgilbert.com/blog

[Stefan]

Yes, that is the ACF way. But I am not sure exactly how "Local scope
mode = always" on Railo affects that. I seem to remember that option
mentioning the 'this' scope in earlier versions of Railo, but not
anymore.

On Mar 13, 11:19 am, gary gilbert <gary.gilb...@gmail.com> wrote:
> Dont forget that the this scope is also visible outside of the component
>
> so in your example code lets call your component "thiscomponent"
>
> <cfset mythis = createobject("component","thiscomponent")>
>
> <cfset mythis.compVar1 = "I am the Walrus">
> <cfset mythis.ds = "database2">
>
> would set those values inside your component so calling your function would
> produce very different results that you expected, and yes you would prefix
> it with this.
>
> component properties are set using the variables scope, they are global to
> all functions within the component but private to the component meaning they
> can not be influenced or directly referenced (without getters and setters)
> wereas the this scope is available all over the place.  At least thats how I
> remember it :) not sure if cf9 changed all that, I need to test it too...
>

> Gary Gilberthttp://www.garyrgilbert.com/blog

>
> On Sat, Mar 13, 2010 at 10:59 AM, Stefan

> <stefan.vesterl...@googlemail.com>wrote:

[Gert Franz]

Yes there is one option in the "components" section of the admin that would allow you to eliminate/disable the "variables" scope in components. This would make sense if you would define the "this" scope to be private in the same section:

 

This would make your components safer and even safer. Faster, because Railo doesn’t have to search through the variables scope and safer because the this scope isn’t accessible from outside anymore...

 

 

Greetings from Switzerland

Gert Franz

 

Railo Technologies    Professional Open Source

skype: gert.franz        ge...@getrailo.com

+41 76 5680 231        www.getrailo.com

 

 

 

 

-----Ursprüngliche Nachricht-----
Von: ra...@googlegroups.com [mailto:ra...@googlegroups.com] Im Auftrag von Stefan
Gesendet: Samstag, 13. März 2010 11:29
An: Railo
Betreff: [railo] Re: variable [CFCATCH] doesn't exist

[gary gilbert]

And all that in combination with the magic functions just rocks!

Gary Gilbert
http://www.garyrgilbert.com/blog

[Judah McAuley]

And, by rocks, we mean work like every other language :)

Judah

[Stefan]

Indeed, but it definitely creates compatibility problems. I have
cursed the ACF behavior many times, but changing all the code to fit
the above is not easy and there is no going back.

On Mar 13, 4:40 pm, Judah McAuley <judah.mcau...@gmail.com> wrote:
> And, by rocks, we mean work like every other language :)
>
> Judah
>

> On Sat, Mar 13, 2010 at 7:10 AM, gary gilbert <gary.gilb...@gmail.com>wrote:
>
>
>
> > And all that in combination with the magic functions just rocks!
>
> > Gary Gilbert
>
> >http://www.garyrgilbert.com/blog
>

> > On Sat, Mar 13, 2010 at 11:49 AM, Gert Franz <g...@getrailo.com> wrote:
>
> >>  Yes there is one option in the "*components"* section of the admin that
> >> would allow you to eliminate/disable the "*variables*" scope in
> >> components. This would make sense if you would define the "*this*" scope

> >> to be private in the same section:
>

> >> This would make your components safer and even safer. Faster, because
> >> Railo doesn’t have to search through the variables scope and safer because
> >> the this scope isn’t accessible from outside anymore...
>
> >> Greetings from Switzerland
>
> >> Gert Franz
>
> >> Railo Technologies    Professional Open Source
>

> >> skype: gert.franz        g...@getrailo.com

>  image002.png
> 147KViewDownload

[Michael Offner-Streit]

we had a other idea to solve this problem, in ACF9 you can address the local scope as follows
<cfquery name="local.qry" ...>
because that it makes sense to simple support a attribute name for tag cfcatch like
<cfcatch name="local.catch">

what do you think?

/micha

 

Lyle Karstensen schrieb:

[Stefan]

To me, the 'local' scope feels wrong, would be better if the variables
scope was replaced with 'global' :)
It's a tricky question and I would like a path that goes straight into
compatibility with other languages rather than to struggle with
keeping both at the same time. But I guess most of us have made plenty
of sloppy code and left the scoping for CF to handle and going strict
all of a sudden is going to create headache. I also assume that
developing Railo in the "strict" direction while keeping compatibility
with ACF would be a nightmare. Branch it and take one into direction
'strict' with proper typing and everything?
I have no idea :)

On Mar 14, 8:36 pm, Michael Offner-Streit <michael.off...@railo.ch>
wrote:

> we had a other idea to solve this problem, in ACF9 you can address the
> local scope as follows
> <cfquery name="local.qry" ...>
> because that it makes sense to simple support a attribute name for tag
> cfcatch like
> <cfcatch name="local.catch">
>
> what do you think?
>
> /micha
>
> Lyle Karstensen schrieb:
>
>
>
>
>
> > AHHHH.. That does make sense. I am not doing threading but I can see how that makes sense now. Thanks for the explanation.
>
> > Lyle Karstensen Jr.
> > Chief Executive Officer  (CEO)
>
> > Phone: 702.940.4200
> > Fax: 702.940.4201
> > Direct: 702.932.8200
> > Cell: 702.683.3666

> > Email: l...@realistiq.com

> > Website:http://www.realistiq.com
>
> > -----Original Message-----
> > From: ra...@googlegroups.com [mailto:ra...@googlegroups.com] On Behalf Of Judah McAuley
> > Sent: Friday, March 12, 2010 11:07 AM
> > To: ra...@googlegroups.com
> > Subject: Re: [railo] variable [CFCATCH] doesn't exist
>
> > The reason is that tags which implicitly create variables (cfcatch,
> > cfhttp, etc) create those variables unscoped. Unscoped variables, by
> > default, are scoped to the Variables scope. If you are doing this
> > inside of a CFC that is referenced by multiple threads, this is not
> > threadsafe. Doing <cfset var cfcatch = ''> would be a way of creating
> > a locally scoped (thread safe) variable that would hopefully then be
> > overwritten by the cfcatch in your your try/catch block.
>
> > Thank make more sense?
>
> > Judah
>

> > On Fri, Mar 12, 2010 at 10:27 AM, Lyle Karstensen <l...@realistiq.com> wrote:
>
> >> I did read it and understand the issue but am not seeing why you would ever do this. I use cfcatch in my code all the time to gracefully handle errors and report them to the users but do not see a situation where I would ever set a variable called cfcatch. I am just wondering why users would do this in their code so that I might start doing it if the situation every comes up on my end. I am trying to be as efficient as possible and use as many best practices as possible.
>
> >> Lyle Karstensen Jr.
> >> Chief Executive Officer  (CEO)
>
> >> Phone: 702.940.4200
> >> Fax: 702.940.4201
> >> Direct: 702.932.8200
> >> Cell: 702.683.3666

> >> Email: l...@realistiq.com

> >> Website:http://www.realistiq.com
>
> >> -----Original Message-----
> >> From: ra...@googlegroups.com [mailto:ra...@googlegroups.com] On Behalf Of Paul Klinkenberg
> >> Sent: Friday, March 12, 2010 9:46 AM
> >> To: ra...@googlegroups.com
> >> Subject: Re: [railo] variable [CFCATCH] doesn't exist
>
> >> Hi Lyle, did you read the full post? I guess it will answer your
> >> question :-)
>
> >> Regards,
>
> >> Paul klinkenberg
>
> >> ------------
> >> Dit bericht is verstuurd via mijn iPhone, en is daarom wellicht
> >> bondiger dan u van mij gewend bent.
>

> >> Op 12 mrt 2010 om 17:27 heeft Lyle Karstensen <l...@realistiq.com> het

> >> volgende geschreven:\
>
> >>> Please excuse my ignorance here but I am wondering when you would
> >>> ever use this? Where in code would you set a variable called cfcatch
> >>> like that? Just wondering if I have been missing something I should
> >>> be doing.
>
> >>> Lyle Karstensen Jr.
> >>> Chief Executive Officer  (CEO)
>
> >>> Phone: 702.940.4200
> >>> Fax: 702.940.4201
> >>> Direct: 702.932.8200
> >>> Cell: 702.683.3666

> >>> Email: l...@realistiq.com

> >>> Website:http://www.realistiq.com
>
> >>> -----Original Message-----
> >>> From: ra...@googlegroups.com [mailto:ra...@googlegroups.com] On
> >>> Behalf Of gary gilbert
> >>> Sent: Thursday, March 11, 2010 11:12 PM
> >>> To: ra...@googlegroups.com
> >>> Subject: Re: [railo] variable [CFCATCH] doesn't exist
>
> >>> Hi Paul,
>
> >>> if you attempt in cf9 to add a <cfset var cfcatch=''> in a function
> >>> with a cfcatch block cf9 will error out telling you that you can't
> >>> declare a local variable twice, whereas Railo will not.
>
> >>> Gary Gilbert
> >>>http://www.garyrgilbert.com/blog
>

> >>> On Thu, Mar 11, 2010 at 9:19 PM, Paul Klinkenberg <p...@ongevraagdadvies.nl

> > Version: 9.0.733 / Virus Database: 271.1.1/2741 - Release Date: 03/12/10 01:42:00
>
> --
> Michael Offner-Streit
> CTO
> Railo Technologies GmbH

> michael.off...@railo.chwww.getrailo.com

[WebFlint]

I am so close from stepping off that ledge.

Gert, you mentioned going this route is safer and faster. Does anyone
have any idea how much faster it is? Our framework runs about 8K
"page operations" (the count in the Railo debugging.cfm template) per
request and I am all about shaving ms off off the bottom line. Right
now it is all running of the onMissingMethod handler.

.brett

[gary gilbert]

Micha,

I have to admit that I am lazy and dont want to have to scope cfcatch, it just needs to be in the right scope to begin with.


Gary Gilbert
http://www.garyrgilbert.com/blog

[Todd Rafferty]

I concur.

--
~Todd Rafferty ** Volunteer Railo Open Source Community Manager ** http://getrailo.org/

[Gert Franz]

Since I don't see the context anymore, can you elaborate which route it should be?

 

So for instance if it is the strict mode in Railo, then the important thing to know is: It works under ACF as well! So if you set the mode to strict in Railo, you will have to remover error after error for unscoped variables, but in the end it should be faster and work on ACF as well as on Railo. Here's a measurement I made about 2 years ago, which I updated with latest versions:

 

	Railo 3.0			Railo 3.1.2.008			not Railo
Scope	unscoped	Scoped	Improvement	unscoped	Scoped	Improvement	unscoped	Scoped	Improvement
Cookie	4852 ms	1272 ms	73.8%	2556 ms	639 ms	75.0%	4524 ms	3107 ms	31.3%
Client	4671 ms	1247 ms	73.3%	2520 ms	700 ms	72.2%	4942 ms	3748 ms	24.2%
Form	4532 ms	1242 ms	72.6%	2045 ms	988 ms	51.7%	3385 ms	2737 ms	19.1%
URL	4297 ms	1237 ms	71.2%	1480 ms	962 ms	35.0%	3114 ms	2678 ms	14.0%
CGI	2453 ms	1625 ms	33.8%	1518 ms	1300 ms	14.4%	4278 ms	4272 ms	0.1%
Variables	1256 ms	1254 ms	0.2%	656 ms	642 ms	2.1%	318 ms	2376 ms	-647.2%

 

The code used for it was:

 

<cfset iTime = getTickCount()>

<cfset cookie.sName = "susi">

<cfsilent>

            <cfloop from="1" to="4000000" index="i">

                        <cfset a = cookie.sName>

            </cfloop>

</cfsilent>

<cfset iTime = getTickCount() - iTime>

<cfoutput>#iTime#ms</cfoutput>

 

So in the unscoped one we would delete the bold "cookie." from the code so that the scope cascading needs to take care of the variable search. Then we used variables from other scopes: client, form, url, cgi & variables. Hope this helps.

 

Greetings from Switzerland

Gert Franz

 

Railo Technologies    Professional Open Source

skype: gert.franz        ge...@getrailo.com

+41 76 5680 231        www.getrailo.com

 

 

 

-----Ursprüngliche Nachricht-----
Von: ra...@googlegroups.com [mailto:ra...@googlegroups.com] Im Auftrag von WebFlint
Gesendet: Montag, 15. März 2010 01:08

An: Railo
Betreff: [railo] Re: variable [CFCATCH] doesn't exist

 

I am so close from stepping off that ledge.

[WebFlint]

Thanks for the numbers Gert, I put them it into a spreadsheet here to
make them more readable:

https://spreadsheets.google.com/ccc?key=0ArB3Iga97PPpdGxtTDE4RG9pVXVWYVZmYUU1WGVWOEE&hl=en

I always have the variable cascading setting set to strict, so we are
good there. I was curious how much faster components might be if
their data member access was set to private and the variables scope
was disabled as mentioned in your message below.

From: "Gert Franz" <g...@getrailo.com>
Date: Sat, 13 Mar 2010 11:49:10 +0100
Local: Sat, Mar 13 2010 6:49 am
Subject: AW: [railo] Re: variable [CFCATCH] doesn't exist

Yes there is one option in the "components" section of the admin that
would
allow you to eliminate/disable the "variables" scope in components.
This
would make sense if you would define the "this" scope to be private in
the
same section:

This would make your components safer and even safer. Faster, because
Railo
doesn’t have to search through the variables scope and safer because
the
this scope isn’t accessible from outside anymore...

> skype: gert.franz        g...@getrailo.com

[WebFlint]

Okay, I ran some _very quick_ tests to test the performance
differences of various component settings in the railo administrator.

Here is what I came away with:

+ Enabling or Disabling the Variables scope did not have a noticeable
change in page execution time in any of the combination of settings.

+ Turning On/Off magic functions did not cause a noticeable difference
in execution times

+ Making data member access Private, and accessing the now private
properties through magic getters DID have a pretty big impact.
Accessing private properties through magic getters was about 3x slower
than accessing through a public variable. (I had debugging turned
off)

+ Using onMissingMethod to implement a custom getter was 3x slower
than magic getters, and 9x slower than accessing the data through a
public variable.

Not much surprising here, I guess I would have hoped the magic getters
were faster, that seems like a lot of added time to lookup the
function and call it. Also onMissingMethod is _very_ slow compared to
accessing the public data member.

For anyone is curious here is my test code:

https://docs.google.com/leaf?id=0B7B3Iga97PPpNmU4M2M2NzctYzY0OS00NDZmLTk2OGMtMDI1NWJhNzU5NTRi&hl=en

On Mar 15, 10:44 am, WebFlint <webfl...@gmail.com> wrote:
> Thanks for the numbers Gert, I put them it into a spreadsheet here to
> make them more readable:
>

> https://spreadsheets.google.com/ccc?key=0ArB3Iga97PPpdGxtTDE4RG9pVXVW...

[Gert Franz]

OK... let me run the tests... I have them somewhere here...

 

Testcase	Railo 3.1.2.008	not Railo
witout setting in Railo Admin
this.myTest	73	129
myTest	fails	fails
variables.myTest	71	217
myTest	81	204
with setting in Railo Admin
this.myTest	82	129
myTest	72	fails
variables.myTest	76	217
myTest	71	204

 

So if you set the this scope to private and you hide the variables scope, you can have an implicit addressing of the this scope as well.

 

The testcase used for testing is:

 

test.cfc:

<cfcomponent>

            <cfset variables.myTest = 6>

            <cffunction name="test" access="public">

                        <cfset var a = variables.myTest>

            </cffunction>

</cfcomponent>

 

cmpn.cfm:

<cfset iTime = getTickCount()>

<cfset oObj = createObject("component", "test")>

<cfsilent>

<cfloop from="1" to="100000" index="i">

            <cfset oObj.test()>

</cfloop>

</cfsilent>

<cfset iTime = getTickCount() - iTime>

<cfoutput>#iTime#ms</cfoutput>

 

 

On a side note. If I do this in ACF:

 

<cfcomponent>

            <cfset this.test = 6>

            <cffunction name="test" access="public">

                        <cfset var a = this.test>

            </cffunction>

</cfcomponent>

 

It throws an error in ACF since creating a variable in the this scope that is named like a method in the component, overwrites the method!!! So I cannot call it from outside and I got:

 

Entity has incorrect type for being called as a function.
The symbol you provided test is not the name of a function.
The error occurred in D:\Projects\test\cmpn.cfm: line 5
3 : <cfsilent> 4 : <cfloop from="1" to="100000" index="i"> 5 :     <cfset oObj.test()> 6 : </cfloop> 7 : </cfsilent>

 

 

Gert

 

 

-----Ursprüngliche Nachricht-----
Von: ra...@googlegroups.com [mailto:ra...@googlegroups.com] Im Auftrag von WebFlint

Gesendet: Montag, 15. März 2010 15:44

[Gert Franz]

Thanks a lot for the tests. We might use them for some future
improvements...

Greetings from Switzerland
Gert Franz

Railo Technologies Professional Open Source

skype: gert.franz ge...@getrailo.com

+41 76 5680 231 www.getrailo.com

-----Ursprüngliche Nachricht-----
Von: ra...@googlegroups.com [mailto:ra...@googlegroups.com] Im Auftrag von
WebFlint

Gesendet: Montag, 15. März 2010 16:54
An: Railo
Betreff: [railo] Re: variable [CFCATCH] doesn't exist