[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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