Fwd: IceBreak as an alternative to Apache?

[Niels Liisberg <liisberg@xxxxxxxxxxxxx>]

> Hi Thor;
>
> My answer in you mail: 
>
> Den 30/12/2010 kl. 22.59 skrev Thorbjoern Ravn Andersen:
>
> > Den 30/12/10 22.30, Niels Liisberg skrev:
> > > Hi Thorbjørn;
> > >
> > > There is nothing wrong with apache!! it is a fantastic web-server... The problem is the CGI part and fact that apache is well suited for running thread where you in RPG normally would like to have a process - namely a IBMI job.  So typical you have to (re) design you app to relocate resources whenever you have a new request from the "next" session. Which again makes i.e. commitment control almost impossible - or at least a nightmare..
> > >
> > > Some have implemented persistence in CGI ( now we are only talking ILE/RPG/COBLE - and down that road) however, that just adds to the CGI overhead.
> > >
> > > So the 10-factor holds in IceBreak. It is, however,  more in the manner - 10 times less resources is needed due to the added unnecessary stuff applied to your code and due to the number of layers.
> > Hi Niels.
> >
> > I am not doubting your figures.  I just try to understand how it happens.
> >
> > Sorry for not understanding this immediately, but I am not very familiar 
> > with how the non-Java things work on the i.  Does this mean that you map 
> > each session to its own IBM i job, and let it keep state from invocation 
> > to make it very fast to handle each response?  And said job is then 
> > finished when the session expires?
>
> You got it !!
>
> In java apache work absolutely fantastic. Any request maps into a thread which again has almost no cost.
> In IceBreak we also create one thread for each client request, serve the data from the thread if it is static contents. If it is dynamic (some program call) we serialize all session requests into one job IBMi job for each session. we let the job be purge-able and let IBMi do the rest. This results in more clean code, superb solation which again allow us to use commitment control etc in a webjob. And best of all the job we create has a super tiny system foot print which again lets us have 1000 jobs on an old crappy 170      
>
>
>
> > But I do not understand what you mean by "commitment control".  Could 
> > you elaborate?
>
> sql update tbl01 set a=123;
> sql commit; 
>
>
> .. Units of work - you dont even think of that as problem when you code in tomcat, but for apache/CGI it will not work since all sessions is in the same unit of work.. (unless you do some ugly stuff) 
>
>
>
>
>
>
>
>
>
> > -- 
> >
> >  Thorbjørn Ravn Andersen  "...plus... Tubular Bells!"
> >
> > -- 
> > This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
> > To post a message email: WEB400@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/web400
> > or email: WEB400-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/web400.