World: r3wp

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

Same behaviour with v0.9.18 and v0.9.19 ?

never tried 18

ok, so it looks like an issue with the DO mezz and the new sandboxing 
system.

Seems to be

sometimes even

do %/opt/fgw/Cheyenne/config.r

doesn't work consistently

so I have to 

f: read sometimes even

do %/opt/fgw/Cheyenne/config.r

doesn't work consistently

so I have to 

f: read  sometimes even

do %/opt/fgw/Cheyenne/config.r

doesn't work consistently

so I have to 

f: read %/opt/fgw/Cheyenne/config.r

and then

do f

??? what happened

Cosmic rays ? :-)

bouncy keyboard?

trapped in a time loop ?

it's that Haldron accelerator

they must have turned it back on again.

What prompted the changes in sandboxing and the do mezzanine?

Strange that you've been hit so far away on the other side of the 
planet...things have been turn upside down ?

Checking on google, nope, REBOL is still not the most use language...so 
it has to be the keyboard ;-).

matter is immaterial

Sanboxing: word clashes between several RSP webapps.

I think I used to see data from one rsp session appear in someone 
else's session

As long as you run only one webapp on Cheyenne, no problem, but I 
ran a dozen apps on some of our servers and I was facing several 
cases of name clashing.

RSP session corruption should have been eradicated since a year at 
least.

I think I have no updated my app for over a year!

If you notice such issue with the latest version, please report it 
asap, that's the worst thing that can happen.

have you tried encapping Cheyenne with the webapp?

Don't remember trying that.

Not sure that it can work with the current version. Cheyenne is using 
READ to get static and RSP files,  I have to change that to use the 
virtual file system in memory.

I see

I thought about doing that once, then I found that it requires some 
redesign work first on the virtual file system (%encap-fs.r) and 
also being sure that it won't affect performances when reading files 
from the filesystem in normal usage. I've planned to work on such 
feature for v1.0.