http://coldfusion.com logo
Join Slack
Powered by
CFWheels has a bug in how it handles the applicati...
# cfwheels
a
CFWheels has a bug in how it handles the application scope, detailed here: https://blog.adamcameron.me/2022/09/cfml-looking-at-how-cfwheels-messes-up.html Am happy to raise an (abbrev`d) issue for it on GitHub if you like. I had a look and couldn't find an existing one. But if I'm off the mark in my assessment, pls lemme know if you like. #triggerWarning I am unkind about the design of CFWheels in that article. Nothing that isn't warranted, IMO, but I know some ppl consider CFWheels like their pet, not some code so... well... there you go. Be judicious in yer clicking.
d
I am constantly amazed at how you think you can consistantly trash CFWheels and continue to ask for help Adam. I think most developers would just file a bug report and then quite possibly fix it... It is open source code after all. But not you. You enjoy taking that extra time to write an essay about how awful the contributors to CFWheels were. Must be nice to know that everything you've ever developed was perfect.
c
@Adam Cameron Since you've already done most of the leg-work, are you able to finish it off with a PR? I'm sure the community would appreciate it.
s
@David Belanger The article criticizes the code, not the people.
@chapmandu Whilst his other recent article shows a good technique for encapsulating a global scope, it is far from "most of the legwork" because a PR would require a substantial rewrite of a lot of core cfWheels code -- and you know that. The article posted above, by contrast is "just" an analysis of a specific race condition problem in the current code and doesn't offer any "legwork" at all that would be close to a fix.
c
@seancorfield He seems like a very clever man and I'm sure the community would appreciate any effort. Please don't tell me "what I know", I've never touched any of the cache code.
s
"I've never touched any of the cache code." -- then you aren't one to judge whether he's done "most" of the legwork, right?
c
Fair enough.. I'll re-phrase it.. @Adam Cameron Since you've identified the issue, would you be able to contribute a PR? I'm sure the community would appreciate it.
Anyway, thanks for your valuable input Sean.. I'd better get back to work.
a
@David Belanger - wearing my Admin hat here - please play the ball and not the player. Your comment is ad hominem, and isn't really appropriate in this environment.
Back to my non-admin-self... completely keen to hear yer input on the topic under discussion though. Did I miss / misunderstand anything? --- @chapmandu I think an immediate fix might be to slap and exclusive application scope lock around the body of that function. That would bypass the immediate issue if they only place that 
application.wheels.cache
is being referenced / accessed. As @seancorfield points out... it's a significant undertaking to sort it all out, given how widespread direct application-scope access is in the codebase. I'm happy to raise the ticket (I'll do that shortly), but I've already sunk my share of time into this issue in isolating it, repro-ing it, analysing the extent of the problem and reporting back on it, also offering guidance as to what needs doing to fix it.
d
This for @Adam Cameron the "Admin": if you really believe your comments wouldn't offend people than you wouldn't have added #triggerWarning in your text above. You know exactly what you're doing when you write these things. And yes, it's very much in the way you write these things.
a
Sorry David, in my admin capacity (again) I was only addressing your tone in your response to another user (which also happens to be me). Personal attacks are not on. Second warning.
d
As for the topic at hand, I've seldom seen an app where using an application scope lock was a good idea. In this cache context I'm pretty sure that would reduce your app to a crawl.
My tone? You've got to be kidding me. I swear I take the bait every time
a
Issue raised: https://github.com/cfwheels/cfwheels/issues/1182 (sorry, that was for @chapmandu)
One needs to lock race conditions. For the very reason demonstrated here.
And for the locks to be effective, non-race-condition access to shared scopes also need to be locked. So... erm... yeah, you need to lock all access to shared scopes. IE: there's no point having the race-condition locked if there's other unlocked code that could also be messing with the shared scope at the same time. I think the mitigation is rather more... leave the shared-scope usage to the very last mile. Work with local variables where possible, and just have simple reads and writes to the shared scope. This would minimise the frequency of needing to lock stuff. Locking has overhead, but the answer to solving the overhead is not "don't lock", it's "don't write code that needs locking".
Specifically on caching... don't both Lucee and CF ship with a built-in ehcache (?) these days anyhow. Most of this shit would be handled by that already, by an application specifically designed to handle load. One would still need to mitigate race conditions, but it's perhaps a safer way of handling shared caching. Would not address the rest of the stuff CFWheels has in application scope though.
c
Some great ideas there.. and I'm sure they'll be addressed at some stage. Thanks for the leg work.
a
Sorry to arrive with a can^h^h^hbarrel of worms and kick it over and go "what a mess!" 😉 But poss better to know than not know.
c
Well, let's face it.. there's some stuff in there that needs improvement/refactoring/burning.. but that's OSS. I have no business designing a complex framework.. but I do enjoy tinkering/testing & learning.. and hopefully fixing some bugs along the way.
a
Yeah def. Legacy code / legacy design will "always" be a mess, and one is a fool to think otherwise. It's also completely fine to say so. Nothing ever gets anywhere if we're too scared to admit that things aren't great. Dave might be shocked (based on his "Must be nice to know that everything you've ever developed was perfect" comment) to find that I cringe at almost all of my code from more than about 10yrs ago. And it's all very very far from perfect. If someone was to blow smoke up my arse suggesting it was fine, I would not thank them for it. Instead I - continuously - try to get better at my game, and I'm helped by ppl pointing out shitness in code I have written. We should encourage discussion about code that is subpar and the reasons it is, and how poss to mitigate it. It's just... code. It's not the Queen. Ooh shit... too soon? (or... too late?). It's just code. Text on a screen. It doesn't have feelings. We do ourselves no favours by anthropomorphising it, or treating it as anything other than something that got typed in at some point in the past. Cos that's all it is. It's supposed to be transient, and it's supposed to be improved, not idolised.
c
My cringe zone is much less than 10 years..
a
hahahaha. OK I was showing off 😛
5 Views
Open in Slack
PreviousNext
Powered by