Re: 'green screen' not sellable --> WE(?) are the problem

Nathan

<iframes> is not the problem, AJAX is since many modern UI's
initiates parallel AJAX conversations.

To illustrate that here is what happens when I fire up my Viewport.

The Viewport has an accordian menu where each main topic is an
object that is populated by the server through an AJAX call.

This means that if there are 5 main topics the client will fire five
AJAX call's to the server for the menu content under its topic.

What happens behind the scene is illustrated here:

http://www.powerext.com/RESTTIER0.png



On Thu, Jun 11, 2015 at 5:07 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Henrik,

Thanks for the reply. If I understand correctly, there are at least two
problems with "persistent CGI". First, when the "maximum" threshold is
reached, then existing "sessions" may be closed to accommodate new users.
The second problem is that developers may be forced to create some rather
unique plumbing in order to accommodate certain application designs, such
as using <iframes>, where each frame may need to implement AJAX.


On Thu, Jun 11, 2015 at 8:07 AM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Nathan



It is a combination of several things.



Normally the Apache server runs it QZSRCGI jobs under a common

userprofile

(serverUserId) in the config file. That is that the QZSRCGI job actually
runs under user QTMHHTTP as job user id and the common user from the

server

config as adopted/actual user profile.



The number of possible QZSRCGI jobs under and Apache instant is also a
config setting.



If all QZSRCGI jobs are active processing and a request comes in the
request I queued until a QZSRCGI job is idle.



When you set up the Apache to run persistent this scenario is changed.
QZSRCGI jobs now runs under the real user profile as adopted/actual. A

new

request will cause apache to create a new QZSRCGI job for the requesting
user.



When the allowed number of active QZSRCGI jobs is reached and a new user
makes a request the trouble starts. What Apache will do is to find the
first idle QZSRCGI job allocated to another user, close it down and

start a

new QZSRCGI job for the new user. This will of course mean that the

closed

job will lose persistency.



Now, today we run AJAX and AJAX may fire parallel requests from one

client

against the Apache server. The Apache server will not queue this request
for one QZSRCGI job but execute them in different QZSRCGI jobs and that
doesn’t matter if you run stateless or persistent.



So suddenly one user may have a number of in this case persistent QZSRCGI
jobs and nobody knows which of the jobs are used for a single request.

This

will of course also add to the overhead of closing and restarting QZSRCGI
jobs when the maximum threshold is reached.



There may be techniques to avoid this behavior, but as standard I will

not

call it persistent.

On Thu, Jun 11, 2015 at 3:36 PM, Nathan Andelin <nandelin@xxxxxxxxx>
wrote:

PS. If you run Apache there is no such thing as persistent CGI but

that

is

another rather long story. If you like I could explain it.

Henrik,

Yes, I would be interested in your views about "persistent CGI" under
Apache. My understanding is that Profound UI uses it. And it seems to
maintain a session which may time-out after a period of inactivity.

What

makes you say there is "no such thing"?

BTW, I agree with your method of storing "session" variables in an IBM

i

DB, keyed by a secure value.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.