|
So what you are saying is that the call to read the data queue is part ofthe DB2 adapter, and stays in the program stack until it completes rather
So what you are saying is that the call to read the data queue is part of
the DB2 adapter, and stays in the program stack until it completes rather
than dropping something on the "web api" stack. That makes more sense. I
like the animations, and the little tool behind this video. Makes it easier
to understand what is going on.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
-----Aaron Bartell <aaronbartell@xxxxxxxxx> wrote: -----
To: "Web Enabling the IBM i (AS/400 and iSeries)" <web400@xxxxxxxxxxxx>
From: Aaron Bartell <aaronbartell@xxxxxxxxx>
Date: 10/13/2015 03:28PM
Subject: Re: [WEB400] Why does node's Toolkit for i, use a database
connection to execute CL commands?
Awhile back I dug deep to learn about the Node.js/Javascript event loop. I
found the following and I'd highly recommend watching it.
http://latentflip.com/loupe
The kicker that breaks a single Node process is when something is blocking
in nature, and that can happen simply by writing a bit of Javascript
incorrectly (assuming the intention was to NOT block). Note, currently the
DB2 adapter for Node.js is blocking. This more or less necessitates
multiple Node.js processes so you don't end up with a waiting line of web
requests.
​
Aaron Bartell
litmis.com - Services for open source on IBM i
On Tue, Oct 13, 2015 at 2:06 PM, Mark Murphy/STAR BASE Consulting Inc. <
mmurphy@xxxxxxxxxxxxxxx> wrote:
I recognize this technique, but, due to my knowledge of node beinglimited
at best, I have to wonder if this is an appropriate technique using node.hence
That is, since Node is event driven, should there be a need to wait, and
then loop around and check conditions again. RPG is not event driven,
the need for such a loop. But I was under the impression that Nodealready
incorporates this event loop and will call the appropriate function whendeeper
the event occurs. I would expect to have to register to receive the event
in some way, but not to have to code the event loop.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
-----Kevin Turner <kevin.turner@xxxxxxxxxxxxxxx> wrote: -----
To: "Web Enabling the IBM i (AS/400 and iSeries)" <web400@xxxxxxxxxxxx>
From: Kevin Turner <kevin.turner@xxxxxxxxxxxxxxx>
Date: 10/11/2015 04:44PM
Subject: Re: [WEB400] Why does node's Toolkit for i, use a database
connection to execute CL commands?
That's interesting stuff - thanks. I'm not entirely sure how to dig
but I will try :)Richard.Schoen@xxxxxxxxxxxxxxx>
On 11 Oct 2015, at 17:47, Richard Schoen <
wrote:create
it's re-initiated and I could see this being intensive if you had to
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
a new session for each interaction.up
over and over if I want to maintain state and use the same job on the I
You can start the IPC session with a unique name and use the same job
which should improve performance I think.
should be similar depending on how the toolkit was implemented.
Not sure how the node toolkit works, but this works good with .Net and
HelpSystems
Regards,
Richard Schoen | Director of Document Management Technologies,
T: + 1 952-486-6802that sits and waits of data on a keyed data queue. It waits for 5 seconds
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
then loops round and checks some stuff (like an instruction to end) then
waits again.
on its feet. It wasn't obvious why because the node app was not showing
When I did the same in a node app using itoolkit, the LPAR simply died
as using much CPU. However it certainly was the culprit - I changed towait
for 60 seconds instead as it wasn't essential to loop every 5 secs. Themailing
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)
listto
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 email has been scanned by iomartcloud.
http://www.iomartcloud.com/
________________________________
NOTICE: The information in this electronic mail transmission is intended
by CoralTree Systems Ltd for the use of the named individuals or entity
which it is directed and may contain information that is privileged oror
otherwise confidential. If you have received this electronic mail
transmission in error, please delete it from your system without copying
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.
--
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.
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 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.