Have you tried debugging the CGI app to see if it's the program or the
network that is the issue?

I would think stepping through any resource intensive spots in the program
may lend a clue.

Since you mention you're using QtmhWrStout I am assuming that you're not
using a toolkit like CGIDEV2 or ERPGSDK. Just wanted to make sure.

Here's a link to an article I wrote on debugging CGI as it's a little
different (it is similar but not as bad as debugging batch programs).
http://www.fieldexit.com/forum/display?threadid=48


Bradley V. Stone
www.bvstools.com
Native IBM i e-Mail solutions for Microsoft Office 365, Gmail, or any Cloud
Provider!

On Mon, Feb 20, 2017 at 12:09 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Call it what you want ;-)

I have a CGI-program that writes a buffer out via qtmhWrStout, i may call
qtmhWrStout one or several times
for the same transaction and it still works. There is no way to signal to
QtmhWrStout that the last call is the
last call so there is no way the HTTP header knows the length of the data
that follows.

Since qtmhWrStout dosn't know when the stream end my program isn't ending
(*lr = on) there is no way
Apache can know when data tream ends.

The whole transaction takes about 1.5ms in the cgi program running an SQL
and generating a JSON object.

I can btw build in a delay of 50ms between calls to qtmhWrStout it dosn't
matter if the CGI program runs
for 151.1ms instead of 1.5ms the time in the other end just takes around
180ms.

When I call it from my browser the entire call takes around 35ms so about
33ms is lost in transfering the
about 4K of data somewhere.

If I do the same from a node.js program running in the machine calling the
service over port 127.0.0.1 where
there are no network latency it takes excactly the same time - 35ms so
somewhere 33ms is lost in unaccouted
time.


On Mon, Feb 20, 2017 at 4:36 PM, Kevin Bucknum <Kevin@xxxxxxxxxxxxxxxxxxx>
wrote:

What we call ajax is actually an XMLHttpRequest. There are messages that
set different states. Along with the states it sends byte counts for
various stages of the process. When it gets to the state that indicates
that it's done, it checks the bytes received against what it was told to
expect, and if it matches, starts processing the response.
https://xhr.spec.whatwg.org/





Kevin Bucknum
Senior Programmer Analyst
MEDDATA/MEDTRON
Tel: 985-893-2550

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of
Henrik Rützou
Sent: Saturday, February 18, 2017 2:15 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] QtmhWrStout

Tanks,

but how does AJAX call know when e.g. a JSON file send is finish so the
AJAX
starts to process the data it receives?

On Sat, Feb 18, 2017 at 9:03 AM, Stefan Tageson
<Stefan.Tageson@xxxxxxxx>
wrote:

since you may call QtmhWrStout repeatly to flush the total data to
a
browser through StdOut how do you tell it that it is *EOD so it close
the connection?

Hi Henrik,

As the browser established the connection, it will be in charge for
closing it as well. If your server does not reply in due time then a
timeout will occur.
Normally the browser "knows" when to close the connection based on
the
data you sent.

Best regards

stefan.tageson@xxxxxxxx
M +46 732 369934


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




--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
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.




--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
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 ...

Follow-Ups:
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.