World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
| older newer | first last |
| Dockimbel 14-Oct-2009 [6190] | You can use a shorter timeout period (e.g. 30 secs) to test behaviours when session timeouts. |
| Maxim 14-Oct-2009 [6191] | doc, I've got some questions about http.cfg vhost redirection... www.domain.com:81 [ redirect 301 "/*" "http://www.domain.net" ] www.domain.net:81 [ root-dir %/E/dev/project/my-web/web/www.domain.com default %index.rmrk ] should this work? cause its not . I'm still getting a request for domain.com and a 404 error. domain.net works perfectly. actually, unless I include a root-dir entry in domain.com config, I get an error within cheyenne. |
| Dockimbel 15-Oct-2009 [6192] | Root-dir is mandatory in a domain definition (even if you try to redirect everything to another domain). |
| Maxim 15-Oct-2009 [6193x2] | adding that didn't help in my tests |
the thing is, if I redirect, the root-dir of the redirection should be used... no? | |
| Dockimbel 15-Oct-2009 [6195] | right, it should. |
| Maxim 15-Oct-2009 [6196x2] | also note, I tried adding the :81 to the redirected domain and it didn't seem to change much. |
using the last svn build btw. | |
| Dockimbel 15-Oct-2009 [6198] | looking into mod-alias to see what's going on. |
| Maxim 15-Oct-2009 [6199] | thanks. |
| Dockimbel 15-Oct-2009 [6200x3] | I've added your virtual domains definition to my httpd.cfg file, added a root-dir to domain.com, added :81 to the redirection URL, mapped both domain to localhost, changed domain.net's root-dir to %www/testapp and it works ok : >> read http://www.domain.com:81 connecting to: www.domain.com connecting to: www.domain.net == {<html> <head> ^-<title>Welcome to TestApp web application</title>... |
I've also added port 81 to LISTEN directive in config file. | |
and also changed default file to %index.rsp. | |
| Maxim 15-Oct-2009 [6203x2] | hum... ok, I'll dig deeper ... btw the .net:81 site worked well when I was doing my tests, only the redirection didn't fork the call from .org:81 to .net:81 |
simple question, what do the BIND & BIND-EXTERN directives do? I may have asked before but I'm totally clueless right now. | |
| Dockimbel 15-Oct-2009 [6205x2] | BIND associates a mod handler with one or more file extensions. For example: o bind SSI to [.shtml .shtm] : process those extensions through mod-ssi. o bind php-fcgi to [.php .php3 .php4] : process those extensions thru mod-fastcgi using a php backend. The ID value used as first argument of BIND is just a hook used by the target mod to know which request it should process (as required by config file). See mod-ssi.r as an example. |
Those associations could have been hardcoded in each module, but BIND gives a more convenient way to define and maintain those associations than having to change mod-* source code. | |
| Maxim 15-Oct-2009 [6207] | ok cool... I'll add a new directive for remark which is bind-static, since it treats static and dynamic files differently. |
| Dockimbel 15-Oct-2009 [6208] | BIND-EXTERN plays the same role for background processed modules. All BIND-EXTERN associations will be processed through mod-action. The first argument must match an external module file in %Cheyenne/handlers/ . |
| Maxim 15-Oct-2009 [6209x3] | and use bind for the dynamic mode |
ok thanks for the extra details... now I know where to look in order to integrate mod-remark into cheyenne's current directives :-) | |
the first release of mod-remark, next week, will not have a handler, but I will be working on that quickly after... in order to make the mod more scalable. | |
| Dockimbel 15-Oct-2009 [6212] | If you need to build an handler, there's an old doc that you might use : http://softinnov.org/rebol/task-master.html#sect6. |
| Maxim 15-Oct-2009 [6213x2] | thanks :-) |
I'll probably analyse the RSP handler and mod for proper understanding when I get to it. | |
| Dockimbel 15-Oct-2009 [6215] | The choice between adding a mod (main process) or handler (worker process) is simple : when a mod function is evaluated, the server waits for it to complete before being able to process any other network event. :-) |
| Maxim 15-Oct-2009 [6216] | yep... which is why I want to go down the handler road soon. |
| Dockimbel 15-Oct-2009 [6217] | mod-rsp is quite complex, it does a lot of things. You can start by mod-action (which handles CGI), it's like a stripped down version of mod-rsp (no session, no webapp, etc...) to get the basics of using an handler, then dive into mod-rsp to add higher level features. |
| Maxim 15-Oct-2009 [6218] | handlers seem easy enough to setup, but then it opens up a few problems for session concurrency, and stuff, which you already know... so I want to iron out the whole dynamic remark architecture before tackling the performance issue. |
| Dockimbel 15-Oct-2009 [6219x2] | feel free to copy/paste any code from mod-* to your own mod if that can help. |
Sessions (and especially session data synchronization) is the really hard part. | |
| Maxim 15-Oct-2009 [6221x2] | I'll be adding session support and integrated forms creation within a few days... |
yep... the synchronisation mainly... | |
| Dockimbel 15-Oct-2009 [6223] | It would be so much easier to implement and so much more efficient if we had multithreading and a way to share data between threads. |
| Maxim 15-Oct-2009 [6224x4] | sure... I've impleted some purpose built multi-threaded servers in python and its quite easy to do. probably the last real limitation in REBOL right now. |
I am thinking of building a session server for remark. an uber simple multi-tcp port server which implements liquid-net and synchronises the remark handlers, in a lazy way. so unless the users are actually calling for pages.... no network traffic occurs between processes. | |
not as good as mem copies, but should still be effective and scalable. | |
it has the advantage of freeing the load from the web server so it can continue to stream data... and some client work using several inter-connected cheyenne servers actually provides good results, so I'm optimistic so far ;-) | |
| Janko 15-Oct-2009 [6228x2] | Doc, I don't know a lot about this subject so sorry if I ask stupid questions :) ... could it be made and would cheyenne benefit from using IPC like pipes to communicate between processes instead of TCP ? (I used pipes just once so far so I don't know much about them) |
BTW.. did any of you see the recent discussions about Unicorn ( a pure Unix philosophy webserver - that uses pool of processes .. etc.. very interesting blogposts in any manner, I can find links if anyone is interested. It reminded me a little on cheyenne too, although Unicorn has no async I think) | |
| Maxim 15-Oct-2009 [6230] | janko yes, IPC is another way to approach the issue, but the question is how easy would it be to use within R2? have you successfully done IPC stuff within REBOL using a dll? |
| Dockimbel 15-Oct-2009 [6231] | Pipes implies the same overhead of serializing data to be able to exchange it and AFAIK they cannot be made async in REBOL (polling could be used instead but would affect whole server performances). Regarding session synchronization, it's the same complexity than TCP. |
| Maxim 15-Oct-2009 [6232x3] | Doc, have you ever made benchmarks of TCP xfer rates between two process, using Rebol? |
integrated mod-remark in BIND directive :-) | |
Doc is there any documentation on the directives dialect? | |
| Dockimbel 15-Oct-2009 [6235] | Dialect: no, but you can have a look in %mod-static.r, there's a lot of examples there. |
| Maxim 15-Oct-2009 [6236] | I just don't see where some of the setup gets put... for example... [remark-debug in main] .... hum... where is that information stored? |
| Dockimbel 15-Oct-2009 [6237x3] | benchmarks of TCP between two processes : no, I never needed to mesure that speed because anyway, I don't have real alternatives. |
main => directive has to be in domain or webapp config block global => directive has to be in global section of config file | |
'location and 'folder targets are currently unsupported. | |
| older newer | first last |