?

Log in

No account? Create an account
January 11th, 2002 - LiveJournal Development — LiveJournal [entries|archive|friends|userinfo]
LiveJournal Development

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

January 11th, 2002

$LJ::READONLY [Jan. 11th, 2002|03:16 am]
LiveJournal Development

lj_dev

[mart]

Patch created.

When $LJ::READONLY is set on in ljconfig.pl, the most commonly-accessed features which require database writes are disabled in some form. In most cases, this comes in the form of removing the auth fields and replacing them with a message saying the site is down. There are some special cases...

  • talkread.bml loses some buttons from its @linkele (the blue bar thing) which link to things which require database writes.
  • The reply links on talkread.bml vanish, the first of which being replaced by a message explaining why.
  • The delete links on comments vanish.
  • talkpost.bml refuses to output anything bar an error message.
  • The protocol handler returns a warning to clients at login, and error messages when commands are executed which do database writes.
  • A little blurb goes on the front page.
  • The support section loses the links to post a question and read questions (since you can't answer them right now anyway)

In addition to these, I also recommend the following changes to ljcom, which I don't do...

  • Disable all of the stuff about paid accounts. It won't be nice if people try to buy paid accounts when the site's read-only and LiveJournal ignores the acknowledgement from paypal.
  • Edit the dystopia BML scheme to display a small warning somewhere and also remove links to the main things which will require database edits.

The modification to LJ::auth_fields is a hackish catch-all I just threw in to cover anything else in some way, relying on the fact that we never use auth fields for anything which doesn't edit stuff. At some point when readonly checking is added everywhere, that stuff should be removed because it doesn't really belong there.

I also fixed up some HTML to be well-formed XML but not everywhere.

linkpost comment

Error upon 'cvs update' [Jan. 11th, 2002|02:01 pm]
LiveJournal Development

lj_dev

[lucretio]
When I try to use 'cvs update' on my goathack, I'm getting this error:

lucretio@goathack:~/cvs/livejournal$ cvs update
cvs [update aborted]: connect to danga.com(66.150.15.140):2401 failed: Invalid argument


Something else: When I go to http://www.danga.com, it looks like http://goathack.livejournal.org. Was there some sort of switcheroo?
link3 comments|post comment

PATCH: count invitation codes [Jan. 11th, 2002|02:24 pm]
LiveJournal Development

lj_dev

[lucretio]
Yes, invitation codes should be going soon, but this is a very minor, small patch.

Working from this suggestion, I added code to invite/index.bml to display the number of codes. They were already being counted, so I just made a count of unused codes, and displayed both.

http://goathack.livejournal.org:8030/patches/2002-01-11-codecount.diff
link10 comments|post comment

Is this a known bug? [Jan. 11th, 2002|04:06 pm]
LiveJournal Development

lj_dev

[teedz]
[Note: I'm using mozilla on linux, I haven't yet tested it in Netscape]

1. Create a new journal, while logged in as your current account.
2. Verify this journal via the email URL
3. Go to the user menu and Click "Your Settings | Personal Info"
4. At the confirmation screen, rather than hitting "Proceed", select "click here"
5. Login as new account.
6. In the Edit Personal Info page; Note that all information displayed is for new account; Go down to "Your Picture".
7. Click "Go here" to add/create a new one.
8. On the Upload Picture page, submit an image From File; Click "Proceed".

Expected Result: 'Upload Picture' page gives the name of the new account (the one you are editing) in the 'Username' dropbox; Image can be uploaded for new account.

Current Result: Your original (main) username[s] appear in the 'Username' dropbox. Furthermore, uploading an image using the preselected (main) username is not challenged -- image is uploaded to original account, rather than new LJ account.


I dunno if this is a downright bug, or "the way things work", but it's certainly misleading.
link10 comments|post comment

Conversion: Take 3 [Jan. 11th, 2002|07:27 pm]
LiveJournal Development

lj_dev

[bradfitz]
History:

Plan 1: I knew conversion of the data would take awhile, but didn't know how long. I wrote the conversion code and ran it on my test machine. A few seconds and it was done. Ran it on a copy of the real database.... whoa, this is going to take weeks.

Plan 2: Did a billion things to make the conversion quicker. Kept working on this for about a week, each day making it faster. Timed it on a fraction of the real database. A full conversion without even the logtext/talktext tables would take several days. I figured we'd do the *text tables on demand, as previously mentioned. Even with the read-only operation of livejournal running while the database was converting, people would get angry after 76 hours of read-only downtime.

Third time's a charm: We convert nothing immediately. I'll have to alter user (a few minutes), memorable (a few seconds), and topic_map (a few milliseconds). A new column in user says what cluster they're on (this was already planned). But instead of cluster "0" meaning "the first cluster", it'll now mean "no cluster... the old tables". The tables that clustered data store into will be called log2, logtext2, talk2, talktext2, talkprop2, etc. Those can coexist in the same database as the old tables.

In ljconfig.pl where we define clusters, cluster 1 will be on the same host for now, and we'll convert a user at a time. Here's how that'll happen: a new capability class named "in conversion" is allocated (bit 6 is free?), with a class capability of "readonly = 1". All the code should check if that user's readonly cap is set. If so, don't allow writes, because some other process is the middle of moving the user's stuff all around. At the end of that user's move, the clusterid is changed, and then the capability class bit is turned off, and then all the old stuff is deleted from the previous cluster (or cluster 0, as in the case of a conversion from non-cluster).

Advantages:
  • No global downtime. Each user will have a bit of downtime (proportional to their amount of data), but everything else still works during that time.
  • No code fork. We won't need the pre-cluster code and post-cluster code. (I don't need to learn more CVS crap! hooray!)
  • No double copying. Before we would've needed to 1) convert everything, and then 2) copy everything to their destination cluster. Now we can do the conversion and copying to destination cluster at the same time.
Questions / Objections / Brilliant foresight / Fellatio offers?
link17 comments|post comment

CVS Back [Jan. 11th, 2002|10:20 pm]
LiveJournal Development

lj_dev

[bradfitz]
CVS server is back and better than ever.

Happy anonymous checkin'-outin' !!

(the reason it went down is because I rebuilt Marklar the other day.)
linkpost comment

navigation
[ viewing | January 11th, 2002 ]
[ go | Previous Day|Next Day ]