[revServer] process timeout issue

[Jerry Daniels]

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 <jerry.daniels at me.com> wrote:
> 
> From: Jerry Daniels <jerry.daniels at me.com>
> Subject: Re: [revServer] process timeout issue
> To: "How to use Revolution" <use-revolution at lists.runrev.com>
> 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
>> use-revolution at 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 at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution