RE: CFLOCK problem
I think that the key here is that this is an indicator of how the rest of the code is likely written. While it's silly and is likely to slow things down a bit, I doubt seriously that this one useless bit of code is causing the server to crash. However, I'd be willing to bet that the rest of the application has similar flaws and probably has several that are much more problematic. I'll bet that's what's bringing it down. Thanks, Ken Ferguson 214.636.6126 -Original Message- From: Cameron Childress [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 9:22 PM To: CF-Talk Subject: Re: CFLOCK problem Well, I guess is there are exclusive server scope locks like this one all over the place, you are basically single threading the entire server in multiple points, including all apps. Under the right load I suppose that could slow things down enough to start queueing threads and bring the server down, but that would require these locks all over the place, and for the load to be healthy. If there are readonly/exclusive locks nested within each other all over, then that also introduces the possibility of deadlocks. So, yes, this could be part of a larger problem, but in and of itself it's pretty harmless. If there are lots of them, I'd remove the un-needed ones (probably virtually all of them if they are like this one) and see if that helps. However, if the original programmer did something this ridiculous, there probably a ton of other more damaging stuff in the codebase that's causing more serious problems. -Cameron On 8/31/06, Mary Jo Sminkey <[EMAIL PROTECTED]> wrote: > >That code doesn't have the power to crash anything, it's just dumb code. > > Are you sure? I'm wondering what that really long timeout is going to do. If for any reason a thread isn't able to obtain a lock, it's going to be waiting a *very* long time before timing out. I agree it's unlikely, but could be an issue on rare occasions . ~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:251763 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: CFLOCK problem
Well, I guess is there are exclusive server scope locks like this one all over the place, you are basically single threading the entire server in multiple points, including all apps. Under the right load I suppose that could slow things down enough to start queueing threads and bring the server down, but that would require these locks all over the place, and for the load to be healthy. If there are readonly/exclusive locks nested within each other all over, then that also introduces the possibility of deadlocks. So, yes, this could be part of a larger problem, but in and of itself it's pretty harmless. If there are lots of them, I'd remove the un-needed ones (probably virtually all of them if they are like this one) and see if that helps. However, if the original programmer did something this ridiculous, there probably a ton of other more damaging stuff in the codebase that's causing more serious problems. -Cameron On 8/31/06, Mary Jo Sminkey <[EMAIL PROTECTED]> wrote: > >That code doesn't have the power to crash anything, it's just dumb code. > > Are you sure? I'm wondering what that really long timeout is going to do. If > for any reason a thread isn't able to obtain a lock, it's going to be waiting > a *very* long time before timing out. I agree it's unlikely, but could be an > issue on rare occasions . ~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:251720 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: CFLOCK problem
>That code doesn't have the power to crash anything, it's just dumb code. Are you sure? I'm wondering what that really long timeout is going to do. If for any reason a thread isn't able to obtain a lock, it's going to be waiting a *very* long time before timing out. I agree it's unlikely, but could be an issue on rare occasions . ~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:251718 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: CFLOCK problem
That code doesn't have the power to crash anything, it's just dumb code. -Cameron On 8/31/06, Ken <[EMAIL PROTECTED]> wrote: > Sorry guys. We are using CF MX 7. > > So, do we agree that this code does not need the locking, and also > that this code has the power to crash a CF server under high traffic? > > Please let me know. > > Thanks, > K > > On 8/31/06, Mary Jo Sminkey <[EMAIL PROTECTED]> wrote: > > >I would argue that that is not only a horrible abuse (LOCKING on SEVER to > > >set something in SESSION), but that this situation doesn't even need a lock > > >at all. > > > > That's assuming that the server is CFMX, not CF5 (which the OP didn't > > specify), otherwise a lock is indeed needed. Pretty awful code regardless > > (in more than one way!) > > > > Mary Jo > > > > > > > > ~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:251715 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: CFLOCK problem
That code is the same as: and as others have pointed out, locking isn't required for this case in CFMX. -Cameron On 8/31/06, Ken <[EMAIL PROTECTED]> wrote: > Hi. I am analyzing another programmers code for possible code problems > that may be causing our servers to crash every so often, especially > under high traffic. > > Can someone please tell if the code below is abusing the cflock. I am > thinking the cflock scope should be set to session instead of server > scope. Could this be responsible for crashing our CF server? > > The code is: > > > > > > > > > > > > Thanks, > K > > ~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:251708 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: CFLOCK problem
Sorry guys. We are using CF MX 7. So, do we agree that this code does not need the locking, and also that this code has the power to crash a CF server under high traffic? Please let me know. Thanks, K On 8/31/06, Mary Jo Sminkey <[EMAIL PROTECTED]> wrote: > >I would argue that that is not only a horrible abuse (LOCKING on SEVER to > >set something in SESSION), but that this situation doesn't even need a lock > >at all. > > That's assuming that the server is CFMX, not CF5 (which the OP didn't > specify), otherwise a lock is indeed needed. Pretty awful code regardless (in > more than one way!) > > Mary Jo > > > ~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:251707 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: CFLOCK problem
>I would argue that that is not only a horrible abuse (LOCKING on SEVER to >set something in SESSION), but that this situation doesn't even need a lock >at all. That's assuming that the server is CFMX, not CF5 (which the OP didn't specify), otherwise a lock is indeed needed. Pretty awful code regardless (in more than one way!) Mary Jo ~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:251703 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: CFLOCK problem
> I would argue that that is not only a horrible abuse (LOCKING > on SEVER to set something in SESSION), but that this > situation doesn't even need a lock at all. The race condition > here seems unimportant. In fact, it is locking for one CFSET > but not the other. Get rid of this lock. Not to mention the use of the very much deprecated ParameterExists()!!! Wow... I haven't used that function since CF 4.01 when we migrated everything to IsDefined() and now with MX, StructKeyExists()... What version of CF is that code running on? Paul ~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:251702 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: CFLOCK problem
I would argue that that is not only a horrible abuse (LOCKING on SEVER to set something in SESSION), but that this situation doesn't even need a lock at all. The race condition here seems unimportant. In fact, it is locking for one CFSET but not the other. Get rid of this lock. ... Ben Nadel www.bennadel.com Certified Advanced ColdFusion Developer Need Help? www.bennadel.com/ask-ben/ -Original Message- From: Ken [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 6:04 PM To: CF-Talk Subject: CFLOCK problem Hi. I am analyzing another programmers code for possible code problems that may be causing our servers to crash every so often, especially under high traffic. Can someone please tell if the code below is abusing the cflock. I am thinking the cflock scope should be set to session instead of server scope. Could this be responsible for crashing our CF server? The code is: Thanks, K ~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:251701 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
