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

Re: Call to HTTP_URL_P ended in error



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:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------