Re: SetError() #2: Host name look up failed.

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Hi Spencer,

Please try the current BETA version of HTTPAPI, and see if you have the 
same problem.  I have fixed a number of problems with debug files (which 
could very well be causing you to run out of descriptors -- and that, in 
turn, would prevent either gethostbyname() or any other networking to work.)

http://www.scottklement.com/httpapi/beta/

If you have the same problems with the beta, then post again, and tell 
me how to reproduce the error.  (ONLY if you have the problems with the 
beta)

Thanks


On 1/21/2011 2:59 PM, SWofford@xxxxxxxxxx wrote:
>
>
> I'm using the HTTPAPI to access a webservice
>
> This is actually a followup to a prior post but I have spent some more time
> researching it now and have more information to share.
>
> We are consuming a webservice where a specific job may be accessing the
> same service doing multiple queries(possibly more than 100 per user job
> over a period of hours.  I have been able to log job specific attempts and
> their success/failure at contacting the service.
>
> What I have found is a job has many successful attempts at making a
> connection and then after a certain amount of time and/or iterations the
> log shows the "host name lookup failed" error message, then from that point
> on that specific job cannot successfully make a connection(until the user
> signs off the session and restarts)
>
> I have isolated that the error comes from Module COMMTCPPR4 and procedure
> commTcp_resolve().  We are specifying a the link as
> https://qhos.qualcommapps.com/qhoswsna/driver.asmx, so the procedure is
> utilizing the C-function of gethostbyname() to retrieve the ip address.
> Shortly after this procedure execution the specific error we are getting is
> is sent to the debug log.  no communication is actually attempted because
> of this failure.(I have verified this will a communication trace)
>
> This almost appears to be a resource/memory leak problem the way it behaves
> and I was thinking there could be some deallocation of memory requirement
> for the c-function(s) used but I don't know enough about C to make that
> determination.
>
> It seems to be isolated to a specific job for a user, they may have another
> session signed on that is working just fine at the same time, but that one
> job fails consistently after the error first appears.
>
> One side note:  the debug log file can't actually be generated by the
> service program because of the same issues once the error starts occurring,
> I actually had to add my own code to the service program in the
> debug_write() procedure to log the information to a database file so that I
> was able to even see that this error was being generated.  This again
> points me to a resource issue. When it tries to create an ifs file it gives
> some kind of error indicating no handles are available(i don't remember the
> specific error)
>
>
> Spencer Wofford
> Sr. Programmer/Analyst
>
>
>
>
> Please consider the environment before printing this email ...
>
> *****************************************************
> This e-mail and any files transmitted with it are confidential and solely for the use of the individual or entity to which they are addressed and intended.  If you have received this e-mail in error, please notify the sender by return e-mail.  If you are not the intended recipient, you may not read, copy, retain, print, disclose, or distribute this message or its contents to any other individual, for such actions may be unlawful.
> WARNING: We take certain precautions to prevent viruses, but we are not responsible for loss or damage arising from the use of this e-mail or 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
-----------------------------------------------------------------------