[revServer] process timeout issue

[Jerry Daniels]

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 <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: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 <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
> 
> _______________________________________________
> 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