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

Re: Call to HTTP_URL_P ended in error

   Troy,
   So you have 1400 network connections open at once in your
   application?   and you don't think this is a problem, instead you want
   me to change FTPAPI, I guess?
   Can you confirm that, by design, you have that many simultaneous
   network connections open, and you want them all to remain open?
   Your proposed fix doesn't make any sense.  Setting the bit pos to 28
   will tell it to check the completely wrong descriptor, so instead of
   checking to see if there's data on FTPAPI's network connection, it'll
   be checking for data on some other, unrelated network connection.
   This seems like a recipe for disaster to me.
   -SK

   On 5/20/2014 11:34 AM, Troy Paulson wrote:

   Boaz/Scott,

   I have this same issue that Boaz uncovered.  We have a very large
   number of server connections and all web services come in to one of our
   2 AS/400's.  Every time I debug the process to use FTPAPI to ftp a file
   from a CGI DEV2 webpage, the socket # comes back well above 224.  Today
   I get numbers above 1400, so of coarse the CalcBitPos will calculate
   173, which in turn would error in the FD_Set procedure when doing the
   %Subst of a 28 character field.   Have either of you found a solution
   to this problem?  I thinking the only way to fix this, is to check if
   the Bit Pos is greater than 28, then set it to 28.  But I'm sure this
   could have issues.

   I am currently using FTPAPI 2.3 on OS/400 version v4r4m0.

   Troy Paulson


     * From: Scott Klement <[1]sk@xxxxxxxxxxxxxxxx>
     * To: [2]ftpapi@xxxxxxxxxxxxxxxxxxxxxx
     * Subject: Re: Call to HTTP_URL_P ended in error
     * Date: Sat, 12 May 2012 01:03:20 -0500
   _______________________________________________________________________

Hello Boaz,

If that is indeed the problem, I'd expect it to occur in FD_SET shortly
after a new socket is created.

But, in Naresh's case, it's occurring near the end of the communications
session, after the socket had already been used with FD_SET many times.
  So, it doesn't seem to fit the description.

So, please let me know if you're truly working with Naresh and debugging
his program... because, if that's the case, there's something very weird
and crazy going on here, and there's a lot more going on than meets the
eye!!


On 5/12/2012 12:38 AM, Boaz mermelstein wrote:

    Hi Scott

    The problem is not in the application functionality but in the TCP low
    level algorithm.

    I have this problem in my application for a long time.

    But before address it, I'll describe the application  in order to give
    you the background of what cause it.


    Application is a Web service server program, running under Apache as a
    CGI program.

    An external source send a web service request to open a lead or
    incident in our internal CRM software.

    Our AS/400 is the front end to all external web service requests.

    Thus CGI Parses the request, build a new web service request and send
    it to internal CRM.

    May be other old programs working under same job, doing some TCP
    connections to other places.


    When the problem raised, I debugged the Apache job (STRSRVJOB) and
    found the following:

    When the job runs for a long time, many programs communicate with TCP
    in the wrong way (sockets are not closed, or not reused), then socket
    number ( file descriptor ) can very easily reach the numbers of 224.

    Since FDSET structure is only 28 bytes, when CalcBitPos returns value
    greater then 28, then HTTP_URL_P.... ends with error.


-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
[3][1]http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------


   Troy Paulson

   Applications Developer

   [[2]4]tpaulson@xxxxxxxxxx

   920-756-4739 Direct

References

   1. [3]mailto:sk@DOMAIN.HIDDEN
   2. [4]mailto:ftpapi@DOMAIN.HIDDEN
   3. [5]http://www.scottklement.com/mailman/listinfo/ftpapi
   4. [6]mailto:tpaulson@xxxxxxxxxx


-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
[7]http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------

References

   1. http://www.scottklement.com/mailman/listinfo/ftpapi
   2. mailto:4]tpaulson@xxxxxxxxxx
   3. mailto:sk@DOMAIN.HIDDEN
   4. mailto:ftpapi@DOMAIN.HIDDEN
   5. http://www.scottklement.com/mailman/listinfo/ftpapi
   6. mailto:tpaulson@xxxxxxxxxx
   7. 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
-----------------------------------------------------------------------