I created a new version of lazy site node caching which roughly follows what I have been describing. Remaining issues are though:

a) Unnecessary hits to the database. Due to the fact that files can reside under /packages/acs-subsite/www and be mounted under that package, we always hit the database unless we would announce for the / that we loaded all children. Which excactly is not the purpose of lazy caching. So the occasional hit to the DB is in there. Same is true for directories under /www.

To solve this issue I have come up with a list of reserved names under / which will not trigger a trip to the database. At the moment these are the usual suspects "resources images image x o file admin". As this is a list of names you are not allowed to use when mounting a package, maybe we can get this list complete and also make sure that noone comes with the idea of mounting a package with that name in the first place?

b) Much more testing needed. I have it now on a busy production site, but this is using acs-subsite a lot and does not make use of dotlrn. So maybe someone with a busy .LRN site could test it again? Also I'm not sure if all the issues reported by Gustaf have been fixed.

The first one is really strange. It should find the images no problem. What are the links to these images? And did you use the latest version from HEAD (as I initialize all non subsite packages)? Your error message does not indicate that .

Furthermore, run the server in Debug mode. THis will help much more in getting to the root of the problem. As for the portal stuff, please find out where the code with "cn't read node(url)" is actually comming from, which procedure was called where that tried to find the node.

Emma, thanks for this information. I guess it really is time for a cleanup . If you have time that would be wonderful, especially as I don't have a larger .LRN installation on which to test this.

Hi, Emma!

Thanks for the work!

I have put the code in our development environment but I got
the next problem:

When I add one applet to one community appears Ok
but when you click the url of the new applet (in admin)
you get the error:

The requested URL was not found on this server.

When you restart Openacs, the url is working.

Regards,
Agustin

Agustin, Malte,

I've tested again. Here are the steps I followed:

- Standard install of dotlrn from HEAD
- created a new community
- went to calendar index page of the new created community: page displayed
- went to the admin index page of calendar in the new created community: File not found
- reload the page: page displayed
- went to the admin index page of forums in the new created community: File not found
- reload the page: page displayed

There are no error messages in logs.

Note: Same occurs in Openacs when I mount an application, users pages are correctly displayed but I get a "file not found" the first time I go to the admin page of the application.

After that, I've replaced acs-tcl/tcl/site-nodes-procs* with the last revision of oacs-5-3 branch and followed the same steps:

- created a new community
- went to calendar index page of the new created community: page displayed
- went to the admin index page of calendar in the new created community: page displayed
- went to the admin index page of forums in the new created community: page displayed

..well.. fixed the notes problem anyway.

After re-installing the db using the oacs-5-3 version of site-nodes-procs* (to rule out any residual side effects), I see this:

/api-doc/ file not found
/api-doc/index file not found
/api-doc/index? the usual page shows up.


but that probably doesn't help much for test cases with the current code.

Am trying again with current cvs, since there appears to be some recent changes in those files..

Torben,

By current version, do you mean 5.3?

I have the "file not found" problem but with HEAD code, not with 5.3 one.

Though I need to work on a lot of things for the next release of OpenACS (acs-mail-lite being the primary culprit) and ]po[ (upgrade to latest OpenACS version), please post *any* issues you have with the HEAD version of site-node caching here (I am not subscribed to bug-tracker, sorry...). Just make sure you run off the latest version from HEAD.

Thanks Malte. Seems to work fine now.