Hello Katir,
In theory such a process will block your framework for 10 seconds as
you expect. In practice, there is, for sure, a way we can design the
entiere "n-tier" process your are thinking about to have the blocking
part of it on the client-side part of the solution (AJAX
xmlhttprequest object calls if the client app is a webbrowser, Rev
scripting if the client-side app is a Rev one), so you will never
need to slow-up and breake your server-side queue of tasks. In this
case, the fact that Rev is not multi-threaded will never be a problem
because, even if some ones can doubt of this, J2SE deamon are running
up to teen time slower than Rev deamons (Linux and OSX) :
J2SE supports 3 threads max at once while Rev is queuing each task =
3 * 10 times unit for J2SE and, only, 3 * 1 times under a Rev server-
side deamon to have the same quantity (and quality !) of queries
served to the clients. As you can expect, even if Rev is not multi-
threaded, the work will be well done by Rev because its ablity to
speed-up the responses to the queue of requests...
If you give me some more details about the process, you are thinking
about, i'm sure we will be able to design the solution without having
to manage synchronious blockings on the server-side.
Kind Regards,
Pierre
Le 26 août 06 à 05:43, Sivakatirswami a écrit :
Pierre:
If a single engine is running as a daemon, and, as we know,
Revolution is no multi-threaded and cannot fork a new process.
What happens if one of your CGI has a "wait 10 seconds" in it... or
a blocking call ? Doesn't this bring down the entire framework for
10 seconds and all other attempts to use the engine are blocked for
10 seconds?
Sivakatirswami
Pierre Sahores wrote:
Hi Andre,
I'm bundeling MC/Rev client-server's applications to Apache since
1997 in using this kind of architecture. The client part of the
process can be un standard web browser under the Win32, MacOS9/X
or Linux platforms, a webbrowser+AJAX add-ones (XMLHTTPRequest
objects) on the same platforms or MC/Rev client-side apps. All
works very securely in real solutions solded to my customers
(Education, Universities, Humans Ressources Management and Coaching).
Perhaps could you have an eye on the basic tutorial i maintain on
the subject at <http://istream.homeunix.com/insead/index_en.html>.
Dont hesite to ask me more about the details ;-)
Best Regards,
Pierre
Le 24 août 06 à 01:49, Andre Garzia a écrit :
Hi Folks,
I am building my soon to be released web application development
thingy. I am bundling all my libraries (and some third party with
credits), docs and example.
But since I talked with Dan and others during RevConWest, I
decided that the most important part of this package is the out-
of-the-box experience. The hardest thing about CGI and WebApps
for rev users is usually setting up the environment. The idea is
to develop locally and then deploy when ready. I can't really
build this for Windows, I expect help on that later. So the idea
is that there's a home stack that sets everything up.
Till today I was bundling the LiteSpeed Web Server <http://
www.litespeedtech.com> server with the package. The server would
be all set up out of the box so that you could just launch and
play. The problem is, the thing is not running CGIs, the plain
old ones... they run once, then the server deadlocks. ARGH!!!! I
thought about using cherokee web server <http://www.0x50.org/>
but then, it comes out in source form and when it compiles it
hard code some paths for the dynamic loading libraries, so you
cannot really build it and then just bundle. You must compile it
for each installation. Thats the same trouble with Lighttp
<http://www.lighttpd.net/>, and building it with static options
makes a huge server like 158mb and still it hard code the paths.
The MacOS X Apache server is not ready for FastCGI, for that we
need to install the modules, which is easy. Actually thats not
hard, simple commands and a revolution made stack could drive
that installation easy. But again MacOS X out-of-the-box lacks
the needed C compiler for that, only those that installed XCode
development tools have the needed stuff to build Apache Modules.
So here I am. The little servers all have some trouble or
another, the MacOS X bundled one is fine, but again, you need to
download 1GB XCode tools just to build simple couple megs apache
module...
any clue out there folks? is there any autoconf magician here
that can build a lighttp install with relative paths instead of
absolute ones (I tried and it didn't like).
Can we use otool to rewrite the linkers absolute path using a
relative one like we do for frameworks (using @executable_path).
Argh, I am looking for help.
Andre
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
--
Pierre Sahores
www.sahores-conseil.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
--
Pierre Sahores
www.sahores-conseil.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
