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


  • Subject: Re: Bug in HTTP API's http_req() procedure - leaving connections open
  • From: Charles Wilt <charles.wilt@xxxxxxxxx>
  • Date: Mon, 21 Jan 2019 10:08:56 -0700
  • Arc-authentication-results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=YyOrFAWx; spf=pass (google.com: domain of charles.wilt@xxxxxxxxx designates 209.85.220.41 as permitted sender) smtp.mailfrom=charles.wilt@xxxxxxxxx; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=+BC6Rb/9jTvLpX1ZMgqdQCExKxLhX1xhNqMpHNLrpTo=; b=RqCDPWEN7EfTdeQxRWhBBnRwYK4FaOEfMi3TVALdXGbVlc1gJBo7o/5lvDZQLPDhdm CQgPj7xnGY3/sMbehbTtEw+aa0nVrcsCdWHC6ZvaFHoRgXwwMusSGNYO6nQPQKhnmiWG KrlJUWSGHCiKyyDFRHNZIWafr4kR9rdVjBHZ7D/xyoIpfTFPO3VVLbLmcJyNb+77WKiP LiU8W43Bmd5iFZAYhvO0EKmfEU/8SUYV4t3jz/58nQmaJdwle/i96go0fo5CYo0ECNQO Vs5RG0OIBIS8pEU/c7J559GeODZCLDLVmTQFWXRPhoYlDjZK7y5To50WrlY1n5fuRtaT +fsg==
  • Arc-seal: i=1; a=rsa-sha256; t=1548090548; cv=none; d=google.com; s=arc-20160816; b=asDtuI2nRXT5ZW+n0g1sz59Fxb6xzhPsa7J61MN4ttN+6KnJ5gIzvd5aSWcy3QLt3P CL05ypqGQEu5BAl0aOxgMiJkEgAex/rOwCTMS7nX2dky9eUgzk8hu17cdvgSEykCc8A2 ina3U20js9Or4ERwdGQyIOUUpwOD1dsTr6t1pYQR2wFQf0f2SFwt1Iq3Zv2D5G2lkHsU YCdj3PxOonTsZbjSY/KNA8d61C5eaZWRaefZJx91qLW780qsRn7h4IXI/V6g4V4KORhG efAmAujmuM6n7SYn3eCgdGBiLSPXkHEXhg+o1sdQ3hSvcLMqxkDmkDp/w1ojBMxOIwFA dHwQ==
  • List-archive: <https://archive.midrange.com/web400/>
  • List-help: <mailto:web400-request@lists.midrange.com?subject=help>
  • List-id: "Web Enabling the IBM i \(AS/400 and iSeries\)" <web400.lists.midrange.com>
  • List-post: <mailto:web400@lists.midrange.com>
  • List-subscribe: <https://lists.midrange.com/mailman/listinfo/web400>, <mailto:web400-request@lists.midrange.com?subject=subscribe>
  • List-unsubscribe: <https://lists.midrange.com/mailman/options/web400>, <mailto:web400-request@lists.midrange.com?subject=unsubscribe>

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


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.