Forum OpenACS Development: xowiki crashes

Collapse
Posted by Jon Griffin on
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.

Collapse
2: Re: xowiki crashes (response to 1)
Posted by Stan Kaufman on
Weird. With an oacs-5-2 install plus xotcl 1.5.2, xotcl-core 0.44 and xowiki 0.37, adding a page here doesn't crash the server but does generate this error:

wrong # args: should be "ns_cache names cache"
    while executing
"ns_cache names xowiki_cache link-*-$folder_id"
    (procedure "update_references" line 16)
    ::xowiki::f1 ::xowiki::WikiForm->update_references
    invoked from within
"my update_references"
    (procedure "new_data" line 7)
    ::xowiki::f1 ::xowiki::WikiForm->new_data
    invoked from within
"::xowiki::f1 new_data"
    invoked from within
"set item_id [::xowiki::f1 new_data]"
    ("uplevel" body line 1)
    invoked from within
"uplevel #$level $new_data"
    ("1" arm line 1)
    invoked from within
"switch $errno {
                    0 {
                        # TCL_OK
                    }
                    1 {
                        # TCL_E..."
    (procedure "ad_form" line 612)
    invoked from within
"ad_form -extend -name [my name]  -validate [my validate]  -new_data $new_data -edit_data $edit_data -on_submit $on_submit  -new_request $new_request -..."
    (procedure "generate" line 45)
    ::xowiki::f1 ::Generic::Form->generate
    invoked from within
"::xowiki::f1 generate -export [list [list return_url $return_url]]"
    (procedure "edit" line 57)
    ::xotcl::__#04 ::xowiki::Page->edit
    invoked from within
"$page edit -new true"
    (procedure "edit-new" line 6)
    ::11922 ::xowiki::Package->edit-new
    invoked from within
"$object $method"
    (procedure "call" line 6)
    ::11922 ::xowiki::Package->call
    invoked from within
"my call $page $method"
    (procedure "invoke" line 8)
    ::11922 ::xowiki::Package->invoke
    invoked from within
"::$package_id invoke -method $m"
    invoked from within
"::$package_id reply_to_user [::$package_id invoke -method $m]"
    (file "/web/oacs52/packages/xowiki/www/index.vuh" line 21)
    invoked from within
"source [ad_conn file]"
    (procedure "rp_handle_tcl_request" line 3)
    invoked from within
"$handler"
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
                $handler
            } ad_script_abort val {
                # do nothing
            }"
    invoked from within
"rp_serve_concrete_file [ad_conn file]"
    (procedure "rp_serve_abstract_file" line 60)
    invoked from within
"rp_serve_abstract_file "$root/$path""
    ("uplevel" body line 2)
    invoked from within
"uplevel $code"
    invoked from within
"ad_try {
            rp_serve_abstract_file "$root/$path"
            set tcl_url2file([ad_conn url]) [ad_conn file]
            set tcl_url2path_info..."

    * I
Collapse
3: Re: xowiki crashes (response to 2)
Posted by Stan Kaufman on
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?

Collapse
4: Re: xowiki crashes (response to 3)
Posted by Gustaf Neumann on
See the 2nd line of the comment: get an update of ns_cache. ns_cache supports the pattern since more than 2 years

cvs -z3 -d:pserver:mailto:anonymous@aolserver.cvs.sourceforge.net:/cvsroot/aolserver co nscache

Jon:
The crash indicates most likely a mixup of different tcl versions used for different aolserver modules. Since you
have a fresh installation, be sure to point to the tcl version explicitely.

As well, i would recommend to run xowiki/admin/test
-gusaf

Collapse
5: Re: xowiki crashes (response to 1)
Posted by Dave Bauer on
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.

Collapse
6: Re: xowiki crashes (response to 5)
Posted by Stan Kaufman on
Actually, the install docs do say to use CVS to get aolserver as well as nscache and other modules. For some reason, during this install I just grabbed tarballs from sourceforge; guess I thought that the latest ones would work -- but that obviously isn't the case for nscache. Anyway, with the cvs version, all is sweetness and light again.
Collapse
7: Re: xowiki crashes (response to 5)
Posted by Gustaf Neumann on
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.

Collapse
8: Re: xowiki crashes (response to 1)
Posted by Dave Bauer on
Gustaf,

Why is "Naviserver" working outside the rest of AOLserver community? There isn't any reason that work can't be done in the AOLserver CVS. If you ask for commit, you get it, that is historically what I have seen.Also have they actually released someting? Let's remember most people want software that works, not that is a changing target.

I just see this as one of the big problems with OpenACS overall. Unfinished work, some code is frm CVS, some from different places, etc. Perhaps we should package our own AOLserver too? What is a solution to make it simple and easy to install? Whatever we have right now is wrong.

I see it as a problem that our documentation says to get ns_cache from CVS. Except for xowiki, there was never a reason to get it frm CVS. The only change is the tiny one to support the pattern argument. That is incredibly easily worked around using lsearch. I seriously doubt there is any real performance difference between using lsearch and the search ns_cache does.

I guess this is a different discussion, I hope Jon can get his site working correctly, and I am sorry I don't know what the answer is to his problem.

Collapse
9: Re: xowiki crashes (response to 8)
Posted by Gustaf Neumann on
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.

Collapse
10: Re: xowiki crashes (response to 8)
Posted by Malte Sussdorff on
Dave, the unreliabilty of software packages, downloads, CVS on sourceforge and so on resulted in me packaging up AOLserver4.5 with an install.sh which sets up everything for OpenACS. It includes unreleased code, but if noone is going to officially release it then it is better to use the code (especially if proven to work) then not.
Collapse
11: Re: xowiki crashes (response to 1)
Posted by Dave Bauer on
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.