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
