This repo contains the .NET Core runtime, called CoreCLR. It is an execution engine for .NET apps, performing functions such as IL byte code loading, compilation to machine code and garbage collection. The repo contains the complete up-to-date CoreCLR codebase.
To just go back to talking about memories, I would see it as a terrible thing if I felt that it was more important for me to convince people that I was right than for me to understand the best version of their point of view and to look for the idea that's the most helpful for both of us. That having-to-be-right stuff is not one bit enjoyable in the long run for me. Frustration on one hand, hollow victories on the other hand. Both broadcasting how much more important I think I am compared to whoever I was just talking to.
So yeah, for me anyway, life has much more satisfying things in it than winning.
I think that desires can change, that our desires often originate in things outside our control or awareness, and that our understanding of our own motivations is probably inherently confabulatory.
but the ref source shows no such method
Anyway GetResponseAsync is throwing a WebException that's a timeout - does the async call timeout if it hasn't completed within the timeout window? is that what goes on?
each class has Timeout property they are distinct, the derived class does not touch the base class's Timeout
Changing Timeout on a HttpWebRequest instance has no impact on problem, operation still times out
Therefore this was needed and it worked:
((WebRequest)(request)).Timeout = 1000000;
VS though says the cast is redundant but I dont see that.
One thing I ran into that led to timeouts was that WebClient defaults to keep-alive
WebClient sends headers that you didn't specify, HttpClient doesn't
System.Net.Http is a framework assembly yet System.Net.Http.Json is not it seems.
I can't believe the jumping around I have to do just to submit a simple async HTTP put FFS
private static HttpWebRequest CreateRequest(string Method, string Url, IDictionary Args)
{
string json = JsonSerializer.Serialize(Args);
var request = (HttpWebRequest)WebRequest.Create(Url);
request.Timeout = 10000;
//((WebRequest)(request)).Timeout = 1000000;
request.Method = Method;
request.ContentType = "application/json";
var bytes = Encoding.ASCII.GetBytes(json);
request.ContentLength = bytes.Length;
using (var stream = request.GetRequestStream())
{
stream.Write(bytes, 0, bytes.Length);
}
return request;
}
Whatever happened to the concept we we're all lectured about for years, you know that concept?
"reuse".
This isn't reuse, this is rewrite, that's another OO promise that's been abandoned.
Its abstract, that actual class is HttpWebRequest but it does not override the async methods, so these are all in the base class
setting HttpWebRequest.Timeout seems to have no effect (hence its commented out in that code fragment above)
that code returns an HttpWebRequest, that'll change so all callers must change etc etc.
but then if the api is too limited for use cases whatever then the only thing you can do is rewrite sometimes
In addition, since I have no real idea why the timeout occurs, it might not be in the HttpWebRequest area at all, until I rewrite the code and retest I won't know. If the timeout has some other cause (like for example ServicePoint details). If I rewrite yet continue to see the problem, all of the time spent studying HttpClient and rewriting the code is a total waste of resources.
All too often we hear "Well just use XXX" as if this were a five minute tweak, it often isn't and the costs, time, impact is huge - this is especially true of fixed deadline projects (which I hasten to add, "agile" is utterly useless for).
Sorry to gripe, but this is what development has become.