World: r3wp

Apart not having doc to set the httpd.cfg correctly, I have one small 
problem.

I use it to test RebelBB localy and it seems POST request does not 
work. I had to change to the GET method to have it working.
Any idea ?

And I'm unable to see the documentation on the Cheyenne website (wiki). 
I only have a neverending "wait for cheyenne-server.org" that finnaly 
ends long time after with a blank page.

doc needs to restart Cheyenne

Right. I left it in that state to be able to study the reasons why 
the FastCGI connection is still unreliable with PHP. I'll restart 
it in a couple of hours.

404 page : yes, Skype, among other applications, reserves port 80 
for its own use, so you have to shutdown any such program before 
being able to use Cheyenne (or any other web server on port 80). 
Once Cheyenne is started, you can launch again Skype and it will 
use another port (that should be configurable somewhere in Skype).

You can also choose to run Cheyenne on another port, just look in 
the default %httpd.cfg file and uncomment the LISTEN option in the 
'globals section.

I guess that RebelBB is running as a CGI app ? If it's using READ-IO, 
your issue might be caused by some limitations of my READ-IO emulation 
code. If you can send me or point me to the code, it should help 
me improve Cheyenne's CGI support.

The code is the one of RebelBB here : http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?code=1

Okay, my READ-IO emulation has been removed in the last version. 
I've replaced it with a safe 'cgi-read-io function. I plan to put 
it back soon, I think I know how to make it work reliably now.

Doc, does it affect RSP or is this solely a PHP issue?

It's a FastCGI/PHP issue only.

ok

Cheyenne's wiki is back online. I've fixed a bug in the FastCGI reconnection 
process. Load tests seems ok. It's now under observation during a 
few days to see if it really solved the stability issue.

Thanks DideC. I disabled Skype and Violla! Everything is working.

Cheyenne locked up ( RSP ).

Logged into rconsole.r and tried the write %debug.log mold uniserve 
but nothing written.

Quit and tried to login to rconsole.r again, but now just hangs.

See screenshot http://screencast.com/t/eoERBSFOLz6

Anything else I can try before I reboot?

What I was doing ... I had FF in one RSP session.  Then tried to 
access the same webapp using IE ... and that seemed to cause the 
problem.

The Vista can be the problem ;-)

Interesting pattern, I'll try to reproduce that. Strange that you 
can write a log file from rconsole, something wrong with filesystem 
writing permissions ?

can't ?

sudo rebol
and then do %rconsole.r
and there was no error when I tried to write the log file.

not using Vista .... except for the ssh client.

Cheyenne is still running, but RSP is not.  Going to kill the chyenne 
process now as I need this server up and running.

Graham: can you make sure it is not task-handlers busy due to long 
processyng rsp? if you run it in the console you can put "rsp-log 
word-to-check-here" in your rsp-code to monitor if they are still 
running.

No long running rsp

How to turn off the inbuild RSP cache?

or at least the cache should be cleaned on config reload.

For debugging purpose, start cheyenne with the -debug command-line 
option, it forces RSP to reload everything at each request.

Graham: running the rconsole with root privileges doesn't help. Once 
you're in the console, your code is executed by the cheyenne process, 
not by the rconsole process.

Is your Cheyenne process running as root ?

A possible explanation is : your RSP processes are freezing because 
of a file access issue. The main process  wait for the RSP process 
to finish and launch a new one for new request. Once the max number 
of processes is reached, your server is no more able to execute RSP 
requests.

I have a log which notes when I call an external app, and when I 
return.  There's no problem there so it's not 'call.

Yes, sudo Cheyenne

As I mentioned, it seems to crash usually when I have IE and FF both 
accessing the webapp

If I just stick to using FF, I never see RSP fail

I'm investigating the issue with Will. Not sure that's exactly the 
same issue as you, but its probably related in both cases to *uncatched* 
user script errors that freeze or kill the RSP process...which is 
quite odd, because RSP script execution is protected by 3 levels 
of TRY...The main process seems to never been notified as TCP control 
connections with RSP processes are probably left half-opened.

*uncaught*

thanks for correcting me.

IIRC, that's the second time you correct me on that same mistake 
;-)

Btw, what was your CALL doing in your RSP app ? Calling ImageMagic 
?

if anyone has code that reproduce rsp stopping working please send 
me a copy,

Yes, I call imagemagick

and faxstat
http://compkarori.no-ip.biz:8001/debug.txt

nothing wrong with it

Yep ... it returns okay from 'call

does it run in a webapp ?

when rsp stop responding do the rsp (task-handlers) still exists?

Yes, it's a webapp