Re: Bug in HTTP API's http_req() procedure - leaving connections open

No, HTTP LIB has an arbitrary hard coded limit of 224...see this message.

http://www.scottklement.com/archives/ftpapi/201504/msg00093.html

Usually not an issue, but we were originally running this process in a
generic job that pulls requests from a DTAQ and runs various processes.

Charles

On Mon, Jan 21, 2019 at 11:47 AM Kevin Bucknum <Kevin@xxxxxxxxxxxxxxxxxxx>
wrote:

I wonder if DosSetRelMaxFH would help? I use it like this in one of my
programs.

*-- DosSetRelMaxFH --- Change Maximum Number of FIle Descriptors
*
d Dossetrelmaxfh PR 10I 0 Extproc('DosSetRelMaxFH')
d Pcbreqcount * Value
d Pcbcurmaxfh * Value

c Eval Setfd = 0
c Eval Curfd = 0
c Eval Rc = Dossetrelmaxfh(%ADDR(Setfd):
c %ADDR(Curfd))
c Callp Dsperror(%CHAR(Curfd))
c Eval Setfd = 250
c Eval Curfd = 0
c Eval Rc = Dossetrelmaxfh(%ADDR(Setfd):
c %ADDR(Curfd))
c Callp Dsperror(%CHAR(Curfd))

First call just retrieves the current values. First parm is the number of
descriptors you want to add or subtract, and the second parm gets the new
number of descriptors available. So passing 0 0 gets me back 0 200 the
first time, and then 250 0 gets me 250 450 back. I log that out in the
DSPERROR routine and gets something like this.
DSPLY 200->0000000000:There is no error.
DSPLY 450->0000000000:There is no error.

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of
Charles Wilt
Sent: Monday, January 21, 2019 11:09 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Bug in HTTP API's http_req() procedure - leaving
connections open

Just a follow up....

It appears that other programs running in the job are leaving
connections/files open (by design (mostly?)) and once we happen to get a
socket# higher than 224 we start seeing issues in HTTP API; and the
response file and/or connection gets left open when HTTP API crashes.

The Java JVM for instance has 180+ open file descriptors, mostly to
various JAR files.

When we run our new HTTP API process all by itself in a job, we don't see
any issues.

Charles



On Fri, Jan 11, 2019 at 11:27 AM Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

Since the FTPAPI list is having problems, thought I'd post here...

Running v1.33 of HTTP API, and noticing connections sometimes being
left open by the HTTPS calls that use the http_req() procedure.

Noticeable only because it's happening in a set of long running job
making 50,000+ calls...

Problem manifested as "out of range" error "One of the following has
occurred in RPG procedure COMMTCP_FD in program
LIBHTTP/HTTPAPIR4: - A numeric length or start position is less than 1
or too large for the string operation.describe her in this message"

as described here...
http://www.scottklement.com/archives/ftpapi/201504/msg00093.html

It seems we're a few versions behind...

Changes to version 1.39 from 1.38:

- Fixed ALGD0200 declaration in ENCRYPTR4 -- though, this should

not impact current users. (Thomas Raddatz)

- Correct international handling of $Version string in Cookie

header routines.

Changes to version 1.38 from 1.37:

- Added memory alloc/dealloc diagnostic routines

- Fixed memory leaks -- comm drivers were not cleaned up

- fixed mismatches with regular alloc vs xalloc

Changes to version 1.37 from 1.36:

- Fix problem where debugLevel not propagated properly

- Added buffering to COMMTCPR4 to improve LineRead performance

- Added buffering to COMMSSLR4 to improve LineRead performance

Changes to version 1.36 from 1.35:

- Fix problem where http_persist_close() would get a pointer error

if http_persist_open() failed during SSL handshake.


The changes in 1.36 and 1.38 seem most likely to be related. Trying
to get the latest version put on to test.

But I'm hoping somebody here as seen the issue and can confirm it's
fixed in a later version when I push management for the upgrade.

Thanks!
Charles

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list To post a message email: WEB400@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx Before posting, please take a
moment to review the archives at https://archive.midrange.com/web400.



[https://www.medtronsoftware.com/img/MedtronMinilogo.bmp] Kevin Bucknum
Senior Programmer Analyst
MEDDATA / MEDTRON
120 Innwood Drive
Covington LA 70433
Local: 985-893-2550
Toll Free: 877-893-2550
https://www.medtronsoftware.com



CONFIDENTIALITY NOTICE

This document and any accompanying this email transmission contain
confidential information, belonging to the sender that is legally
privileged. This information is intended only for the use of the
individual or entity named above. The authorized recipient of this
information is prohibited from disclosing this information to any other
party and is required to destroy the information after its stated need has
been fulfilled. If you are not the intended recipient, or the employee of
agent responsible to deliver it to the intended recipient, you are hereby
notified that any disclosure, copying, distribution or action taken in
reliance on the contents of these documents is STRICTLY PROHIBITED. If you
have received this email in error, please notify the sender immediately to
arrange for return or destruction of these documents.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.