Katir,
I forgot to precise, in the previous mail, that the tasks queued to
the Rev deamon is'nt managed by the Rev deamon it-self (Rev is not so
good in about this) but by Apache+PHP, so the Rev deamon always just
know about one task after the other and never twice at once. Because
Apache does this part of the job in multi-thread mode, the result is
for us that the global server-side process "Apache+PHP+Rev" works
just alike a 100% multiprocess system would do with just a small
difference : it works then time faster than the Tomcat, JBoss or
Websphere based solutions...
Best,
Pierre
Début du message réexpédié :
De : Pierre Sahores <[EMAIL PROTECTED]>
Date : 26 août 2006 12:36:01 HAEC
À : How to use Revolution <use-revolution@lists.runrev.com>
Cc : Pierre Sahores <[EMAIL PROTECTED]>, Sivakatirswami
<[EMAIL PROTECTED]>
Objet : Rép : Question: MacOS X Bundled Apache Server or Embeded
Web Server?
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
use-revolution@lists.runrev.com
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
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
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
--
Pierre Sahores
www.sahores-conseil.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
