[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Intermittent string-length error in COMM
The error only occurs in CGI Web server jobs. I assume that since it's a threaded, socket-heavy environment there might be legitimate reasons for it to be larger than normal. Our Web server uses IFS files, JDBC connections, sends notification email, etc. and I don't doubt that there is a descriptor leak somewhere in the thousand or so CGI programs we support. I had to make this same kind of change to the SMTP client a few years ago.
In an interactive job I was unable to open 200 files at a time (I was trying to replicate the issue), so for normal use case it's not a problem. I'm not expecting that this is a good idea for a general release, so don't make changes on my account.
I've made this code change already in our copy of the library. (Politics & high-visibility projects and all.) Totally agree it's not the "right" thing to do. I was asking if there was anything I had to do besides changing the size of that mask field, but it looks like that was all.
Thanks for providing such a useful piece of software.
--
John Maassel
Lead Programmer / Analyst
Bob Evans Farms, Inc
614-492-7413
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, April 28, 2015 2:50 AM
To: HTTPAPI and FTPAPI Projects
Subject: Re: Intermittent string-length error in COMM
Hello John,
This means that you have more than 224 descriptors open at one time.
Can you explain WHY you need to have so many open at once? If this is
truly intentional and desired to have so many open at once, then sure, I
can see updating HTTPAPI to handle this high capacity.
But, in my experience, people almost never need more than 10 open at a
time. So the fact that you say you need more than 224 makes me skeptical.
I'm thinking it's more likely to be a bug in one of your programs that
it isn't closing the descriptors when it should be, and is leaving them
open indefinitely -- eventually causing you to run out. And if that's
true and I increase the capacity in HTTPAPI to (for example) 1000, the
problem won't really be solved, it'll just take longer to run out, but
you'll still run out eventually.
So can you explain what's going on here? Do you truly, intentionally,
need more than 224 descriptors open simultaneously? Or is this a bug
somewhere?
-SK
On 4/27/2015 7:11 AM, Maassel, John R. wrote:
> One other question.
>
>
> If I change `fdset' in PRIVATE_H from 28a to 64a, will that have any
> side effects elsewhere? I think that's probably the easiest way to fix
> this. Do I have to make other changes too?
>
>
> --
>
> John Maassel
>
> Lead Programmer / Analyst
>
> Bob Evans Farms, Inc
>
> 614-492-7413
>
>
> From: Maassel, John R.
> Sent: Monday, April 27, 2015 9:58 AM
> To: 'ftpapi@xxxxxxxxxxxxxxxxxxxxxx'
> Subject: Intermittent string-length error in COMM
>
>
> We're having an intermittent issue with HTTPAPI running in our CGI
> environment.
>
>
> My theory is there's a resource leak in some other jobs in our system
> and we keep getting a high number for socket descriptor, and it's much
> bigger than expected by this library. Am I on the right track?
>
>
> Is there a patch already available for this? If not, are there any
> gotchas I have to be aware of while I'm trying to fix this?
>
>
>
> RNX0100 Escape 50 04/27/15 08:52:25.259954
> QRNXIE QSYS *STMT HTTPAPIR4 LIBHTTP *STMT
>
> From module . . . . . . . . : QRNXMSG
>
> From procedure . . . . . . : SignalException
>
> Statement . . . . . . . . . : 25
>
> To module . . . . . . . . . : COMMTCPR4
>
> To procedure . . . . . . . : COMMTCP_FD_SET
>
> Statement . . . . . . . . . : 4851
>
> Thread . . . . : 0000026A
>
> Message . . . . : Length or start position is out of range for the
> string
>
> operation.
>
> Cause . . . . . : 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. - The
>
> search-argument parameter of the %SCAN built-in function has zero
> length or
>
> is longer than the source-string parameter. - The maximum-length
> parameter
>
> of the %STR built-in function is not a value between 1 and the
> maximum size
>
> of a character field. Recovery . . . : Contact the person
> responsible for
>
> program maintenance to determine the cause of the problem.
>
>
>
> I traced the failure to this block of code:
>
>
> Module :LIBHTTP/COMMTCPR4, procedure COMMTCP_FD_SET:
>
>
> 4850 C callp
> CalcBitPos(peFD:wkByteNo:wkMask)
> 061002 090000
>
> 4851 c eval wkByte =
> %subst(peFDSet:wkByteNo:1)
> 061002 090100
>
> 4852 c biton wkMask
> wkByte
> 061002 090200
>
> 4853 c eval %subst(peFDSet:wkByteNo:1) =
> wkByte 061002 090300
>
>
> Any advise or assistance would be appreciated.
>
> Thanks,
>
> --
>
> John Maassel
>
> Lead Programmer / Analyst
>
> Bob Evans Farms, Inc
>
> __________________________________________________________________
>
> Notice from Bob Evans Farms: This e-mail message, including any
> attachments, may contain confidential information that is intended only
> for the person or entity to which it is addressed. Any unauthorized
> review, use, disclosure or distribution is strictly prohibited. If you
> are not the intended recipient, please contact the sender by reply
> e-mail and destroy all copies of the original message and any
> attachments.
>
>
>
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
________________________________
Notice from Bob Evans Farms: This e-mail message, including any attachments, may contain confidential information that is intended only for the person or entity to which it is addressed. Any unauthorized review, use, disclosure or distribution is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments.
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------