r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Cheyenne] Discussions about the Cheyenne Web Server

Dockimbel
27-Oct-2010
[9122]
Hi Oldes, good point, I was thinking about adding a worker processes 
user-controlled killing policy since years now, but it  has never 
bothered me on my production linux servers. 


Also, if you use the -w command line option, you can (in theory) 
set the threshold for workers kept alive after each request. In practice, 
a worker gets killed only if the threshold is reached and after a 
request is processed, so you might have cases, where more workers 
than should be, remains temporary after a burst of requests.


If it's really an issue for you, I can have a look at this feature 
to see if there's a simple way to implement a killing policy (would 
decrease the number of worker processes using 1 / t or e^(-t) function 
classes). See function plots at :
http://www.wolframalpha.com/input/?i=1+/+t
http://www.wolframalpha.com/input/?i=e^-t
GrahamC
27-Oct-2010
[9123]
Any reason not encapping with encmd?
Gregg
27-Oct-2010
[9124]
Sounds great Doc. A lot of changes in there.
Oldes
27-Oct-2010
[9125]
It's not a big issue for me, but sometimes I think about it, that 
the unused processes just sit there with allocated memory. "The threshold" 
sounds good imho.
Dockimbel
27-Oct-2010
[9126]
Graham: I can provide encmd binaries too if it's allowed by RT?
GrahamC
27-Oct-2010
[9127x2]
I don't see the issue ... View now has cmd functionality and is free
I've been releasing cmd encapped binaries for cheyenne for a long 
time now
Dockimbel
27-Oct-2010
[9129]
Ok then, I'll provide them asap.
GrahamC
27-Oct-2010
[9130]
Are  you encapping with 2.7.6 ?
Dockimbel
27-Oct-2010
[9131]
Yes
GrahamC
27-Oct-2010
[9132x2]
Me too ... :)
keeps our RSP code at 2.7.6 as well....
Dockimbel
27-Oct-2010
[9134x3]
All my code in production has been tested with 2.7.6, if I release 
binaries encapped with 2.7.7, I won't be able to test them as well 
as with 2.7.6.
All my code in production has been tested with 2.7.6
 => All my code in production relies on 2.7.6
2.7.7 didn't looked as stable as 2.7.6 when I first tested it (View 
crashed on linux, CALL's code seems to have changed). As I can't 
take any risk with my code in production, I've sticked to 2.7.6 so 
far. Maybe I should give it a more serious try now.
GrahamC
27-Oct-2010
[9137]
I also wasn't convinced by the stablity of 2.7.7 so I've stayed clear 
of it as well.
Maxim
27-Oct-2010
[9138x2]
I've switched to 2.7.7 a while ago I don't see problems with it, 
though some things which affect cheyenne more directly might not 
be issues I have relied on.
e.g. you have a different use case so it might be triggering problems 
that I don't usually encounter.
Dockimbel
27-Oct-2010
[9140x2]
Right, Cheyenne puts /Core and /Pro at stress. 


Today, I spent almost an hour to spot a bug in the RSP engine (it 
was a regression bug), but no way I could figure out the cause or 
what part of the code was producing it. The error raised by REBOL 
was inside ATTEMPT, saying that SET/ANY in ATTEMPT couldn't set the 
value...?? The whole mess was caused by a missing AS-STRING after 
a LOAD/HEADER, branching the RSP engine code into a faultly path 
leading to a corruption of RSP own code and probably of some REBOL 
global words too (my raw guess, but it could have triggered an internal 
REBOL bug as well). That's the dark side of having a fully modifiable 
language, a very small mistake can lead to a total session corruption 
with a cause very hard to track.
Encmd binary 2.7.6 for Windows: http://cheyenne-server.org/tmp/cheyenne-cmd-r103.zip
I'll release the other missing binaries tomorrow.
Kaj
27-Oct-2010
[9142x3]
I've been running my sites on 2.7.7 without problems
On Linuxes where View 2.7.7 crashes, you need the other build (probably 
Fedora instead of Linux/Ubuntu)
That may mean you'd need two Cheyenne encaps if you want to encap 
with View
Pekr
28-Oct-2010
[9145]
Doc - R3 might be better in that regard - it is a bit less "modifiable", 
more precisely defined, and it has modules too. But - there will 
probably be no Cheyenne for R3, so :-)
Dockimbel
28-Oct-2010
[9146x2]
Modules will surely help secure the environment at runtime, but you 
can still accidentally corrupt your own code, it's part of REBOL 
nature.
0.9.19.103 binaries for main platforms available now: http://cheyenne-server.org/blog.rsp?view=21
james_nak
28-Oct-2010
[9148]
Doc, only an hour? That's a good day for me with rebol sometimes:-) 
thanks for the new version.
Dockimbel
28-Oct-2010
[9149]
an hour?
james_nak
28-Oct-2010
[9150]
From your Wed 3:01 PM post where you mentioned you "spent almost 
an hour to spot a bug..."
Dockimbel
28-Oct-2010
[9151x2]
Ah, yes, I guess I was lucky.
SVN r104: 

- FIX: port-id's relocation for multiple Cheyenne instances support, 
wasn't working correctly.


Do not use r103 binaries to run multiple instances of Cheyenne. I'll 
update the binaries asap.
Carl
28-Oct-2010
[9153]
Doing a little catch up here...
PeterWood
29-Oct-2010
[9154x4]
I'm having a little fun trying to set far future expiry dates from 
Cheyenne.


There seems to be some conflict between the httpd.cfg and the script 
as to whether the anem is expire or expires.
Having changed expire to expires, I get the follioing messages when 
I start up Cheyenne:


29/10-11:48:27.025934-## Error in [uniserve] : Cannot open server 
RConsole on port 9801 !

 29/10-11:48:27.053752-## Error in [uniserve] : Cannot open server 
 Logger on port 9802 !

 29/10-11:48:27.060870-## Error in [uniserve] : Cannot open server 
 MTA on port 9803 !

 29/10-11:48:27.061148-## Error in [uniserve] : Cannot open server 
 HTTPd on port 8000 
!

29/10-11:48:27.061893-## Error in [uniserve] : Cannot open server 
task-master on port 9799 !
anem -> name
Using RebCmd 0.9.20 with mod-expire.r from 0.9.19
Dockimbel
29-Oct-2010
[9158x2]
Peter: the error you get is caused by trying to run multiple sessions 
of Cheyenne at the same time, see my post at Thu 19:04 about that.
About mod-expire, I'm not sure to see where precisely the conflict 
you're mentioning happens?
PeterWood
29-Oct-2010
[9160x6]
Thanks  Doc. I must have forgotten to stop a previous session before 
starting a new one.
I ferlt the conflict with mod-expires was:
htttpd.cfg

modujles [
   expires   ;; initially commented out
]

%mods/mod-expire.r
I'll check again.
I have mod-expire(s) working now - I changed the script name to mod-expires.r
I also have it working with by using expire in the list of modules 
with the script named mod-expire.r
Dockimbel
29-Oct-2010
[9166]
I guess you had an old version, from SVN repo, it's "expire" in httpd.cfg.
PeterWood
29-Oct-2010
[9167]
Maybe I mistakenly added the s - not too worry, it's working fine 
now. 

Thanks for your help.
Dockimbel
29-Oct-2010
[9168]
For Cheyenne fans, finally some logos to spread everywhere. ;-) 
http://cheyenne-server.org/blog.rsp?view=22
Gregg
29-Oct-2010
[9169]
Nice.
Kaj
29-Oct-2010
[9170]
Yes, nice ones
PeterWood
2-Nov-2010
[9171]
I'm having problems with post data and Rebol CGI scripts under Cheyenne. 
I ran a simple test scipt to simply echo back the post data:

#!/usr/bin/rebol -cs



REBOL []


data: make string! 1020

buffer: make string! 16380

while [positive? read-io system/ports/input buffer 16380][

    append data buffer

    clear buffer
]


print "content-type: text/plain^/"

print data


The script echoes back the post data when run under Apache but prints 
an empty line under Cheyenne.


(Just to check I ran a similar Ruby script which successfully echoes 
back the post data in Ruby).

I'm running 0.9.20 encmd.