We've just run into a situation where some bad HTML took our server down. The bad HTML (unclosed tags) caused the text/html conversion proc called in acs_mail_lite::send_immediately to return an error. Although the error is caught in the sweeper (acs-mail-lite-procs.tcl), the memory consumed in the scheduled thread is not released. Since the message wasn't sent, the sweeper tries to process it again and again. In our case, the outgoing message contained batched notification for many edits on a handful of large wiki pages which totaled about 8mb. With the sweeper running every minute, you can see how this can get out of hand quickly.

We've identified the source of the bad HTML and, locally, we've modified the sweeper to leave a bad message locked so it won't be processed again. This isn't a proper long-term solution, though. Rather than silently deleting the message or abusing the semantics of the locking_server column, I suggest we generalize the "locking_server" column into a status column that can be 'locked', or 'failed'. Thoughts?

Thanks for the response, Gustaf. It is strange it doesn't happen more often. I'll change make the changes on HEAD. I checked and we must be a bit behind in terms of xowiki versions as we don't have the tidy option. I'll look into upgrading.

Regarding Naviserver, is it at the point yet where it can be a drop-in replacement for Aolserver?

Hello. In the University of Valencia we are trying to install naviserver with openacs (5.3). We are interested about the "small layer for the openacs". Can we find this code in de CVS?
On the other hand, we have not found the nsldap module.

Thanks to share our experiences

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.

Use --prefix=/usr/local/ns for everything, that keeps your aolserver installation untouched; see below. As pg driver, use nsdbpg from bitbucket (http://bitbucket.org/naviserver/)

Concerning XOTcl: i would recommend to use XOTcl 2.*, https://next-scripting.org/; a configure --with-tcl=/usr/local/ns/lib/ should again be sufficient, no "make install-aol" needed. Same is true for for XOTcl 1.6.*, but i have not tested this for a while. Don't install in the same tree xotcl 1.* and xotcl 2.*, since the the 2.* versions are still in beta, and a "plain package require" prefers the non-beta over the beta version.

all the best
-gustaf

cd /usr/local/src/tcl8.5.12/unix
./configure --prefix=/usr/local/ns --enable-threads --enable-symbols
make
make install

cd /usr/local/src/tDOM-0.8.3/unix
../configure --prefix=/usr/local/ns --with-tcl=/usr/local/ns/lib 
make 
make install

cd /usr/local/src/thread/unix
../configure --enable-threads --prefix=/usr/local/ns --exec-prefix=/usr/local/ns --with-tcl=/usr/local/ns/lib --with-aolserver=/usr/local/ns
make 
make install

cd /usr/local/src/xotcl-1.6.7
./configure --with-tcl=/usr/local/ns/lib/
make
make install

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.