Re: IceBreak as an alternative to Apache? -- WEB400

Hi Gents

Aaron wrote:
The way I have kept state in the past is to have batch jobs listening to
data queues that are waiting for requests. Then you have a "mother router"
program that sits under Apache listening for requests and marrying them up
with the correct data queue based on the session id passed up from the
client.

I am not sure if that is the same thing being described by IceBreak/Niels,
so I would be interested to hear how they are doing it.

It sounds a little a like. IceBreak however, implements a lot of other stuff:

- Wether or not the to call into the persistent job
- Timing / purging / re-invoke persistent job
- Persisten 5250 integration (IceCap)
- producing ExtJS datastores ( persistent or non-persistent)
- producing XML ( persistent or non-persistent)
- run QUERY/400 query 400 queries returning ExtJs datastores or XML
- LDAP and Active Directory integration
- login via RESTservices or via Apache CGI
- httpRequest - webservice calls
- SOAP services
- XML / X-Path
- RFC 2616 - Hypertext Transfer Protocol: 3.6.1 Chunked Transfer Coding" so the RPG program literally puts the data directly back to the client.

... just to name a few

Joe Pluta wrote:
I have absolutely no issues running hundreds of users through stateful
connections. The only thing you need to do is make sure you assign (and
dedicate) enough memory to the JVM. Stick 500MB in its own subsystem
and run your JVM there. As your needs grow, you add some more memory to
that subsystem. But really you don't need a lot; that subsystem is just
a thin layer over your RPG business logic. The RPG then runs using
normal IBM i memory management which is tuned to support thousands of users.

Joe - you are absolutely right. The IBMi is especially good a one specific feature: job management. So we just let IBMi do what it is best at - task switching - keeping track of QTEMP, filepointers, units of work/commit control, paging, prioritizing etc.

The only difference Joe is that IceBreak don't need that much RAM - we don't use Java. Our application stack is so tiny - it is ILE, so we only have one procedure your app waits on. If your app terminates with *INLR the complete persistent job only requires 8MB per session - I will not go into the *INLR / or not discussion - but just say that the IceBreak stack just reflects the stack of an old 5250 app. - If you open lots of files and keep the open : it is not my business - If you use *INLR or return it is not my business - My business is that you can have it with vanilla or strawberry as you like....

Regards

Niels

On Fri, Dec 31, 2010 at 2:03 PM, Maurice O'Prey <Maurice.Oprey@xxxxxxxxx>wrote:

OK Joe

Thanks for the clear introduction to 'State'. I understand that the
'session
id' is stored in a cookie or in a cookieless environment it is included in
the request or query string.

My question really is how do people using the i store the information that
is related to that session ID, e.g. in server memory (by Session ID),
written to disk (out of state storage) or is there an application level of
State, again stored in server memory?.

Can 'State Objects' be stored in the Server Cache and retrieved from there,
if so what types of objects can be stored and how are they retrieved and
re-instantiated?. Is there an equivalent of ViewState as used in .NET? Of
course there is a painful overhead but that can't really be avoided.

I guess the answer differs depending on whether your using, RPG(le), PHP,
EGL or other.

- Maurice

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