Forum OpenACS Development: Re: Bad HTML + Notifications

it would certainly make sense to handle failing queued requests in a better manner, flagging failed requests, options for the swa to redo or flush, ... this would be in general useful for all queues. Strangely enough, this happens rather seldom, so it seems nobody has implemented a more general solution (e.g. adding a column "state").

a few hints that might improve the situation for you:

* xowiki contains an option to use tidy for cleaning up the content.

* NaviServer has a config parameter "schedsperthread" that defines a maximum number of scheduled procs per worker thread, leading to a cleanup by terminating the threads running the scheduled procs regularly.

-gustaf

yes, the version of naviserver in bitbucket https://bitbucket.org/naviserver/naviserver is the version we use in production. With the config file openacs-config.tcl (on bitbucket) it works pretty much out of the box with OpenACS. We switched to naviserver about two years ago and developed a small layer for the openacs. With this and a recent version of xotcl-core one is also ready to use naviserver with XOTcl 2/NX (http://next-scripting.org/)

Below are some long-term statics from our production system, where one can see how the resources went down and the performance improved. All data is from the same hardware. In the the last two years, the number of views/day more than doubled, while the overall response time was cut to less than a third (even though the database size went up, we have added recently much more rather complex queries for workflows, plagiarism checking, lecture casts, etc.). We have now more than 120.000 learning resources, more than 5.000 courses per year. Performance-wise, XOTcl 2/nx helped a lot, but finally, it is hard to say, how much each piece contributes. Due to the reduced resource consumption, our next production machine will be significantly cheaper than the previous one (will be in use in oct).

http://www.openacs.org/xowiki/file/naviserver-nx.png

-gustaf

the mentioned layer is in part in the naviserver distribution (aolserver-openacs.tcl) and part in OpenACS (guarded by

if {[ns_info name] eq "NaviServer"}

). See e.g. acs-tcl/tcl/utilities-procs.tcl. the naviserver support is quite a long time in OpenACS, but was improved over the years. i am not sure about the state of OpenACS 5.3, my recommendation is to upgrade to a more recent version.

In other words, for the layer, there is nothing extra to install.

Concerning nsldap: A few days ago, I have added a nsldap module adjusted to the C-api of naviserver to the bitbucket repository.

Best regards

-gustaf neumann

the tdom module is completely in and for tcl now,,,

• so, untar it
• cd in there,
• cd to unix, then...
• CC=compilerYouBuiltTCLWith ../configure --enable-threads --disable-tdomalloc --prefix=/path/to/tcl/install --with-tcl=/path/to/tcl/install/lib
  
  note that compilerYouBuiltTCLWith should really be the compiler you're building everything with, and so if you built without any CC= in the configure step you can leave it out of everything else, and
  
  /path/to/tcl/install would be the value of --prefix= when you ran the tcl ./configure.

the --prefix will install tdom so it's a sibling of the other tcl modules.

even more...

xotcl is also in and for tcl; soemthing happened when aolserver4 cane out,,, it allowed regularly built tcl modules to be included by aolserver without special/weird actions or syntaxes for doing it. the consequence of that is nothing needs to be --with-aolserver any more.

./configure --with-tcl=/path/to/tcl/install/lib --prefix=/path/to/tcl/install --enable-threads --without-aolserver3

which will also make the xotcl module, when installed, a sibling of the other tcl modules.

The installation went well.

Thank you very much for the suggestions.