Forum OpenACS Development: xowiki crashes

Whenever I add pages, the server crashes with no warning.
/?object%5ftype=%3a%3axowiki%3a%3aPage&edit%2dnew=1&return%5furl=%2farticles%2fadmin%3fobject%255ftype%3d%253a%253axowiki%253a%253aPagehttp://jongriffin.com/articles/?object%5ftype=%3a%3axowiki%3a%3aPage&edit%2dnew=1&return%5furl=%2farticles%2fadmin%3fobject%255ftype%3d%253a%253axowiki%253a%253aPage
is the url.

This is cvs head xowiki and xotcl-core. latest xotcl.

I get no debugging information, just a hard crash.

This was the last command before restart:
timing 1600 nsdb0 0or1row dbqd.acs-tcl.t
cl.defs-procs.ad_parameter_cache.select_parameter_value

This is a fresh install of OACS, but it also crashed on update.

Hmm...looks like Gustaf knows this is broken. From /xowiki/tcl/xowiki-form-procs.tcl:

  WikiForm instproc update_references {} {
    my instvar data
    if {![my istype PageInstanceForm]} {
      ### danger: update references does an ad_eval, which breaks the [template::adp_level]
      ### ad_form! don't do it in pageinstanceforms.
      $data render_adp false
      $data render -update_references
    }
    # delete the link cache entries for this item 
    # could be made more intelligent to delete entries is more rare cases, like
    # in case the file was renamed
    my instvar folder_id
    ##### why is ns_cache names xowiki_cache *pattern*   not working??? 
    ##### upgrade ns_cache from CVS !
    foreach entry [ns_cache names xowiki_cache link-*-$folder_id] {
      array set tmp [ns_cache get xowiki_cache $entry]
      if {$tmp(item_id) == [$data set item_id]} {
        ns_cache flush xowiki_cache $entry
      }
    }
    if {![$data istype ::xowiki::Object] &&
        ![$data istype ::xowiki::PageTemplate] } {
      ::xowiki::notification::do_notifications -page $data
    }
  }

This error occurs with version 1.5 of nscache which is in cvs with aolserver 4.0.10 and thus presumably the most up to date. Gustaf, while ns_cache isn't working when passed a pattern, how should this be fixed so that we don't slam into an error?

Gustaf, the version of ns_cache you recommend is UNRELEASED. We can't be distributing OpenACS requiring folks to get the basic prerequisites from CVS.

Until someone actually releases a new version of ns_cache that actually supports this feature, it makes sense to write code that will work without it.

Xowiki cannot be included in .LRN, for example, until we have an "official" ns_cache that supports the pattern agrument. Insiting on this kind of thing is why it is so hard to get OpenACS working. For you, getting ns_cache with a one-line change from CVS is no problem, me neither, but expectig a new user to hunt and find every little piece in a different place is not good.

I use the debian packages for AOLserver and the AOLserver modules and that version of ns_cache does not support the pattern argument either.

I asked before on the AOLserver list but noone seems interested in making the latest ns_cache available. If someone could do that it would be great.

Dave,

Vlad Seryakov was the last one working on ns_cache https://openacs.org/forums/message-view?message_id=51200 and made it available from the following site ftp://ftp.crystalballinc.com/pub/vlad/nscache.tar.gz

We can't be distributing OpenACS requiring folks to get the
basic prerequisites from CVS.

As Stan points out, we do this already. Our official installation notes say "get ns_cache from cvs". The automated installation script from Malte gets if from cvs as well.

So, if only debian is using the old version, would it not be best to point the debian maintainer to the oacs-installation guide and ask him/her to upgrade the debian package accordingly?

-gustaf
PS: there is active work improving ns_cache in the naviserver project.

Concerning the naviserver: yes, it is a pity, it went this way. I have high respect for the naviserver developers, they had good reasons for doing this. Things look different, if your companies product depend on low-level functionality of the server. Btw, Their latest release is 4.99.1.

concerning ns_cache: if one has to iterate over a couple of hundred entries in tcl, this is certainly slower than doing this in C. For the same reason, many tcl commands (array, info vars/commands...) have a pattern argument. For toy installations, you are right, the difference won't be noticed.
It is no rocket science to program around this problem (used so far only on two places), and it should be possible to use the c-version where available and the tcl version, where not. however, i would think, upgrading the debian distro would be even less work.

I do not believe, that Jon's problem is related with ns_cache.

Gustaf,

Ok, i guess you are right, if the list is big, in the real world, there could be a real performance impact.

Malte,

Yes, I fear we will have to distribute an "approved" AOLserver package from openacs.org to let people get the software they need without jumping through hoops. Hopefully we can get enough volunteer effort to commit to doing this into the future if we have to.