Fortunately and/or unfortunately, Commonspot is backwards compatible to older versions of ColdFusion, including versions which required very careful use of CFLOCK to ensure shared memory doesn't become corrupted. This means that even if you are running CFMX, you're going to have alot of locks being set and cleared on your server. Occasionally, Commonspot users run into situations where these locks get deadlocked and start timing out, bogging the server down.

Usually this is due to a unique situation involving load patterns or user behavior that Paperthin QA didn't catch, but telling you that that doesn't make you feel any better does it?

Today I got an email from someone having this very problem and I thought I would share my advice to him in case it comes in handy for someone else. Here's his question and my answer:

We are noticing an extreme number of lock errors in the CommonSpot code. "Error","jrpp-2","07/27/04","11:29:11","UDS_commonspot-users","A timeout occurred while attempting to lock appcommonspot-users. The specific sequence of files included or processed is: path/to/some/template.cfm This is happening very frequently and eventually causes our jrun process to either hang or go away. Random occurrences of each.

About your problem specifically, this is what I'd do:

1. Run CFStat on the server and look to see how many threads are running. You'll start to notice a pattern where locked threads pile up and the thread count increases. Once the lock breaks the thread count will drop back down to normal.
2. Once you think you can identify the pattern in cfstat, watch for a lock and run a series of stack traces during several locking incidents. MM has a KB article about how to do this if you've never done it before.
3. Once you have a few stack traces, look them up and down for commonalities. Eventually you'll find some common, um, spot where everything's locking up. You'll be able to tell form the trace what line of what file it is getting stuck on. This is great ammo for Paperthin support and may even give you a hint as to a setting you can tweak to make the problem go away.

Paperthin just released SP2 for Commonspot 4.0.

Also, if you landed here looking for help with Commonspot, make sure you sign up for the Commonspot email list at chattyfig!

Ran into an unusual problem last week while upgrading Commonspot 3.2 SP2 to a 3.2 SP4 and CFMX 6.0 to CFMX 6.1. Thought I'd drop it into the ole blog in case someone else runs into this problem. After the upgrade everything seemed fine except replication. Having dealt with a number of replication problems in the past I wasn't totally shocked by this, but the error wasn't one I'd seen before. In the application.log file, I uncovered the following: "Error","jrpp-47","05/19/04","10:29:38","CommonSpot","CFID, CFTOKEN contains invalid characters. This exception is caused by either broken links, or security attacks. The invalid id is 370db970662a6471%2D9D91146A%2D96A6%2DEFAB%2DDC215EC73B22393D The specific sequence of files included or processed is: /xxx/xxx/commonspot/sync/sync-process-requests.cfm" After decoding the URLFormatting of the string, I found that the invalid CFTOKEN being passed was 370db970662a6471-9D91146A-96A6-EFAB-DC215EC73B22393D. It's pretty apparent that this is a UUID with some sort of rouge data appended to the front of it. The reason that this might throw a ColdFusion error is somewhat documented in the following forum post by Christian Cantrell. From the looks of it, anytime ColdFusion gets a CFTOKEN or CFID value in a format that it doesn't expect, it blows up. In this specific case, it may have been because the CFTOKEN contained lowercase text, or perhaps because the format of the string was unexpected. Either way, it made CF break. So I knew why ColdFusion blew chunks, and just had to wait for Paperthin to get back to me on why Commonspot might have passed this CFTOKEN value during replication. Side note: For those who've not dealt with Commonspot's content replication before, it's essentially a process where an authoring server "replicates" approved content to one or more "target" content servers. There are a few choices on how to have Commonspot move the data, including FTP and HTTP (CFFTP and CFHTTP). The content to be replicated is zipped up and transferred to the target server, then unpacked and distributed to it's location in the database or file system. Back to the problem - I finally heard back from Paperthin about the root case of this issue. Turns out that Commonspot tracks CFTOKEN/CFID pairs within the replication process so that the repeated requests between the authoring server and target server(s) don't startup a buncha phantom sessions. Somewhere along the way, their tracking of the CFTOKEN got munged and the replication process started feeding the invalid value to the target server. This halted replication in it's tracks. Paperthin sent over a couple of patches to solve the problem, and I also ended up turning off the "Use UUID CFTOKEN" option in CFMX's admin. One of those two things fixed the problem, though I am uncertain which it was. Hopefully this little tidbit of information will help out someone else in the future...

As blogged by Ben Forta, Paperthin recently released version 4.0 of their CMS product, CommonSpot. As some may be aware - one of the sites I work with, PGA.com, uses CommonSpot. When Turner Sports Interactive (who manages PGA.com) first talked with the folks at PaperThin, we requested/suggested several features in the product. Two of these features were popular requests they had also received from other customers, and have been included as new features in version 4.0. XHTML Support - While older versions of CommonSpot work well in all browsers, they didn't come close to validating as proper XHTML. They've done alot of work towards producing valid XHTML, which isn't a small accomplishment when considering the complexity involved in the 4,000+ files in the CommonSpot application. Static Site Generation - Scaling a CommonSpot application out across several servers can get expensive when you consider the CF/CommonSpot licensing fees involved on the extra machines. Static site generation makes the product far more viable for sites with heavy traffic by allowing sites to be generated as static files and copied over a large number of webservers.