I think that is all correct.

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Aaron Bartell
Sent: 02 September 2015 14:28
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Subject: Re: [WEB400] Question about Node.JS and XMLSERVICE

I might be missing something...

Kevin, your separate child processes (aka IBM i jobs) are manually created by you. My understanding is that these child processes have nothing to do with WebSockets and instead were only necessary to get around the blocking issues, correct?

I am *guessing* (I haven't tested this) that Node.js Websockets can operate within a single process with, potentially, multiple threads. The state would be held in the TCP/IP connection (see NETSTAT opt 3 for browser clients), correct?



Aaron Bartell
litmis.com - Open Source and IBM i. No Limits.


On Wed, Sep 2, 2015 at 8:19 AM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Again, thanks for the information. It doesn't sound like six (6)
threads in the main JOB would support very many Web-socket
connections. I seem to recall that broadcasts require persistent
connections. An Apache instance at a client's site is running upwards
to 4,000 threads to support HTTP connections, which timeout after
something like 60 seconds of inactivity. I wonder how scalable Node might be in comparison to the Apache based server?
Is the number of Node or Sails threads configurable?





On Wed, Sep 2, 2015 at 7:02 AM, Kevin Turner <
kevin.turner@xxxxxxxxxxxxxxxxxxxx> wrote:

Yes that is right. The main node app is a web socket server, and
the child node processes are listeners that wait for entries to
arrive on a keyed data queue (one child per key). When they get
data, they pass it back to main process to broadcast to the subscribed clients.

One thing I did notice when I started looking at the stats was that my
main process was consuming a ridiculous amount of CPU. A major
worry......until I realise what it was. My app is actually a Sails.js
app
that uses Express.js under the covers. Sails also uses something
called Grunt that watches for changes to certain files and then redeploys them.
That was totally superfluous to my requirements, so I disabled Grunt and
the CPU usage returned to next to nothing. Phew! I didn't have the
time
or inclination to find out why Grunt was doing this. I suspect I
needed
to
reconfigure it slightly for this platform - but I couldn't be bothered.


--
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 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 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
Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton
Hampshire
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.