Re: Web server connection mostly times out - except when I step though the API with debug.

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Hi Colin,

Yes, "/tmp/httpapi_debug.txt" is the default filename for the 
trace/debug file.

Am I understanding correctly that the part below (quoted) is the only 
part that occurs during the calls that time out?  I'm a little confused 
by the start of your message where it shows several lines with "(GSKit) 
Identifier value is not valid." followed by your e-mail signature.   Am 
I correct in assuming that the e-mail signature was somehow placed in 
the middle of the successful trace file by mistake, and that the part 
below is the only part you see when you get the failures?     (I will 
say more beneath the quoted text that follows):

On 4/22/2015 7:37 PM, Colin Grierson wrote:
> HTTPAPI Ver 1.29 released 2015-02-23
> NTLM Ver 1.4.0 released 2014-12-22
> OS/400 Ver V6R1M0
>
> http_persist_open(): entered
> http_long_ParseURL(): entered
> DNS resolver retrans: 2
> DNS resolver retry  : 2
> DNS resolver options: x'00000136'
> DNS default domain: SKYTV.CO.NZ
> DNS server found: 192.168.196.46
> Nagle's algorithm (TCP_NODELAY) disabled.
> SetError() #7: Timeout occurred while trying to connect to server!


This error (#7: Timeout occurred while trying to connect to server) 
means that HTTPAPI sent a request to connect, but got no response back 
from the server in the specified amount of time (by default, timeout is 
60 seconds.)

Here are some possible reasons that could happen:

1) The server may be very busy, and unable to keep up with all of the 
connection requests it's trying to handle.  In this case, I would 
suggest maybe lowering the timeout value to 20 or 30 seconds, and 
re-trying the call maybe 5 times, hoping one of them would get 
through.   The timeout is adjusted by changing the 6th parameter to 
http_url_post_xml() to the number of seconds you need.  (In your code, 
you are using the constant HTTP_TIMEOUT, which is just the number 60.  
Pass the number 20 or 30 instead.)    Then to re-try, just write a 
little for/next loop, and leave the loop if you get a successful 
connection...


2) Another reason for a timeout would be that something in your network 
(Network card, cable, router, switch, etc) is flaky and dropping 
packets.  This would be a hardware error, and would show up in other 
applications besides HTTPAPI as well...  for most packets, they are 
automatically resent if the packet is dropped, but the connection 
request packet is an exception to that rule... so if you are often 
seeing lags in network performance (connections seem to "freeze" for a 
second or two then resume) in other network applications, then this 
might be the issue.


3) A firewall may be blocking the connection request.   This seems 
unlikely, though, as I'd expect it to happen consistently in that 
case.   Unless, of course, salesforce is giving you different URLs at 
different times and the firewall is only blocking some of them -- in 
that case, it would make perfect sense, and the solution would be to 
open up the other URLs.  The way you'd notice this problem is to notice 
that it "always" fails to "cs14.salesforce.com" but succeeds to 
something else like "cs1.salesforce.com" or other host names that aren't 
the same as the failing ones.  I don't know much about salesforce, so I 
don't know how likely/unlikely this might be.

There are probably other possibilities, but these are the ones that 
occur to me off the top of my head.  My first guess would be #1.

I don't understand why running it in debug would help, though. Possibly 
simply because it slows the process down a little bit allowing the 
salesforce server to catch up?  That seems weird, and isn't something 
I've seen before -- but if that's the case, you could always try 
inserting a delay into your program to see if that helps...  But, 
without seeing it personally, I'm inclined to believe that the "debug" 
thing is more likely just coincidence.   Only you'd be able to tell for 
sure...

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