Caching problem

I know we have a caching problem. I suspect I know the cause.

The symptoms of the problem are:

  1. a commit has been processed by the system.
  2. the commit can be viewed via the URL /commit.php?message_id=MESSAGEID
  3. the commit can be seen via index.php or date.php
  4. the commit cannot be view on the port page

I think I found the cause of the problem tonight. tlp reported that this commit on vim had not appeared in production, but was present in beta.

I checked the FreshPorts processing logs for that commit and found indications that the log had been cleared out. However, the cached HTML did not contain the new commit.

The processing log contained a clue, as demonstrated by this extract:

Observer has noticed that ports for 200606261821.k5QILd6m004747@repoman.freebsd.org have been refreshed.
# # # # Updating ports_vulnerable table # # # #

port = editors/vim, port_id = '6166', category_id='1'
$sql='select PortsVulnerabilityCountAdjust(6166) as count'
# # # # done updating ports_vulnerable table # # # #

# # # # Removing ports from the cache # # # #

editors/vim

# # # # Finished: Removing ports from the cache # # # #

adding that commit date to the daily summary refresh list
sql = select DailySummaryDateAdd('2006-06-26');
No errors found during that commit


 *** end of all updates ***
Observer has noticed that processing has finished.
 now is the commit:
EOF

You can see that the entry was removed from the cache. I think the cause of the problem is one of timing. The cache is being cleared before the commit is done. I think the cache must be cleared after the commit. I’m not sure if this is the actual cause of the problem or if it’s something much more complex. Regardless, this must be changed. There is a window of opportunity for error. Time to close it.

Website Pin Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google StumbleUpon Premium Responsive

Leave a Comment

Scroll to Top