[revServer] process timeout issue

[Richard Gaskin]

Jerry Daniels wrote:

 > This thread has repeatedly gone from the revServer timeout issue
 > to personalities, Rodeo and its choice of technologies.

Respectfully, may I note that the last several posts on this (from Sean, 
Andre, Michael, and myself) have attempted to help focus the discussion 
on a rational analysis of the problem suggested, looking at this as a 
RevServer issue and not a Rodeo-specific one.  Given the potential 
usefulness of this new product, I think it's helpful to continue its 
exploration along these lines.

If Oliver's comment about "iRev" meant to refer to on-rev.com (which it 
turns out was the subject of that thread -- see 
<http://forums.runrev.com/phpBB2/viewtopic.php?f=8&t=4791>), the 
situation is readily understandable and poses no problem to anyone 
wanting to use RevServer on a dedicated server.  Shared-hosting servers 
commonly impose such limits on all processes, including PHP, and for 
good reason.  Anyone wanting to dominate a machine's CPU would expect to 
use a dedicated server.

If instead Oliver's comment was referring to the RevServer engine itself 
then it would indeed limit the appeal of the product for use on 
dedicated servers, but we have yet to determine:

a) whether that's the case.

b) if it is, whether that's the intended behavior when using RevServer 
on a dedicated server or is merely a bug which could be fixed in the 
next build.

c) how it's even possible for a single child process to govern aggregate 
server-wide limits (if it is there may be some useful hacks and/or 
interesting security exposures worth exploring).

So far the analysis provided by Andre and Pierre suggests that any 
limits on cycles or memory exit only in the common configs for shared 
hosting services such as on-rev.com and are not specific to the 
RevServer engine itself.  Andrew Dickey's astute comments in the forum 
and the improve-rev list refer only to on-rev.com; I haven't yet seen 
claims that such limits have been observed on a dedicated server.

For my own part, while I have no experience with RevServer itself yet 
I've done enough work on public sites using Rev CGI that I know the 
RunRev team is capable of delivering a robust, flexible engine that 
performs on par or better than many alternatives (Rev's well-optimized 
chunk expressions rule for many server tasks).  One of the systems I've 
developed is used by hundreds of hospitals worldwide with Rev-based CGIs 
handling login, registration, and even a custom search engine and it's 
held up quite well, so I feel we all have good reason expect the same of 
at least the release version of RevServer if not the version we have 
available now.

I have no opinion about Rodeo or its choice of technologies, and as far 
as personalities go I like yours a lot and like many here regard Sarah 
as a generous code goddess. :)

My interest here is simply that I have a lot of resources invested in 
the Rev CGI and may migrate some of those to RevServer, so it's useful 
for me and anyone else here considering RevServer to pursue a solid 
understanding of that engine.

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv