Somebody ask a question about Revolution. Please. On Aug 2, 2010, at 9:27 PM, Michael Kann wrote:
> Jerry, > > It's like when my wife says, "Ok, do whatever you want." Then I know I'm > really in trouble. > > Mike > > --- On Mon, 8/2/10, Jerry Daniels <[email protected]> wrote: > > From: Jerry Daniels <[email protected]> > Subject: Re: [revServer] process timeout issue > To: "How to use Revolution" <[email protected]> > Date: Monday, August 2, 2010, 9:20 PM > > I just said "yes" > > On Aug 2, 2010, at 9:19 PM, Michael Kann wrote: > >> Jerry and Robert, >> >> To summarize: >> >> Austin and Edinburgh got into a pissing match. >> >> Mike >> >> >> >> --- On Mon, 8/2/10, Jerry Daniels <[email protected]> wrote: >> >> From: Jerry Daniels <[email protected]> >> Subject: Re: [revServer] process timeout issue >> To: "How to use Revolution" <[email protected]> >> Date: Monday, August 2, 2010, 9:15 PM >> >> Robert this is a lo-o-o-o-ong post. >> >> On Aug 2, 2010, at 8:16 PM, Robert Mann wrote: >> >>> >>> Please let us not fall into the "bloody" trap of personnal feelings, >>> whatever >>> mood swing is expressed here or there. This list is a fantastic oportunity >>> to collaborate from all over the world, for us, for our interest, not >>> against anybody's interest !! ok? >>> >>> The issue between Kevin and Jerry could well be that runrev would have >>> benefited from Rodeo potentially if it had decided (as was once upon a time >>> announced) to distribute revServer for free (the original "pitch" was : >>> we'll make revServer available for free but offer the on-rev service and let >>> you developpers sell protected stacks, this is what I understood and >>> bought!). >>> >>> If that road had been followed, rodeo, if successful, could have given a >>> hand to runrev and propagate revServer with the rodeo sites that can be >>> exported from the rodeo environnment... But at the price of revServer, that >>> is not possible anymore, so that rodeo has to go to PHP, anyways. Full stop. >>> >>> It may well be that his opening of rodeo was triggered by the revServer >>> limitations that rodeo experienced (and boy I won't beleive they invented >>> that...) which led them to consider moving to PHP and thus allowing to >>> export more widely rodeo apps.. etc... >>> >>> What I have understood of Jerry's path these last years is that he protyped >>> using runrev, tried it hard, but then was carried to develop more solid >>> tools outside runrev like tRev, rodeo app, and now rodeo-php. He >>> communicates and shares his experiences, so we here about it. And it is >>> disturbing to all of us who "beleive(d)" in revTalk... >>> >>> So the issue we're concerned with revServer is : is it yet another >>> prototyping tool only or is it a solid work horse server? Let's find out! >>> >>> A) Is there a problem? >>> >>> ++> There is a problem >>> Rodeo team (poor load and performance test of rodeo apps) >>> Bob Sneidar (experienced unexplained time lags) >>> Pierre Saohres (i can see this happen with the early requests to >>> woooooooords.com : The first request can, time to time, take around 20 secs. >>> After this first request, the next ones are always back to the user in less >>> than some ticks.) >>> Kevin Miller (do not communicate their test benches, so performance problem >>> is plausible) >>> Andre Garzia (You can also notice that there were requests that took 15 secs >>> and others that took 3 secs, which is odd since they were all hitting the >>> same page. What we can infer from this simple thing is that there are places >>> that RevServer needs working but it also means we need more focus to find >>> where and why it breaks) >>> >>> --> There does ot seem to be a problem >>> Pierre Sahores (limitations set in revServer ar standard) >>> Kevin Miller (we do not have enough feedback) >>> >>> >>> >>> B) What are the possible causes of the problem? >>> >>> Rodeo team (We think there is some sort of pooling of processes (and >>> possibly users) that are limited by 30 secs. We have seen the timeout in >>> much shorter time spans. Andrew reports a 4 second time out. >>> >>> Pierre Sahores (setting 30 sec limits and 64 mb limit is standard practice, >>> Could be a problem related to the RAM virtualisation of the RHEL5 host it >>> self, httpd.conf, etc... ) >>> >>> C) consequently what precautions have revServer developpers to take >>> -- do we have to re-send post or get if no answer after a while? any >>> suggested routine to do so? (thank you runrev team to help too!) >>> >>> D) consequently what is revServer ok for and what it is not ok for. >>> -- do we have to postpone any serious launch of revServer, on-rev services >>> until the beta test ends and a version one is officially launched? >>> >>> >>> -- >>> View this message in context: >>> http://runtime-revolution.278305.n4.nabble.com/revServer-process-timeout-issue-tp2310168p2311192.html >>> Sent from the Revolution - User mailing list archive at Nabble.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 >> >> >> >> >> _______________________________________________ >> 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 > > > > > _______________________________________________ > 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
