World: r3wp

From the error message, the error would come from an incorrect event 
definition in %app-init.r

errors like this are usually coaused by error in app-init.r yes

I deleted the app-init.r and still get the error

In fact I didn't have an app-init.r so added one

IIRC, app-init.r is mandatory for a webapp, even if you don't use 
it.

so maybe that was the first issue.

put it back and restarted cheyenne

very odd .. I deleted the comments in on-application-start and it 
works now!

I can only guess that I didn't complete shut down and restart Cheyenne

You should just "Reset Workers", it's enough to reload all the webapps. 
You should also consider running your dev instance of Cheyenne with 
-w 0 command-line option to make it reload all apps on each request.

I'm looking at the code in RSP.r and I can't figure out how you could 
raise such internal error. Can you please describe me the simplest 
way to reproduce that error?

reload all apps on each request?

The first thing I did was create a web app with no app-init.r

When I tried to access the login.rsp page I got that error.

yes, the -w 0 option asks Cheyenne to maintain a pool of 0 worker 
process and launch one only when required (killing it when the request 
is completed). That has the side-effect or "reloading" all webapps 
and cleaning any corrupted data in memory produced by user-scripts.

what impact does that have on performance?

it sounds like it would slow it down to cgi ?

yes, but you use it for the development only, not for production. 
I'm working with big RSP webapps and the slowdown with that option 
is barely noticeable.

oh .. ok

I've removed %app-init.r from %www/testapp in Cheyenne's archive, 
started a fresh Cheyenne session, logged in http://localhost/testapp
and I can't reproduce your error. I only keep receiving this kind 
of (normal) error: 

##RSP Script Error: 

	URL  = /testapp/login.rsp
	File = app-init.r


 ** Access Error : Cannot open /C/Dev/Cheyenne/www/testapp/app-init.r 
	** Where: rsp-script 
	** Near:  [init: load join root %/app-init.r]

I've removed -w 0 option also to mimic your config, I'll try putting 
app-init.r back now.

Still no success in reproducing your error...

I renamed app-init.r in my svn version, started cheyenne and don't 
get any error

looks like the cheyenne I'm using is a build from middle of last 
year

You should get some if you try to use any session object functions 
or access any session/content variables.

mid-2009? That's damn old :-)

it let me run the test rsp script

old .. yeah, but since I haven't had any issues, I don't change the 
server apps

That's usually a good rule.

So, I guess no point trying to produce this error since I am using 
an old server build

Right, there's more than 90 SVN revisions since july-2009...

Is anyone using Cheyenne in an environment where they also use Ladislav's 
INCLUDE? The RSP handler has its own global INCLUDE func, which I 
think will conflict.

I am not, but last time I "felt" an Include conflict, it was very 
easy to resolve, in fact

I'm sure it can be resolved. And if someone else has done it in such 
a way that you and Doc approve, I'll gladly borrow from them. :-)

Gregg: 'include is not used internally by RSP engine, so you can 
freely redefine it, like that for example (not tested but should 
work) :

in %app-init.r :

on-application-start: does [

 set 'rsp-include :include 	;-- use 'rsp-include now for RSP script 
 inclusion

 unprotect 'include	;-- 'include is mark as protected by the RSP engine
	do %include.r 	              ;-- Ladislav's include script
]

So, this is a local 'do and not the '*do ?

Depends if you want to keep that local to your webapp or share it 
for all your webapps (using do/global or *do in that case).

So, yes, it's a local 'do in my example above.

Thanks Doc.

Thanks again Doc, that lets me run things using INCLUDE. Now I'm 
on to the next issue, which is that it doesn't work (i.e. INCLUDE 
gets messed up) after running any kind of RSP. I'll dig in when I 
get a chance and tell you what I find.

did you try *do ?

Gregg: I'll give it a try today to see what's going wrong.

Graham, no I didn't. 

Doc, not critical by any means, but thanks.

Does anybody has init.d script for cheyenne?

ok.. I'm not sure if this is the best way, but it seems to be working 
for me:
#! /bin/sh
# /etc/init.d/cheyenne
#

# Some things that run always
#touch /var/lock/blah

STARTSCRIPT=/web/start-ch.sh

# Carry out specific functions when asked to by the system
case "$1" in
  start)
    echo "Starting Cheyenne "
    $STARTSCRIPT
    RETVAL=$?
    ;;
  stop)
    echo "Stopping Cheyenne"

    ps aux | awk '/cheyenne/ && !/worker/ && !/bin/ {print "kill -9 "$2}' 
    | sh
    RETVAL=$?
    ;;
  reload)
    echo "Reloading Cheyenne"

    ps aux | awk '/cheyenne/ && !/worker/ && !/bin/ {print "kill -HUP 
    "$2}' | sh
    RETVAL=$?
    ;;
  reset)
    echo "Reseting Cheyenne"

    ps aux | awk '/cheyenne/ && !/worker/ && !/bin/ {print "kill -USR1 
    "$2}' | sh
    RETVAL=$?
    ;;
  restart)
    echo "Stopping Cheyenne"

    ps aux | awk '/cheyenne/ && !/worker/ && !/bin/  {print "kill -9 
    "$2}' | sh
    echo "Starting Cheyenne"
    $STARTSCRIPT
    RETVAL=$?
    ;;
  *)

    echo "Usage: /etc/init.d/cheyenne {start|stop|reload|reset|restart}"
    exit 1
    ;;
esac

exit 0

Gregg: my solution was missing a 'unset call too (tested with Cheyenne 
sample webapp, works ok) : 

on-application-start: does [
	set 'rsp-include :include
	unprotect 'include

 unset 'include				;-- this one is required to allow %include.r to 
 load properly
	do/global %include.r
	set 'include-path [%//dev/Cheyenne/www/testapp/]
]

Oldes: we have one here somewhere, but I can't find it right now. 
Anyway: 
 

1) "kill -9" is not a good way to stop Cheyenne, a simple "kill" 
is the right way (this signal is caught by Cheyenne to clean up things 
and exit properly).


2) "ps aux | awk ..." is not required, Cheyenne stores its main PID 
in /var/run/cheyenne.pid (or /tmp/cheyenne.pid in revisions < r90). 
Just read this PID and send all signals to that process only. Watch 
out if you run it on port <> 80, you'll find the port-id inserted 
in the PID file name.

The problem with the PID file is, that I was not able to read it 
because of permisions. But I may check it again.

The PID file should have the same rights as the Cheyenne process, 
let me see if this works as it should.

The PID file is still own by root in that case. It's readable by 
other users but not writable (Cheyenne can't delete it on exiting). 
I need to fix that.