[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Web server connection mostly times out - except when I step though the API with debug.
Scott
Many thanks for your help.
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?
The log has details of both calls I make. Yes, the failing call relates
to the section you identified.
I looked up "(GSKit) Identifier value is not valid." and found
references on your site that it can be ignored. Is this correct?
- see http://www.scottklement.com/archives/ftpapi/201501/msg00094.html
Yesterday I was pretty sure debug was making a difference today it did
not seem to. I'd be much happier if it's not.
I'll try your first suggestion and see how we go.
Thanks again
Colin
[cid:image93a3bd.JPG@a0942833.4280b5c8]
Colin Grierson | Development Consultant
[1]Systems Advisory Services Ltd
520 Great South Road, Greenlane, Auckland, New Zealand | PO Box 17-268
Greenlane
Phone +64 9 525 7353 | DDI +64 9 580 8745 | Email
[2]Colin.Grierson@xxxxxxxxxxx
We develop, integrate and manage mission critical systems
________________________________________
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] on behalf of Scott Klement
[sk@xxxxxxxxxxxxxxxx]
Sent: Thursday, 23 April 2015 3:07 p.m.
To: HTTPAPI and FTPAPI Projects
Subject: Re: Web server connection mostly times out - except when I
step though the API with debug.
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
-----------------------------------------------------------------------
__________________________________________________________________
Scanned by MailMarshal - Marshal8e6's comprehensive email content
security solution.
__________________________________________________________________
References
1. file://localhost/tmp/www.sasit.co.nz
2. mailto:Colin.Grierson@xxxxxxxxxxx
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------