Comments on: CreateUUID() : Friendly Function or Server Killer?

By: Charlie Arehart

Charlie Arehart — Wed, 14 Jul 2010 21:16:51 +0000

Just an update to all this, since discussions here over a year ago: we should note that this problem has been addressed in CF9, which significantly increased the performance of createUUID.

If anyone from webapper sees this, it would be even more helpful to add a mention of this at the top of the entry, for future readers (some of whom may not wade through all the comments to get to this one). Since it was written in the CF 8 timeframe (3 months before 9 came out), there’s nothing in it to clarify that, so some readers may go away thinking it applies as well to CF9, discouraging them needlessly.

Here are some additional references for those interested:
http://www.petefreitag.com/item/742.cfm
http://www.coldfusionjedi.com/index.cfm/2009/8/31/createUUID-speeded-up-in-ColdFusion-9

By: Tyson Vanek

Tyson Vanek — Thu, 04 Jun 2009 19:56:55 +0000

@Sarge: Hey man, great to see you getting involved. =) Do I remember PA&T? Geesh, that’s a silly question. Aside from the fact that I spent many a week sleeping on temperature controlled server room floors during weeks on site with Allaire customers, I’m actually still performing similar sorts of “PA&T” engagements for customers in my present day work. As we all know, it’s one thing to develop and write a good ColdFusion application; another thing entirely to engineer for stability, scalability, concurrency, etc.

But, back to your question. I have not, in fact, tested with the XX:+ForceTimeHighResolution JVM flag enabled. In looking at the Sun bug detail cited by that Adobe TechNote, it seems there’s an open related issue to that original bug that was thought to be resolved. The open related issue seems to indicate that the behavior is still a problem.

Fact is, I sort of had limited accessibility to the customer environment in which we originally diagnosed this issue so I wasn’t able to go so far as altering the JVM config and experiment with adding the flag. And in my own local environments, I’m not even running ColdFusion on a Windows platform anymore. I’ve happily followed in the footsteps of many before me who have made the conversion over to Mac. I’m still running a Windows XP virtual instance that I suppose I could leverage for some testing. But my primary development configuration of ColdFusion is installed within my Mac OS.

Keep me apprised if you or someone you know manage to produce evidence that the JVM flag resolves this issue under the same configuration. I’ll be sure to update the blog posting appropriately with such finds.

By: Sarge

Sarge — Thu, 28 May 2009 15:53:19 +0000

Nice catch Tyson. Talking about coming back to bite you. I believe I wrote that technote back in 2006 after a customer pointed it out to me during a PA&T (you guys remember those?) This thing gets even more complicated when you use time synch software. We did the same loop test and literally watched the second hand spin with each iteration.

Long story short, the technote is really old and hasn’t been updated. The new technote system doesn’t seem to display the product version but this was back in the 6.0.x days. Since I don’t support CF anymore I hadn’t looked into this with CF8 but looks like I’ll have to get the team on it. Ron’s question still remains — has anyone tried the XX:+ForceTimeHighResolution JVM flag to prevent this with their chosen Sun JVM version & CF8?

By: Andy Sandefer

Andy Sandefer — Wed, 13 May 2009 21:21:34 +0000

This is great information to have. Bookmarking for sure.
Thanks!

By: Tyson Vanek

Tyson Vanek — Fri, 08 May 2009 20:40:27 +0000

@Ron: The Adobe TechNote references this behavior as being specific to 1.3.x and 1.4.x JVMs. However, I encountered this problem with a customer on a new install of CFMX 8 on JVM 1.6.0_13. This sort of makes sense to me since the original JVM bug 4500388 is listed with a status of “Fix Delivered”, but a subsequent JVM bug 6435126 which I believe still contributes to this behavior is listed with a status of “Cause Known”. The customer that I mentioned in the article did, in fact, nod their head in acknowledgement that they had seen their system clock running a bit fast on the server in question – a direct result of createUUID() being called on a near continual basis in their application with a frequency of twice very 50ms.

As far as I’m concerned, this problem is not specific to any single JVM version and should be planned for and treated as such.

By: Ron Stewart

Ron Stewart — Wed, 06 May 2009 11:47:16 +0000

Tyson: thanks for a great post! Quick question: the TechNote you reference mentions a JVM switch recommended by Sun as a fix; did you (or Charlie, given that he indicated he had burned by this, too) try that fix as a possible means of resolving this? Looking at the TechNote and the Sun bug report referenced within the TechNote, it seems like this is present for at least some people in fairly broad range of JVM versions, too.

By: charlie arehart

charlie arehart — Tue, 05 May 2009 22:27:34 +0000

Just an update to something I wrote before: I referred to a”’slide 12″ where I said I mentioned both FR and SF. My bad: I was referring to the wrong talk (my CF911 talk). In this “Clients and Sessions an d Crashes: Oh My” talk, I didn’t have much content on the slides and did most of my talking off the cuff. I may well still have referred to FR at some point but I do think/hope that when I first mentioned monitors I’d have mentioned all three, unless I was speaking of something I thought was unique to one of them.

By: charlie arehart

charlie arehart — Tue, 05 May 2009 22:20:34 +0000

@Tyson, thanks and no worries. And yes, it’s a great point we should draw out, that the monitors (all three) can monitor the DSN to track queries (read/update/insert/delete) against any DSN set to be client variable repository. It’s another great way to see the impact of the issues we’re talking about.

Separately, are you guys aware that when we submit this form we’re taken to a blank page? Is that intentional? It just makes it appear that the comment didn’t take, and it seems that you’re doing comment moderation as a refresh of the entry doesn’t show such a submission showing up immediately. Even if it needs to be a new page, how about at least saying “we got your comment. It will not await approval”, rather than a blank page? Somehow I think this blank page is unexpected behavior. Or do you see it, too?

Finally, I’m not getting email notifications of new comments. Is that to be expected? I realize you have no box offering it as an option, but since the form requires an email address, it seemed we should expect notification by default. Has this concern been raised and addressed elsewhere, perhaps in the comments of another entry, if you guys may not want to revisit the discussion here? Yes, I do see the RSS feed option. I just am surprised by the lack of an email option and wanted to ask if the lack of an email notification is indeed intentional.

By: Tyson Vanek

Tyson Vanek — Tue, 05 May 2009 21:57:05 +0000

@John: Thanks for the comment. Yes, it's good to point out that the result of a createUUID() call is more of a calculated unique value than a truly random value. And yes, I agree that integer-based CFTOKEN values pose a threat in the category of client/session hijacking. I should point out that unchecking the "Use UUID for CFTOKEN" option was just our first pass at solving this issue. I did, in fact, have a follow-up call with the customer and discuss strategies for re-structuring both their load-balancer HTTP probe calls and web service invoked CFCs in such a way that they did not incorporate the larger client/session reliant application context. And the official plan is to re-enable the "Use UUID for CFTOKEN" option once they've restructured their application code as we've suggested.

By: John Mason

John Mason — Tue, 05 May 2009 21:01:22 +0000

Great discussion and always important to note as createUUID() gets more popular to use. Just a few points to make. First, that createUUID() is not truly random in a mathematical sense, nor was it design to be. It’s design to always be unique. You pretty much showed that in the way UUID is constructed. Just wanted to make sure that point was also made here. Second, CreateUUID is a great function to use and certainly vital in use with CFToken. Developer(s) need to use it. At the same time, this is a great example shows how things can easily go wrong if the developer(s) aren’t sensitive to its nature. Unchecking UUID for cftoken wouldn’t be my first choice here for the reasons Pete stated. It fixed your problem, but at a hugh cost in possible session hijacking. The design of the webservice calls to CFCs with the client management in the way would need to be alter instead. Not fun for the developer(s), but it’s the right way to go here.