If one could replace the stdin and stout handles with sockets a fork could be executed for redundcy a pipe proxy can be created for the remote process (created via sshd ir what ever sheel system you wish to use).
I have been conversing with RR developers about this topic. Kevin -==-=-=-=-=-=-==-=-=-=-=-=-=-=-==-=-=-=-=-=- Disclaimer: Any resemblance between the above views and those of my employer, my terminal, or the view out my window are purely coincidental. Any resemblance between the above and my own views is non-deterministic. The question of the existence of views in the absence of anyone to hold them is left as an exercise for the reader. The question of the existence of the reader is left as an exercise for the second god coefficient. (A discussion of non-orthogonal, non-integral polytheism is beyond the scope of this article.) --- On Wed 08/04, Pierre Sahores < [EMAIL PROTECTED] > wrote: From: Pierre Sahores [mailto: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Wed, 4 Aug 2004 18:42:38 +0200 Subject: Re: Advise on enterprize application + clustering Grettings, All,<br><br>Le 3 ao�t 04, � 08:01, MisterX a �crit :<br><br>> This is getting interesting... A bit of everything to solve<br>> your problem (x's famous howitzer approach). The last part<br>> may be even more interesting than the first. Remember that<br>> enterprise means also redundancy and zero-downtime ;)<br><br>!!! --> Always have this in mind (aka : only ACID compliant RDBMS <br>back-ends are eligibles there). In respecting this basis, the <br>applications server will always be cleanly designed (with, sorry for <br>the possibles Java's addicts reading us, to the end, Tomcat, JBoss no <br>more suitables at all than Metacard or Revolution...).<br><br><br>> Unfortunately there is some risks of lock ups if not done<br>> carefully... But here are 3 things you could try:<br>><br>> 1)<br>><br>> In a three tiered cluster strategy, mentioned in a clustering<br>> class I had recently, there were three actors<br>><br>> client -> server1 -> server2<br>><br>> client -> server2 is not possible because of the firewall.<br>><br>> but server1 -> server2 is fine and client -> server1 is ok2<br><br>An usefull ports translation strategy, always very suitable, even in <br>about proxying / firewalling applications servers...<br>><br>> if client cannot use sql but can use client1's ports,<br>> and assuming client1 and client2 can do the sql bit...<br>><br>> then you need a port configurable client server networking<br>> protocol.<br>><br>> in brief:<br>> RRclient -> RR on Server -> SQLserver<br>><br>> between RRclient and RRserver you use whatever protocol (80!)<br>> Best is to have your client ask their network administrator<br>> to see what is allowed and for what purpose.<br>><br>> If you saw the forms we have to fill in for these requests<br>> at my office you would scream!<br><br>For sure very cool and secure from the cluster administrator's point of <br>view...<br>><br>> 2)<br>><br>> For the clustering part now... For a redundant server...<br>> but you can have more than one server also...<br>><br>> Run two instances of RR. Named RRServer1 and RRS2.<br>> Now only one application must work with the port communication<br>> at the time but you can imagine either that one is locked up,<br>> not responding, or working hard. It would be nice to have RR2<br>> take over the next client's server call...<br>><br>> What you do, is create a temporary file called rr1alive where<br>> you write a frequent log - the frequency is the timeout for RR2<br>> to kick and start working.<br>><br>> There's the case where the RR1alive file is locked by the RR1,<br>> which should be working but which should be closing the file.<br>><br>> (is there a FileLocked(filepath) function in rr?)<br>> You can use the file's date from the extended files function to<br>> see the date anyway.<br>><br>> So if there is a timeout trying to read that file, RR1 must be<br>> locked. Terminate the proces s RR1. Relaunch RR1 and give it the<br>> hand when you finished the current client processing.<br>><br>> Note: usage of a different log for operations than the alivelog<br>> is worth the trouble. You could keep a log opened in the case of<br>> a processing but the alivelog should be kept closed to see when<br>> the last alive was logged to prevent a double server taking parts<br>> each of the same client's transactions (this can be prevented ez).<br>><br>> Since transactions with SQL could take a while and queue up clients<br>> you could imagine that another RRx takes over while the other<br>> apps finish their transactions.<br><br>Hum ! I like your proposal design, Xavier but why would we have to <br>reinvent the wheel of the "transactions manager concept" when we can <br>let Apache (on the in/out to public/VPN internet side) and the ACID-DB <br>transactions managers handle tthat all for our Rev's applications <br>server ?<br>><br>> 3)<br>> The cherry on the cake<br>><br>> Now, if RunRev implemented threading into RR for 3.0, we would have<br>> this process written into just one server application. It's one<br>> thing that differentiates Java from RR...<br><br>That's mainly marketing... Even if unofficial, the JAVA 1.4 best <br>practices recommandation is to never exced 3 simultaneous bytecode <br>threads per web-services (aka : best to let dedicaded parts of the <br>system handle such kind of tasks, including the Posix kernel's <br>multi-theading features (very well suited under Linux), the Apache and <br>ACID-DB servers ones).<br><br>> BUT wait a millisecond,<br>> requesting web urls is threaded and could be used also as a<br>> transaction protocol for any client over port 80 couldn't it?<br><br>True. Apache is build to handle that all for us (in synchronious mode) <br>in opening a new thread for each incoming request. By experience, the <br>MC/Rev applications servers are just best coached in this way than by <br>any internal transcript dedicated code and, because, the WAS works, in <br>practice,; always faster than the DB backend, there is no wa it at all, <br>each transaction thread after an other.<br>><br>> If well formed, im sure you can send xml or any data embeded into<br>> an client-side html-form request on good old port 80!<br><br>100 times true ! Simplicity is there the best entry to build secure <br>and clean...<br><br>> Using mysqlmgr in html, you can send loads of sql data via a form<br>> to the server.<br>><br>> ;)<br><br>Cool and very "pedagogique" (as we say so much, there, in France) post <br>! Thanks, Xavier :D<br><br>Best, Pierre<br>><br>><br>>> -----Original Message-----<br>>> From: [EMAIL PROTECTED]<br>>> [mailto:[EMAIL PROTECTED] Behalf Of Andre<br>>> Garzia<br>>> Sent: Tuesday, August 03, 2004 00:08<br>>> To: How to use Revolution<br>>> Subject: Re: Advise on enterprize application.<br>>><br>>><br>>><br>>> On Aug 2, 2004, at 6:51 PM, Mark Wieder wrote:<br>>><br>>>> Andre-<br>>>><br>>>> I'd have to agree with Trevor here that a multi-tiered approach is <br>>>> the<br>>>> way to go. I think you'll have an easier time of it than trying to<br>>>> stuff everything into a giant rev app (not to mention an easier time<br>>>> doing maintenance in the long run).<br>>>><br>>><br>>> Mark,<br>>><br>>> Thanks! Already on that path! I just need to know how to make that<br>>> database library work in the mc engine... it's not there...<br>>><br>>> Andre<br>>><br>>><br>>>> --<br>>>> -Mark Wieder<br>>>> [EMAIL PROTECTED]<br>>>><br>>>><br>>> --<br>>> Andre Alves Garzia � 2004<br>>> Soap Dog Studios - BRAZIL<br>>> http://studio.soapdog.org<br>>><br>>> _______________________________________________<br>>> use-revolution mailing list<br>>> [EMAIL PROTECTED]<br>>> http://lists.runrev.com/mailman/listinfo/use-revolution<br>><br>> _______________________________________________<br>> use-revolution mailing list<br>> [EMAIL PROTECTED]<br>> http://lists.runrev.com/mailman/listinfo/use-revolution<br>><br> ><br>-- <br>Bien cordialement, Pierre Sahores<br><br>100, rue de Paris<br>F - 77140 >Nemours<br><br>[EMAIL PROTECTED]<br><br>GSM: +33 6 03 95 77 70<br>Pro: +33 1 >64 45 05 33<br>Fax: +33 1 64 45 05 33<br><br>WEB/EAI services & ACID DB over >IP<br>"Mutualiser les deltas de >productivit�"<br><br>_______________________________________________<br>use-revolution > mailing list<br>[EMAIL >PROTECTED]<br>http://lists.runrev.com/mailman/listinfo/use-revolution<br> _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
