Re: MasonHQ node caching, and other bugs

I did a simple test to illustrate the node caching problem. I created a 
new page; it got node_id 245. I would hit the Edit button over and over 
again, and each time add the next letter of the alphabet. If there was 
node caching, then after hitting Save 26 times, I would have the entire 
alphabet on a single page.

I checked after each save that what I typed in the form actually was put 
inside the database. That was indeed the case. I also noticed for each 
save, what the process id of apache was for the instance saving.

Here are the results.

mysql> select version_number as ver,sequence_number as seq,version_id as
id,content,created_time from wiki_versions where node_id=245;
+------+-----+------+---------------+---------------------+
| ver  | seq | id   | content       | created_time        |  Apache
+------+-----+------+---------------+---------------------+
| 1.0  |   1 | 1633 | a             | 2005-05-26 09:43:35 |  26213
| 1.1  |   2 | 1634 | ab            | 2005-05-26 09:43:59 |  26210
| 1.2  |   3 | 1635 | abc           | 2005-05-26 09:44:05 |  26210
| 1.3  |   4 | 1636 | abcd          | 2005-05-26 09:44:12 |  26210
| 1.4  |   5 | 1637 | abcde         | 2005-05-26 09:44:32 |  26210
| 1.5  |   6 | 1638 | abcdef        | 2005-05-26 09:45:57 |  26211
| 1.6  |   7 | 1639 | abcdefg       | 2005-05-26 09:46:04 |  26211
| 1.7  |   8 | 1640 | abcdefgh      | 2005-05-26 09:46:10 |  26211
| 1.8  |   9 | 1641 | abcdefghi     | 2005-05-26 09:46:45 |  26212
| 1.1  |   2 | 1642 | aj            | 2005-05-26 09:47:07 |  26213
| 1.5  |   6 | 1643 | abcdek        | 2005-05-26 09:48:11 |  26210
| 1.8  |   9 | 1644 | abcdefghl     | 2005-05-26 09:48:57 |  26211
| 1.9  |  10 | 1645 | abcdefghim    | 2005-05-26 09:49:21 |  26212
| 1.2  |   3 | 1646 | ajn           | 2005-05-26 09:49:46 |  26213
| 1.6  |   7 | 1647 | abcdeko       | 2005-05-26 09:51:43 |  26210
| 1.7  |   8 | 1648 | abcdekop      | 2005-05-26 09:52:02 |  26210
| 1.9  |  10 | 1649 | abcdefghlq    | 2005-05-26 09:52:26 |  26211
| 1.10 |  11 | 1650 | abcdefghimr   | 2005-05-26 09:53:07 |  26212
| 1.11 |  12 | 1651 | abcdefghimrs  | 2005-05-26 09:53:15 |  26212
| 1.3  |   4 | 1652 | ajnt          | 2005-05-26 09:53:49 |  26213
| 1.4  |   5 | 1653 | ajntu         | 2005-05-26 09:53:58 |  26213
| 1.8  |   9 | 1654 | abcdekopv     | 2005-05-26 09:54:36 |  26210
| 1.9  |  10 | 1655 | abcdekopvw    | 2005-05-26 09:54:49 |  26210
| 1.10 |  11 | 1656 | abcdefghlqx   | 2005-05-26 09:55:12 |  26211
| 1.11 |  12 | 1657 | abcdefghlqxy  | 2005-05-26 09:55:17 |  26211
| 1.12 |  13 | 1658 | abcdefghlqxyz | 2005-05-26 09:55:22 |  26211
+------+-----+------+---------------+---------------------+
26 rows in set (0.04 sec)

mysql>

I manually added the apache process id's to the right of mysql output.

This example clearly illustrates that each apache instance seems to keep 
it's own mind about what is the latest version, rather than consult the 
mysql database.

Viewing a page is no better. Both htdocs/node/view.html and 
htdocs/node/edit.html get whatever version apache thinks is the latest 
version, regardless of what's inside the database.

By debugging inside MHQ code, I can see that 
MHQ::Wiki::Node->latest_version does not get called for every request. And 
even when it does, $self->_latest_version_id_accessor(@_) still returns 
the wrong information. I cannot say for sure, but to me it seems caching 
happens all the way down in Class::DBI and that's where I start to loose 
track.

As a desperate attempt I inserted $node->update frequently in the code, 
but it did not help.

I have tried to reproduce this on http://www.masonhq.com/ but same problem 
does not seem to occur there, unfortunately.

If it matters, here are some version numbers:

   mysql 4.1.12
   apache 1.3.33
   mod_perl 1.129
   MHQ 2005-05-23

Please let me know if you have suggestions for debugging further.

Soren


-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click