World: r3wp

I normally just reboot ... perhaps I need to find a cleaner way of 
killing the cheyenne process.
No, just the one RSP webapp.
Not responding.

I usually kill it here and start it again. For those times where 
it mysteriously just quits, I can also just start it again. I have 
mine set up via launchd in OSX.

This is not so good then .. is there a way we can debug this?

Or is it just Cheyenne reaching it's pool limit?

Henrik, are you running RSP, or CGI ?

RSP

It's a bug, but hard to fix because I can't reproduce it. The only 
way to fix it would be to log into a  Cheyenne server in blocked 
state, using the rconsole client.

So, if one of you can provide me with an access to a server in such 
state, I should be able to investigate on that issue.

Now my server quit. Doc, can we use that? I can't provide direct 
access to this server, but can you give hints on what to search for?

My quit as well... but i didn't see this message.  So I used 'kill 
to kill the pid and restarted it :(

Did you have to actually kill it?

how else?

Wait... I'll check my log.

Graham, mine just quits. I can go in and start it again without problems.

Mine is still running ... just RSP stops working.

29/10/08 21.56.24 com.apple.launchd[1] (com.rebol.cheyenne[65863]) 
Stray process with PGID equal to this dead job: PID 65868 PPID 65866 
rebol

I think launchd kills it for me.

There are 4 lines with that.

restarted it

If you can access to the server through rconsole just do this : write 
%debug.log mold uniserve (and put the compressed version of the %debug.log 
file on your web site so I can download it).

Ok

I take it that this is a new bug .. I'm still running a much older 
version of Cheyenne from last year ... and I never saw this.

( on a different server )

Henrik, if you're running cheyenne in source mode, you should use 
the -w command line option (that will allow the generation of a %crash.log 
file if the REBOL error is catched). If your Cheyenne quits, I don't 
think that's caused by a bug inside Cheyenne, but usually by something 
like an uncatched file access error (file handles starvation, file 
access rights,...). Will had some similar issues with Cheyenne on 
OS X, I guess he could help here.

Do you think the error is being caused by an untrapped Rebol error?

catched => caught
uncatched => uncaught

For Henrik issue, probably.

And mine .. do you know if anyone is having my problems?

I experienced such issue a few times months ago, but not since v19.

I am running on marginal hardware ... I wonder if that's the issue 
too.

A RSP script that would endlessly loop (or being stuck in a wait) 
could cause such issue.

No loops or waits in my code

But you're using CALL ?

sorry .. I am using call/wait

:)

I will ask my friend if he has the same issues ... he's running the 
same code and has not mentioned any problems

You could put a couple of debug lines around your call/wait and log 
them to a file to see if your CALL always returns.

ok.

I think I could improve such issues with a timeout on RSP script 
execution in the main process (and returning an error message if 
a time limit is reached).

I use call/output

are uniserve logging functions not available to rsp scripts?

no, it's not the same process and helper processes where RSP scripts 
are executed, don't load Uniserve code. They just use a small client 
(%task-handler.r).

Got error on Henrik's site - RSP error catched - internal limit reached: 
parse

Near: [parse either empty? val-ctx [data]] 
where: html-gen

.... ok :-)

I think that's a bug in html-gen. hang on...

ah, so not in Cheyenne? well, wrong group post then :-)

hmm.. that didn't solve anything.

I thought maybe the file table was too big.

has it anything in common with nested calls/recursion?