World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
older newer | first last |
Dockimbel 13-Oct-2009 [6180] | Graham: did you tried launching a new temporary REBOL process using LAUNCH or CALL for sending the requests to S3? (Did I understood correctly that your need is to access S3 asynchronously from your main application?) |
Graham 13-Oct-2009 [6181x2] | doc, no I didn't as that would start up a new App process which seems excessive to just do a download ... especially when Cheyenne is already running in the background :) |
I think I can just include the S3 libraries in the Cheyenne binary, and do a S3 download as a rsp form where I submit the filename, bucketname, and access keys | |
Maxim 13-Oct-2009 [6183x2] | just thought I'd drop a little note that serious remark module work has begun. I was trying some stuff before, but starting too wide and I wasn't able to get traction on the project. now I'm just integrating the v2 remark parser into a mod. One cool thing that it will do out of the box, is handle statically parsed files. basically, you build .html files using remark dynamic tags, they are saved out in a cache dir and then the url-file function will redirect to the parsed file, if done, or will run the parser on it and then cache it. |
I need to get my web sites up quickly for a few projects, so this is a priority thing... I expect to have the first few quality pages functioning within a week. with a few REBOL projects (some still unheard of) to share with all of you guys on one of those sites. :-) | |
Robert 14-Oct-2009 [6185x3] | Session: "On first request to a webapp resource." Hm... I'm not using a webapp, just a RSP file. Could this make any problems? |
ID creation: My RSP file ends after the "startsession" for this case. So, only task here is to either re-use an existing ID or create a new one, that is used in all upcoming RSP calls. Hence, I think the logic is correct. | |
Doc, I think that the problem lies somehwere in the session terminating. It realy looks like session IDs somehow survive and are re-used even for a complete new session. | |
Dockimbel 14-Oct-2009 [6188] | Could you make a minimal RSP script that shows the problem and send it to me? |
Robert 14-Oct-2009 [6189] | I'm currently trying to find out how to make it repeatable. It seems to only happen somestime (or I don't understand the situation at the moment). I add some debug output and will keep an eye on it. |
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) | |
older newer | first last |