Forum OpenACS Development: XoTCL Issue with ]po[ on OpenACS 5.6 - Very slow because of "ns_ictl update"

Hi,

We've got an issue here when updating ]po[ to OpenACS 5.6.
After every page we get tens and hundreds of calls to:

db_string dbqd..check_att {select 0 from acs_attributes where
attribute_name = :column_name and object_type = :object_type}

in ::xo::db::Attribute.

I created an error in the line and was able to track down "ns_ictl update" as the highest level of the call.

Does anybody know why "ns_ictl update" is called and why this procedure apparenty tries to reload all object attributes?

Thanks in advance!
Frank

Hi Gustaf,

Thanks for your reply. I changed the config.tcl file to the one provided with OpenACS 5.6 and now the interpreter issue is gone, thanks!

However, we've got another issue now with XoWiki:

Cannot create object -- illegal name '::'
    ::xowiki::Object ::xotcl::Class->create
    invoked from within
"::xowiki::Object create ::$folder_id"
    (procedure "require_folder_object" line 33)
    ::52670 ::xowiki::Package->require_folder_object
    invoked from within
"my require_folder_object"

I've already seen your answer to a previous questions on that and I have run ::xowiki::fix_all_package_ids here, but without success. There are still cr_revisions without package_id here.

The system I'm running on has been recently upgraded from OpenACS 5.1 (as all of our ~3.000 customers will have to upgrade their system...). So maybe the XoWiki behaviour is due to an upgrading issue? The Content Repository had some upgrade flaws anyway, Malte has written about that previously here.

Here are my preliminary findings about fix_all_package_ids:

• ::xowiki::Package instances returns only the "xowiki" package
• There are no cr_folder with name 'xowiki: xxx' (see below).

I can provide you with SSH credentials if you want to take a closer view...

Thanks in advance!
Frank

po40demo=# select f.*, c.name from cr_items c, cr_folders f where c.item_id = f.folder_id;
 folder_id |    label     |               description                | has_child_folders | has_child_symlinks | package_id |        name
-----------+--------------+------------------------------------------+-------------------+--------------------+------------+--------------------
      -200 | Templates    | Templates which render the pages go here | f                 | f                  |            | templates
     51569 | Email_Images |                                          | f                 | f                  |            | Email_Images
     11968 | Wiki Folder  |                                          | f                 | f                  |      11967 | 11967
     25892 |              |                                          | f                 | f                  |      25884 | bug_tracker_25884
      -400 | Trash        | Deleted content items get put here       | f                 | f                  |            | trash
      -100 | Pages        | Site pages go here                       | t                 | f                  |            | pages
     52526 | File Storage |                                          | f                 | f                  |      52511 | file-storage_52511

Hi Gustaf,

changing the config file

That is right, the problem existed already before changing the config file.

In my development server I am using the versions:

xotcl-core: 0.117
xowiki: 0.118

I got these versions by checking out the OpenACS 5.6 tree...

Cheers!
Frank

I tracked an error a couple of weeks ago and have a fix in 01-attribute-procs.tcl as the code was reloading the element information (attribute metadata) which was unnecessary. This might contribute to some of the issues you are seeing.

This being said I do agree with Gustaf that something else is wrong in your setup, as in five installations of mine we don't have the number of calls you describe and it does not slow us down at all using the db tracker of developer support bar.

As discussed in private, you should probably remove the code for object creation from intranet-dynfields as your stock po does not rely on any of the xotcl related extensions. I will maintain the xotcl-dynfields package as well as xotcl-search (filter based search for object types taken from intranet-contacts) and will take a look if your problem shows up in any of the other sites we implement now and in the future.