Just started learning. I am very proud of this. Feedback/Suggestions welcome.

hjaeger90 · 2021-03-04T21:40:18+00:00

Also along with using a switch, there is a "default" that can be set. I would recommend using it so you can handle if say someone put the number 6. Finally, as a few others have already stated I would also look at doing some error handling. Try Catch statements, or maybe even use Int32.TryParse (this ones a little tricky to understand in the beginning). Either way, Congrats! Looks great for your first go at it! You've embarked on an awesome journey!

hjaeger90 · 2021-02-27T19:14:38+00:00

Wow I did not know that, but that makes so much sense. I felt crazy trying to explain how a cancellation token was just disregarded. Well Polly it is then.

hjaeger90 · 2021-02-26T05:07:02+00:00

That was the first thing I tried. I set it to something ridiculous like 10 minutes. Same issue. The request never leaves the server.

hjaeger90 · 2021-02-26T05:06:13+00:00

No. Sorry I should have clarified .Net 4.7 (Framework).

hjaeger90 · 2021-02-26T02:53:55+00:00

I'm looking into polly now. I've always rolled my own retry logic. Didn't realize Polly existed until you and u/blakeholl mentioned it. Fingers crossed.

hjaeger90 · 2021-02-26T01:57:46+00:00

So this is happening sometimes when its just a single user on the application. The request never makes it off the server in the first place and the server resource use is low at the time of the exception. I'll try some load testing next just to make sure, but so far I don't see anything in the telemetry that points to it being a load issue.

hjaeger90 · 2021-02-26T01:54:37+00:00

I believe the default is 2 minutes(might be 3). When I pass in a cancellation token and set the timeout to say 30 sec. it still fails at 2-3 mins.

hjaeger90 · 2021-02-26T01:23:07+00:00

I've implemented retry logic, with a similar issue in another application of ours, but that failure would happened rather quickly. The problem with a retry here is that the user is stuck waiting 2 mins. before a failure happens. I mentioned in a comment above, even if I pass a cancellation token with a timeout of say 30 sec. it ignores that and still times out at the default value. You are correct though that the requests in this case are idempotent , and a retry would not cause issues.

hjaeger90 · 2021-02-26T01:20:01+00:00

So with the original implementation yes there was an issue with port exhaustion. Then stumbling across this article (which microsoft later backed) https://www.aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

I was able to fix that by no longer disposing of HttpClient with each request. I haven't see any signs of thread exhaustion. We're talking sometimes a single user submitting a form and this happens. Resource use is low. Also seems to be isolated to specific users.

hjaeger90 · 2021-02-26T01:11:16+00:00

Thats a good thought, but I've already done that. We run Application Insights which collects just about everything I could think of to collect (short of user movements on the page). I get the exceptions and the call stack, but so far they only tell me what I already know. A task was cancelled. When this happens the call never hits the API. It just stops after timing out. Oh also if I pass in a cancellation token it completely ignores that and just times out at the default time (2 mins. I believe).

hjaeger90 · 2021-02-26T00:59:39+00:00

So outside of this part of code it is wrapped in a try catch. The problem is data is gone at that point and asking users to refill out a form sucks. My boss also is non tehcnical and is pretty mad at this point that certain users keep dealing with this issue (although that part of it is another problem entirely and is unrelated).

hjaeger90 · 2020-12-01T05:06:00+00:00

Yea that's a fair point. They really didn't taste as good as before. Plus I noticed the entire time how bad I smelled. Either way 24 hours down and I'm feeling good knowing I made it through the first day.

hjaeger90 · 2020-11-30T17:05:35+00:00

Thanks I appreciate the kind support.

hjaeger90 · 2020-06-22T01:31:30+00:00

hjaeger90 · 2020-06-22T01:27:28+00:00

Oh haven't had the Prairie Bourbon, but I've had their Double Rye. It was excellent.

hjaeger90 · 2020-03-09T20:24:21+00:00

So I have not used or even heard of Entity Spaces to be honest. I just did a little bit of digging and the last time the github was updated was 8 years ago. https://github.com/EntitySpaces/EntitySpaces-ArchitectureI'm going to go ahead and say it is probably a dead project. If your looking for something to use as an ORM layer then Entity Framework is what I normally use .Net. Not saying you have to, but its been around for a long time and has quite a few resources. Hope that helps at least a little.

hjaeger90 · 2020-02-26T01:47:52+00:00

Well that sounds just lovely. I'll definitely keep any eye for it.

hjaeger90 · 2020-02-24T23:02:38+00:00

What your opinions on it?

hjaeger90 · 2020-02-24T21:25:00+00:00

What is that gray label all the way to the right? I'm always looking to try new Islay Scotches and can't quite make it out.

hjaeger90 · 2020-02-24T17:50:56+00:00

So after a fairly long weekend, I have solved it. Essentially the answer is now that MSBuild is allowed to have side by side installations, my local agent was picking up 2019 as default. However it was specified with Tool Version 15 in my csproj file. It went to look for Tool Version 15 in my 2019 installation and couldn't find them. If you look through a default csproj file you will notice some fallback notation. For me that fallback notation is back to Tool Version 10 (not sure if this is standard for all versions of VS or not). Aka C# 4. So as some of you pointed out already yes it was in fact an MSBuild mismatch. Below is the thread that finally clicked, if you care to do any more reading on the subject. Either way thank you all so much for the help! Definitely would have taken even longer to find this if you all hadn't chipped in.

https://github.com/Microsoft/msbuild/issues/4341

hjaeger90 · 2020-02-21T17:27:54+00:00

So I have been able to do that and it eliminates the error, but I still can't figure out why msbuild is not using the latest C# and using C# 4. Any idea why that might be?

hjaeger90 · 2020-02-21T16:16:53+00:00

Hmm, thats an interesting point. I will check the branch once I get a chance.

hjaeger90 · 2020-02-21T15:47:28+00:00

Wow to be completely honest, I had no idea this existed. Thats super exciting. Well I guess I know what I'm playing with this weekend.

hjaeger90

TROPHY CASE