Wednesday, October 1, 2008

Issues with purging Client variables data store in ColdFusion

In short: CFMX seems not to do much regarding database purging of client variables. You'd probably need to do manual purge of data from these tables to avoid funny application errors (if your application uses client variables).

Here's the long story:

We have been using client variables on our CFMX7 project for quite some time. They are stored in a database (MSSQL). CF admin is configured to purge these at 48 hours intervals. Since it worked fine for many months I never bothered to check whether the purge actually happens until we've encountered some rather weird problems recently.

The basic issue was that emails that CF would generate would no longer be sent. A day before they were running just fine. Looking at exception.log file I'd notice that there were lots of Smtp-related authentication problems of some sort. Mail sending process reads client-scoped variables for username/password to be used for email sending (they are read from the application database and then stored in client variables while this process runs). I've verified that the mail server and the application settings are all good - they use proper username/passwords and the rest of it.

The log file of the application nicely says that the emails are generated for sending and they are queued for sending. On the mail server side I see it complains that the attempt to send the mail is not authenticated and we need to reconfigure our client sending application.

Finally, when I looked at the [CFMX ROOT]/Mail/Undelivr folder where unsent mails are stored, I spotted (at the top of the mail file) the username+password+mail server string that typically looks like: username:password@servername:port. In the case of undelivered mails they were showing some really old email settings + password (I later verified that the password changed for this other email account which would explain why sending stuff via that email account would not be properly authenticated).

The only place where these values come from are the client variables and it dawned on me that we could be using some old client variables once I saw that the database tables where they are stored had around 90,000 rows in them. Looked like no one was purging the database and I'm guessing the unique identifier (CFTOKEN) must have been duplicated at a later time and ended-up reading values from way before.

After deleting all the records from the client database store things started working again.

No comments: