× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks for clarifying that Kevin.

Jim


Before printing this e-mail please consider if it is necessary to do so

This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Kevin Turner
Sent: Wednesday, January 05, 2011 7:51 AM
To: 'Web Enabling the AS400 / iSeries'
Subject: Re: [WEB400] Summing up the Icebreak discussion

Just to clarify, I started the discussion because I wanted to try
IceBreak as an alternative to Apache for Renaissance. I have been
working on this for about a day and I am pretty close to getting it
working. IceBreak does not use Apache as a front-end - I am not sure
where that assertion comes from. I am using Icebreak with Renaissance
(and therefore all the underlying CGIDEV2 procedures) without any Apache
server in the equation at all. I am not using any of the nice Icebreak
runtime compilation stuff at all at the moment - I simply tell it to
call my own routing program via the URL which uses the Icebreak
procedures to get the request data and return the response (instead of
the normal stdin/stdout procedures).

It is too early to tell if this will be a worthwhile exercise or not,
but given that our largest customer has some odd things happening with
Apache (on a very large box under extreme load), and IBM have not been
able to understand why, I am keen to see if there is a viable
alternative.



-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Nathan Andelin
Sent: 05 January 2011 12:29
To: Web Enabling the AS400 / iSeries
Subject: [WEB400] Summing up the Icebreak discussion

We've just returned from vacationing in Spain with family, so I'm just
catching
up with the list. There appears to be a lot of misinformation shared in
the
Icebreak discussion that is causing confusion. It appeared to begin
with Jim T.
asserting that Icebreak included its own HTTP server as an alternative
to
Apache, and implying that it performed 10 times faster than CGIDEV and
other web
frameworks. Scott. challenged that claim, and so would I. Niels finally
admitted that Icebreak uses Apache on the front end. And I'd bet that
Icebreak
performance is fairly in-line with CGIDEV2. I'd suggest running a
benchmark if
anyone feels strongly to the contrary. I wouldn't mind collaborating on
a
simple benchmark.

There was some discussion about scalability. Aaron Bartell indicated
that he ran
into a TCP limit and Joe Pluta followed up with some rather vague
comments about
a limit of 256, and a couple hundred jobs before things go casters up,
and a
need for horizontal scaling. I was confused by that, at least.

Then discussion erupted over stateful vs stateless architecture where
state may
be managed automatically by giving each user their own job vs. many
users served
by a few jobs. Some people seemed to understand that saving and
restoring
session state in multi-user jobs was resource consuming while others
expressed
concern over giving each individual user their own job and having IBM i
allocate
memory, CPU and other resources to each; they seem to understand
intuitively
that allocating memory to and swapping thousands of jobs in and out of
the CPU
could be resource consuming too. More uncertainty.

The metaphoric likeness between Icebreak, JEE Application servers, and
ASP .Net
was confusing. Maurice and Richard didn't seem to catch the metaphor at
all,
initially. Giving allowance, the comparison was vague. Under stricter
interpretation, it was misleading. For example, under JEE and ASP .Net
a
potentially large number of disparate applications run within a single
container
- a single process - a single job - multiple threads. Under Icebreak,
each user
may have their own job, evidently. If that's the case, why label
Icebreak a
"container" and say it's like JEE and MS runtime environments?

-Nathan




--
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.


NOTICE: The information in this electronic mail transmission is intended
by CoralTree Systems Ltd for the use of the named individuals or entity
to which it is directed and may contain information that is privileged
or otherwise confidential. If you have received this electronic mail
transmission in error, please delete it from your system without copying
or forwarding it, and notify the sender of the error by reply email or
by telephone, so that the sender's address records can be corrected.



------------------------------------------------------------------------
--------


CoralTree Systems Limited
25 Barnes Wallis Road
Segensworth East, Fareham
PO15 5TT

Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton, UK
SO15 2EA
VAT Registration Number 834 1020 74.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.