June 17th, 2001

  • weh

Client list updated

I've asked this question previously and found out why this wasn't working, but I wanted to see if with the new servers and everything it might be possible to begin updating the "clients used" list on the userinfo pages once again. Some newer users do not even have a client listed, and in the support area this could make some troubleshooting difficult if the user does not know how to check for their version of the LJ client.

Anyway, I was curious. Thanks for the help.

Mail loops

Read this bug report:
I just created an account to make into a community. As I have a paid account, I entered my LJ email address as its address, so any mail to this account would go to wherever my main account mail went. This is a handy feature, because it means that if I change my address, I only need to update my main account on LJ. I hope that made sense. OK, so the account creates fine, and I go to edit the profile, and fill in blah blah blah, and submit, and it won't let me use an address @livejournal.com I can see that people might have put an LJ address in mistakenly when they didn't have a paid account, but isn't there some other way around this? And if this validation is correct, shouldn't it do the same when you create an account? Sorry to bother you. Didn't seem like something support could help with.
What is the best option? The bad thing is we can have loops. User "bob" gets a paid account and lists "bob@livejournal.com" as his real email address, so where do we forward bob@livejournal.com mail to then?

Now, we could allow bob to list anything but bob@livejournal.com as his email address, but what if he uses bob2, and bob2 uses bob. Now we have a loop.

Should we not care and let the MTA deal with this, or should we put in some graph traversal code to check for loops whenever email addresses are created/modified?


Note to anybody keeping up-to-date with LiveJournal code in CVS: You need the LJHOME environment variable set whenever LJ code is run. This provides two benefits: 1) no paths hardcoded, and 2) you can run two separate servers on one machine. I use this to test both livejournal.com (livejournal cvs with ljcom on top) and a generic livejounal-only server.

Here are instructions on how to make sure LJHOME is set everywhere:

Apache:: http.conf
SetEnv LJHOME /home/lj

FastCGI apps: http.conf
FastCgiServer /home/lj/htdocs/users -processes 2 -initial-env LJHOME=/home/lj

Bash: ~/.bash_profile
LJHOME=/home/lj; export LJHOME

Crontab: (crontab -e)
LJHOME=/home/lj (at the top, before the cron lines)

Procmail: ~/.procmailrc
LJHOME=/home/lj (at the top, before the recipes)

This will be in the revised INSTALL documentation that I haven't done yet. I'll try to get a good release of the code out before I go on my roadtrip.


This is probably not of much interest to people, but I want a place to be able to point people in the future should I need to.

We now have two new tables: recent_logtext and recent_talktext. They are the same format as logtext and talktext but they use 4 byte pointers instead of 5 byte pointers. In other words, they're intended to always be under 4 GB in size.

Any inserts/updates happen to both tables.

recent_* are replicated to our dummy database slaves, but not logtext and talktext.

recent_* tables will be cleaned every night or so, removing everything older than a week.

Applications will no longer query logtext/talktext directly to get data... instead they'll go through an API which first tries recent_*, and if it doesn't get everything, then goes on and gets the remaining ones from the real tables (on the master database).

The whole point of this is to load-balance the database. Those two text tables are the biggest tables and cause by far the most disk activity and overall load on the database (especially since they contain variable-length records).

This should make cartman's job a ton easier.

Current Status:
config options: now in CVS, ljconfig.pl
recent_logtext writing: now in CVS, ljprotocol.pl
recent_logtext reading: not done
recent_talktext writing: not done
recent_talktext reading: not done
ljmaint script to clean recent_: not done

ljprotocol.pl is patched and in CVS to do the recent_logtext stuff.