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



One of the great thing with the apache/ILE CGI stateless environment is that
it doesn't have to start and close jobs for every request.

Programs has to be loaded, files has to be opened, authority has to be
checked,
servive program has to reinitiated, new activation groups has to be
initialized,
library list has to be set and so on.

It may today seems like a fast process, but it is still a big overhead
compared
with the actual processing a request the job has to do.

On Sun, Oct 11, 2015 at 6:39 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Richard,

Your hypothesis about the "toolkit" launching a new JOB would be worth
checking into. "ipc" is an optional parameter in the toolkit's iConn()
function and the documentation is not clear about what happens if you don't
set a value for it.

Some source code examples suggest assigning a value of "*na" to ipc to
launch a "stateless" server, which implies using a single JOB to support
multiple concurrent clients.



On Sun, Oct 11, 2015 at 9:47 AM, Richard Schoen <
Richard.Schoen@xxxxxxxxxxxxxxx> wrote:

I wonder if the loop is forcing a new job start each time on the i.

With XMLCGI, there is an IPC service that takes a few seconds each time
it's re-initiated and I could see this being intensive if you had to
create
a new session for each interaction.

You can start the IPC session with a unique name and use the same job
over
and over if I want to maintain state and use the same job on the I which
should improve performance I think.

Not sure how the node toolkit works, but this works good with .Net and
should be similar depending on how the toolkit was implemented.

Regards,

Richard Schoen | Director of Document Management Technologies,
HelpSystems
T: + 1 952-486-6802
RJS Software Systems | A Division of HelpSystems
richard.schoen@xxxxxxxxxxxxxxx
www.rjssoftware.com
Visit me on: Twitter | LinkedIn
----------------------------------------------------------------------

message: 1
date: Sat, 10 Oct 2015 22:32:23 +0000
from: Kevin Turner <kevin.turner@xxxxxxxxxxxxxxx>
subject: Re: [WEB400] Why does node's Toolkit for i, use a database
connection to execute CL commands?

It may or may not be of interest or relevant, but we have lots of code
that sits and waits of data on a keyed data queue. It waits for 5 seconds
then loops round and checks some stuff (like an instruction to end) then
waits again.

When I did the same in a node app using itoolkit, the LPAR simply died on
its feet. It wasn't obvious why because the node app was not showing up
as
using much CPU. However it certainly was the culprit - I changed to wait
for 60 seconds instead as it wasn't essential to loop every 5 secs. The
problem went away.

On 10 Oct 2015, at 15:58, Nathan Andelin <nandelin@xxxxxxxxx> wrote:


--
This is the Web Enabling the IBM i (AS/400 and 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.


--
This is the Web Enabling the IBM i (AS/400 and 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.





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.