World: r3wp

ChristianE: I've commited a fix to Cheyenne public repository. It 
will be available as a new source package in http://cheyenne-server.org/download.shtml
in about an hour. But I won't build new binaries now (takes too much 
time).

If you're using the binary version and don't have the SDK, you can 
put the one-line patch in a REBOL script and load it in your app's 
startup code or better, load it using the 'worker-libs config keyword.

Nenad, that's great! Thanks for all the work and effort you put into 
Cheyenne! And don't even think of taking any extra time to build 
binaries for just a little fix like this one, really, I can wait 
and happily use the patch.

Cool :-)

Doc, one thing I have not yet fully mapped out in my mind wrt handlers.

Q1:

how do the handlers actually compile/get their source code... is 
it sent over tcp and run there, or does the handler load a file on 
its own?

Q2:
when exactly does this happen?

Q3:

can I configure the handler source or data in some way before it 
gets compiled/executed,  (at the mod conf parsing stage).


I neet the handler to share some data with the mod which manages 
it in some way.


I don't want to send this config data via the request, at each request 
(makes no sense)

ah... don't bother, I just figured out... I've been reverse engineering 
the whole task-handler/master code for a few hours... finally found 
the magic lines I was looking for.  


its neet, you load the files on demand, loading each module, only 
if its actually required.  best of both worlds.

so I guess, the best way to configure the handlers through cheyenne's 
httpd.cfg system,  is to save out a temporary configuration file 
on the fly when the conf parser is run.  


this file would be executed by my handler when it is launched by 
any of the worker processes.

Looking at COLLECT code again, DO's arity is not 3, it is 2 or 10, 
depending on how one count arguments.

Temporary conf file: right, that should be the simplest solution.

yeah... I've changed my solution a bit.   the handler now has a variable 
to know if its been configured yet, and if it has, it skips that 
part of the code.   so even if I get the cfg at each request, I ignore 
it.


The cool thing is that my mod really doesn't need much configuration 
and most other standard configs are useless to it, so I commented 
just about all of them in my httpd.cfg and my mod still works.  :-)


very lean on the cheyenne side.  I do all the heavy lifting in the 
handler, so it can scale pretty well.

one strange thing though... in the task-master.r  lib I set workers 
like this:

		pool-start: 1	; number of helper process when Uniserve starts
		pool-max: 	2	; maximum number of helper process


and it always opens up 4 anyways.  is there anything else to do?

These default settings are superseded by the ones from %cheyenne.r.

ah.

You need to change them in %cheyenne.r (I should add them to the 
config file some day).

maybe I could add a little cfg option for them... my client is going 
to need this.

yep... works  thanks

btw, I'm starting to feel like a cheyenne mod/handler code ninja 
 ;-)

You can, except you, I think only Philippe Legoff got that far :-) 
BTW, he wrote a few nice articles (french only) on Cheyenne usage: 
http://pl.legoff.free.fr/dotclear/rebol-fondation/index.php/?q=cheyenne

I'm having a strange problem with one virtual-root that works and 
another that doesn't. The one that doesn't simply sends back a 404.

Can you show me the config definition for these two webapps?

privately

What's the best way to debug app-init.r now? I can't see whether 
a bug happens or whether it runs ON-APPLICATION-START at all.

Use 'debug/probe or 'debug/print to emit debug logs in %trace.log 
file.

If an error is caught in 'on-applicaion-start, it will appear in 
%trace.log.

nothing shows up, so I guess ON-APPLICATION-START is never run.

probably (see my private message)

i have an rsp like this:

<% probe delta-time [ ... switch request/method [ get  [...]   post 
[...] ]  ... ] %>

if i make a GET, it's fast:

$ time curl -s -D- http://localhost:8080/docs/rfq3 >/dev/null
0:00:00.003815
real    0m0.026s


if i make a post, the rsp part is still fast, but the overall request 
is damn slow (even consequent requests too):

$ time curl -d @xxx -D- http://localhost:8080/docs/rfq3
0:00:00.004595
real    0m2.034s

so what is this 100 fold difference between GET and POST?

is it just curl? i will try from rebol 1st

from rebol, it's okay...


>> delta-time [read/custom http://localhost:8080/docs/rfq3 reduce 
['post read %xxx] ]
connecting to: localhost
== 0:00:00.034002

it has something to do with the connection keep-alive

curl --http1.0 ... is fast

yes, the http connection will not close until it times out.


if the curl command line waits for ip close to return, its possible 
that is what is happening.

there are probably ways control this via some curl command line options?

i was trying an explicite response/set-header 'connection "close", 
but it didn't help..

see the --http1.0 option above. with that there is no Connection: 
keep-alive  header sent  (or maybe there is, but in HTTP/1.0 mode 
it is ignored)

it shoudn't send it.  the servers are always free to implement more 
headers than the spec.

also realize that if you use http 1.0 there are no virtual hosts!! 
supported so its a bit deal.

bit = big

with the --no-keepalive option, this magic 2seconds delay is still 
there

If you haven't figured out the COLLECT rewrite yet, let me take a 
look.

hmm... does cheyenne handle the Expect: 100-continue header?

i couldn't really find any signs of it. the http-responses mentiones 
the code 100, but that's all, im afraid

Here is a workaround (by raping curl):


$ time curl -H 'Expect:' -d @xxx -D- http://localhost:8080/docs/rfq3
real    0m0.082s

HTTP code 100: not supported, if you have a (not obscure) use-case 
for that, I might add support for it.

Keep-alive: IIRC, Cheyenne doesn't honor the "Connection: close" 
case with HTTP1.1.

BrianH: I've found a workaround for COLLECT (just replacing DO by 
*DO which refers to the native function in RSP environment). Can 
you tell me if there are other recently added mezzs (from R2/Forward 
mainly) that rely on DO in their implemenation?

the module stuff, probably.

I would need to patch them one by one when used in RSP.

(should be a one-line patch like for COLLECT, so not a big deal)

APPLY and MAP-EACH, so far.

Both of them do a block though.