• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

Client Variable size limit issue

Explorer ,
Jan 10, 2008 Jan 10, 2008

Copy link to clipboard

Copied

It appears that we've run into a problem with a 4K limit on the size of a client variable when stored in the registry. You can create the variable larger than 4K, but when you go to read them back out their gone (their still in the
registry if you poke around with regedit, but CF acts like their not there). I've not performed extensive testing,
but the following scenario is what we ran into:
Page 1: Set some client variables, do a cfheader tag with the location parm of Page 2 and a browser redirect (302)
Page 2: cfdump the client scope.

When you have all client variables <4096 characters in length, everything is fine. If one or more client
variables >= 4096 characters, none of the variables set on Page 1 are shown in the cfdump. Using regedit,
the client variables do exist with their proper contents.

I couldn't find anything in the knowledge base or forums which talked about a size limit when storing
the client variables in the registry, so I'm considering this a bug. Anyone else run into this?
TOPICS
Advanced techniques

Views

1.0K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Explorer , Jan 11, 2008 Jan 11, 2008

quote:

Of course, that makes one wonder why it is the default selection for client storage


Yes, doesn't it.


Votes

Translate

Translate
Mentor ,
Jan 10, 2008 Jan 10, 2008

Copy link to clipboard

Copied

I would recommend against ever using the registry to store your client variables. Use cookies or a database.

Phil

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Jan 10, 2008 Jan 10, 2008

Copy link to clipboard

Copied

Cookies have a stated limit of 4K so this isn't an option (plus a lot of transfer overhead).
The Registry has it's place and unless you are dealing with a lot of traffic (which we're
not), it is a valid option. Saying never to use it for client variable storage ignores some
perfectly legitimate reasons for doing so.

I hate absolutes!

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Jan 10, 2008 Jan 10, 2008

Copy link to clipboard

Copied

I was able to duplicate your problem using CF8 in Windows XP. It may be an issue with Windows rather than just a ColdFusion error since it's throwing a 234 error. You can test this by trying to grab the client variable with the cfregistry tag and dumping the catch

I'd certainly suggest moving your client storage to a database rather than the registry. Here's a link to a techNote that may be of help:

ColdFusion 4.5.1 SP2 and Up: Recommended settings for client variable storage
http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_17919&sliceId=1

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Jan 10, 2008 Jan 10, 2008

Copy link to clipboard

Copied

Thanks for taking the time to duplicate the problem. I've considered using the database
for the client variables and may go that route as an interim solution. The longer term
solution is to redesign things so I don't need to hang onto so much data as a client
variable in the first place! I would be curious if Adobe considers this a bug or just
trying to exceed an undocumented limit.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Jan 10, 2008 Jan 10, 2008

Copy link to clipboard

Copied

Regardless of how much data you're keeping in the client scope, it is a well-known best practice to move client vars out of the registry and into a database of some kind.

Using the registry for client variable storage is almost never a good idea. It's not scalable, it has serious limitations, and after a while it will slow your server down to a crawl.

You can usually get away with it on really small web sites, or a local test environment...but for any true production web site, the database is the #1 recommended storage location for client vars.

If you google around for a bit on the subject you'll see what I mean.

Best of luck with it!

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Jan 11, 2008 Jan 11, 2008

Copy link to clipboard

Copied

Just to second (third... fourth...) everyone else's commment about the
registry not being a very good place for client vars,under any
circumstances.

Once upon a time I had to reinstall my dev laptop because the volume of
client variables accumulating in the registry swapped it, and caused the
registry to die. It was sufficiently dead that I could not actually clear
the rubbish out (nor do anything else which required writing to the
registry). And this is an enviroment in which we really don't use client
variables for much, but what went in was never cleared properly.

Now... this was on an older version of CF (6.1, probably), and maybe this
has been sorted in the interim. But "once bit, twice shy" as the addage
goes; I've never revisited the situation, instead always using a DSN
instead.

For your purposes, I would not be storing any actual DATA in your client
variables, I would simply be storing a key to identify the user. And
storing the data relating to the key in the DB. This prevents
out-of-control growth of the client variable.

--
Adam

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Jan 11, 2008 Jan 11, 2008

Copy link to clipboard

Copied

Don't get me wrong, I GET using an external database for client variable storage. I've read the best practice guides and agree with them. What I disagree with is that using the registry has no place. I've been developing CF applications since O'Reilly was giving it away for free with their webserver (I bet few people remember those days :). Most of my applications are intranet apps for companies where were talking no more than a few hundred unique users and a relatively low level of activity when compared to popular Internet sites. When the registry cleanup process is set properly, and the registry is sized appropriately, for SOME applications it IS a perfectly legitimate choice. The registry is a database is it's own right and just like any other data repository (and yes, I've been a DBA working on hierarchical, network, and relational databases with millions of transactions a day so I understand databases 🙂 it needs to be managed correctly.

Trying to get this thread back on track, IF one chooses to use the registry for client variable storage, Adobe should either work to correct this bug or at least document that 4K is the size limit.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Jan 11, 2008 Jan 11, 2008

Copy link to clipboard

Copied

I know what you're saying editcorp, but don't most web sites have a database available anyways? I could understand the argument if for some reason you were working in a restricted environment where no database was available. But if you have a database available to you, I don't see why someone would ever opt for the registry over a real DBMS. Why take the stairs when there's a perfectly good elevator? :)

In any event, I know how frustrating it can be when you trip over an undocumented limitation in a software feature...but I highly doubt this limitation is anywhere on Adobe's radar to fix, or document. Coming from a software company myself, I know how quickly these low priority issues can fall off the radar.

The truth is most people don't use the registry for client variable storage, for reasons that we've already covered. And for the small number of people that are, they certainly aren't going to be storing 4K+ worth of data per client. Generally speaking, anyone that is *heavily* using client vars is going to be wise enough to store them in a database.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Mentor ,
Jan 11, 2008 Jan 11, 2008

Copy link to clipboard

Copied

quote:

Saying never to use it for client variable storage ignores some perfectly legitimate reasons for doing so


Tech Note: Troubleshooting client variable issues on Windows

There are many variations of hangs on production systems related to client variable use with the Windows Registry. The Windows Registry is not supported for production applications.

Tech Note: Deleting client variables stored in the Registry

By default, ColdFusion stores client variables in the Registry. This can cause performance degradation in high-traffic sites as the Registry will increase considerably in size, causing ColdFusion server instability. Macromedia recommends storing client variables in an enterprise RDBMS.

Tech Note: Debugging thread dumps and server problems...

Registry client storage should never be used for production systems but often developers fall into this by accident by not explicitly specifying a data source (and the ColdFusion admin defaulting to "REGISTRY"). Since the registry isn't a real database, ColdFusion has to retrieve the entire registry client tree (high memory usage) and compare the date/time one at a time to decide whether to purge a record. This is a CPU-intensive operation with an hourly purge that may only delete a few records.

Sometimes never does mean never. Of course, that makes one wonder why it is the default selection for client storage.... You seem to believe that you have a legitimate reason to use the registry, so I guess that you are willing to live with the consequences.

Phil

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Explorer ,
Jan 11, 2008 Jan 11, 2008

Copy link to clipboard

Copied

LATEST

quote:

Of course, that makes one wonder why it is the default selection for client storage


Yes, doesn't it.


Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
Documentation