The attached test case causes a failure
when used on a redirect (30x) url.
If the header "Connection: close" is removed
it still fails occasionally (I'm obviously
interested in the occasional failure although
I suspect they have the same root cause).
C file test case
Logged In: YES
user_id=972763
How about this:
--- lib/url.c Tue Feb 10 15:45:23 2004
+++ lib/url.c~ Sun Jan 11 17:56:37 2004
@@ -1375,11 +1375,11 @@
to.tv_sec = 0;
to.tv_usec = 0;
sval = select(sock + 1, &check_set, 0, 0, &to);
- if(sval == 1)
+ if(sval == 0)
/* timeout */
ret_val = FALSE;
return ret_val;
}
Logged In: YES
user_id=972763
Please ignore the last comment (I thought checking
the write-ready number would be sufficient but it's not).
What I think happens is that between the time
the is socket tested and the time it is used it's
being closed. But I guess there's no telling at that point.
Logged In: YES
user_id=972763
Actually if you test the read-ready with "to.tv_usec = 1"
it works since it gets the "EOF", but this adds overhead :-(
Logged In: NO
Anyways, I think that a failure generated by a reused connection
should be handled internally or at least return a unique
error code
to indicate the user should try again since it may not be a
"real"
issue with the server.
Also, as I understand it, connections are only being reused
within
the same easy handle, is it possible to add it to the share
interface
so it could be used across handles?
Logged In: YES
user_id=1110
I don't think this is a 100% fix anyway, and it adds lots of
overhead for some platforms. The code actually used to be
something like that in the past.
Can you try a recent daily snapshot to see if this works any
better for you? We've done some changes I think will improve
how libcurl deals with these situations.
Logged In: YES
user_id=972763
I tried a daily snapshot (curl-7.11.1-20040212.tar.bz2).
It was better but still had failures.
How about my other questions, is it possible to report
this as a separate error code? Can connections
be shared between different handles?
Logged In: YES
user_id=1110
What failures did it still show, and can you see why?
Why would this be a separate error code? For what?
Connections cannot be shared between handles until we have
the share interface supporting it.
Perhaps it would be easier if we took this thread to the
curl-library mailing list instead. It would get more people
involved and able to help out.
Logged In: NO
Still getting 52 and as I mentioned below I think it should be
a different code since the problem is not that the server didn't
respond (which might be a "real" problem) but that the reused
connection was closed which in turn is because its "IsDead"
test failed to return the correct result.
The reason why I think these kind of failures should have
a different code is because the user might want to reissue the
request. Anyways from what you wrote and from looking at the
code I realized that I was only using this "connection caching"
in redirect requests (since I'm not reusing easy handles)
so I just disabled this with the "fresh connect" option
and it works fine now. I still think this may be an issue
under load for people who are reusing easy handles.
Logged In: YES
user_id=1110
I'm moving this to get discussed on the mailing list instead.