World: r3wp

It seems that the issue is caused by helper processes being stuck 
in "busy" mode and 'pool-count reaching the max value (8 in v0.9.18), 
so that any new CGI or RSP request coming won't find a free helper 
process. I still don't see why helper processes would remain stuck 
in "busy" mode. I'll run a few tests tomorrow to investigate that 
more deeply.

can we change the max value?

sure

it's not yet exported in config file, but you can change the default 
value in %Cheyenne.r source code.

ok

Hi Henrick, I store my site at %/c/www/

sorry for the delayed response

Crashed again ... static pages still serving, just rsp down and this 
is with 9.19

All I'm doing is editing RSP pages, and running them.

running source code cheyenne.r on OpenSuse  ( I think )

Nicolas, sorry, the question has scrolled out of view here. Would 
you mind posting it again?

Nicholas "Hi, I'm new to cheyenne. I've tried http://localhost/
and I get the message It works!. But I can't view my site.  How can 
I ? Any tips?"

odd ..

should be Cheyenne/www/site here ....

I can't view my site
 <- what exactly happens?

Nicolas.. your site needs to be in Cheyenne's www folder -> %/c/Cheyenne/www 
(or

Doc, is it this line here to increase the nymber of helper processes?

			shared/pool-max: any [all [flag? 'debug 0] 8]

yes, just change the 8 value.

thanks for the help guys

Are there any issues with an rsp script executing scripts in the 
Cheyenne directory?  As opposed to www and below?  I get these odd 
error messages where the script can't access them due to protected-exec

If I can't store scripts above the web root for security purposes 
.. how does one store user lists etc without using a db?

An update on my web fax portal.  http://screencast.com/t/1n1HgxKH8

When I click on a fax, it gets converted to PNG and then the Rebol 
plugin in invoked.  I bring up a new window outside of the browser 
window and display the fax.

Haven't figured out how to invert or rotate the image in place yet, 
so just bring up a new window with the rotated image.

BTW, as soon as Cheyenne starts, it uses 4 in the pool-count.. ?

You can change it in settings and or code. I think.

Would bad RSP code cause the processes to hang increasing the pool-count?

Perhaps that's why you rarely see them ... ??

In theory, if you code bad RSP that, e.g., loops forever without 
crashing, that may cause such situation (helper processes starvation).

No, not that bad.  
I had some code like this

do to-file "../../config.r"

when i guess it should have be

do to-rebol-file ".../../config.r"

I was avoiding the % so that they don't get mangled while editing 
thru the web.

actually I don't understand why I was getting the errors ...

do to-file "../../config.r" should have worked
and even when I changed it to absolute path
do to-file "/opt/fgw/Cheyenne/config.r"
i still had problems.

In v0.9.19, DO is a mezzanine that do some rebinding. Maybe you should 
try with *do (native DO alias).

ahh.....

It was very odd ...sometimes it would suddenly start to work even 
though I did not change anything, and then it would stop working.

Where would I find docs on setting cookies?

I see req/in/headers/Cookie gets the cookie, but setting it how?

Can set with javascript 
<script>

document.cookie ='cheyenne=testcookie; expires=Thu, 15 Oct 2008 20:47:11 
UTC; path=/'
</script>

Use response/set-header : http://www.cheyenne-server.org/docs/rsp-api.html#def-31

Guess what, clients started getting timeouts because it seems that 
Cheyenne wasn't fast enough to process all events and find enough 
time to accept new incoming connections (this also had the bad consequence 
of halting Cheyenne due to an uncatched timeout error).

I take it this is fixed in next version?


Also, what are the mechanics around the connections.. at 1000 it 
just maxed out CPU or rejected connections? or ?

You plan to support 1000+ simultaneous connections ?

Doc, since I've fixed my Rsp code .. I've not had Cheyenne hang on 
me

What kind of fixes have you done ?

So, I guess it was just bad Rebol coding .. ( caused by my last minute 
desire to edit the rsp pages thru the web )

I use an absolute path to the config file now

instead of 

do %../../config.r
I'm now
do %/opt/fgw/Cheyenne/config.r

I don't understand why sometimes it would not execute the config 
file using relative paths

So with the old code, Cheyenne was hanging on each time ? (I guess 
after a few requests ?)

not hanging ... just crashing my rsp scripts at times

it would complain it could not find variables defined in config.r