10 Replies Latest reply on Jan 11, 2008 8:36 AM by editcorp

    Client Variable size limit issue

    editcorp
      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?
        • 1. Re: Client Variable size limit issue
          paross1 Level 2
          I would recommend against ever using the registry to store your client variables. Use cookies or a database.

          Phil
          • 2. Re: Client Variable size limit issue
            editcorp Level 1
            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!
            • 3. Re: Client Variable size limit issue
              c_wigginton Level 1
              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
              • 4. Re: Client Variable size limit issue
                editcorp Level 1
                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.
                • 5. Re: Client Variable size limit issue
                  Grizzly9279 Level 1
                  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!
                  • 6. Re: Client Variable size limit issue
                    Level 7
                    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
                    • 7. Re: Client Variable size limit issue
                      editcorp Level 1
                      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.
                      • 8. Re: Client Variable size limit issue
                        Grizzly9279 Level 1
                        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.
                        • 9. Re: Client Variable size limit issue
                          paross1 Level 2
                          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
                          • 10. Re: Client Variable size limit issue
                            editcorp Level 1

                            quote:

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


                            Yes, doesn't it.