|
So we've built a system that uses Azure, it's a function that validates a payload and pushes it onto a queue, and then another function pulls it off to process it. It's integration, keeping two systems in sync
Worked fine until the client decided to push in 2000 records at once. We find that HTTP functions blow up if they get too many calls. At one point they were sending 20, waiting 30 seconds, sending more and that still blew up.
We've been chasing this for over a month. There's Azure doco on this being limiting code that you can turn off. You cannot. The doco is all over the place. We found it doesn't happen to C# script BUT C# script won't work with queues with sessions.
Today we get one of my co workers to code review it all. He says it all looks good then, off the cuff, says, why does your DI code use injecttransient. Because we're injecting a few lightweight classes and I didn't trust the idea of a singleton across Azure servers being better.
So I make them all singletons, and now the code works. No documentation anywhere that I can find on why that would be.
|
|
|
|
|
yikes - that's a nasty trap - kudos to co-worker btw for asking the question
|
|
|
|
|
Yeah, I found no doco so his suggestion was awesome. I did find other limits that I could turn off, so I assume all of those changes also worked in their own way
|
|
|
|
|
There are tons of undocumented behaviors in Azure - it is an environment developed in production...
For instance (from my personal experience) a Linux based app service is actually sits behind an IIS wrapper, where that wrapper always 'talks' to the Linux instance in HTTP, which actually makes it unusable for like 90% of the scenarios in today world, where HTTPS is a minimum requirement and checked by most...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
*sigh* there's a lot of defunct doco still live as well. The source of truth is what your function does in real life
|
|
|
|
|
Feel free to ignore this because it's just a wild stab in the dark (and it's obvious once one knows), but are you somehow injecting an HttpClient using transient ?... because HttpClient is (as I know due to (cough) experience) "once per app" and exhibits interesting behaviour if it's continually 'new'd ... see first comment line in the c# example (link below) and text in the in the Remarks section...
HttpClient Class (System.Net.Http) | Microsoft Docs[^]
HTH
|
|
|
|
|
No, in .NET Core there's a HTTP Context factory. I inject that to get a HttpClient
|
|
|
|
|
Christian Graus wrote: No documentation anywhere that I can find
... because people who live in glass houses don't throw stones.
Really? Honestly there's gotta be sample/example use somewhere. If there's no sample there's no way anyone's gonna use it. Anyone who is anybody.
Now, as for Bob ...
|
|
|
|
|
There's tons of .NET Core and Azure functions samples. Nothing on the issue I had that I found while searching
|
|
|
|
|
This thought has nothing to do with the thought of the day line of thoughts. It was brought about by a conversation I had with the Mrs., by OG's thank you post this morning, and by a question last week where the OP really needed to just debug.
The conversations was about books and how she likes to have the physical book. I feel the same way and it took me a long time to get used to PDF 'books'. But I got to thinking about how I learned to program all those years ago, it was basic of course, the C=64 version. All I could do was RTFM. That was all that was available for Basic and Assembly at the time. Within a few years I was able to move to a Pc and start learning C. I had a copy of Microsoft C and again only the manual. But I learned, bought other books as I could, and learned some more.
In all of that I had to fix my own problems and typo's, lots of typo's  . No one else could help. I find that I still use those methods to solve my current problems. Last step is to search online, and maybe ask some colleagues for a new set of eyes on the code.
Makes me wonder if colleges who teach programming classes, teach debugging? Or should it be a course all by it's lonesome?
Anyways, just a thought I had. What are yours?
Jack of all trades, master of none, though often times better than master of one.
|
|
|
|
|
I don't know if any college class teaches debugging, per se. At best, they can introduce debugging tools, and show their capabilities. Depending on your profession, learning how to {debug, troubleshoot, diagnose} is a dark art, and all that can be given are general rules of thumb. It mostly boils down to experience.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I'd disagree to an extent.
Debugging is a state of mind; a way of thinking about the world. It's the process of looking at an event and working out what happened, how you got from "there" to "here" and what you saw happening en route - looking at the symptoms of a problem and deducing what had to happen to cause them; what that means about the underlying process; what actually happened.
I can say with some confidence that I learned a lot more about debugging by buying an unreliable motorcycle that I did on any university course!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I agree. See Operational Research.
Also
I learned much more from my failures than my successes.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
Problem solving.
Programming is like any other challenge in life, you have to learn to use the tools youn can find and reduce the problem to a level where you can solve.
|
|
|
|
|
OriginalGriff wrote: buying an unreliable motorcycle
My Dad obviously agreed with this philosophy. I watched him rebuild multiple cars and helped whenever I could, even if it was just holding the light. When my brothers and I were old enough, we all got dirtbikes...all the very same kind...late 70s Yamaha CT 175s. None worked when we got them, but we quickly learned how the 2 stroke/magneto powered things worked. I used to think he was cheap, but later in life recognized it as wisdom. 
Solving complex problems doesn't come naturally but from experience. Solving complex problems of any kind will improve your ability to solve complex problems of all kinds. High school math should begin this process, but it doesn't always translate well to the real world.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
kmoorevs wrote: we all got dirtbikes...all the very same kind...late 70s Yamaha CT 175s. None worked when we got them
[...]
I used to think he was cheap, but later in life recognized it as wisdom
That's actually pretty cool. He knew exactly what he was doing, didn't he?
I hope he knows you later understood why he bought them in a non-working state.
|
|
|
|
|
OriginalGriff wrote: Debugging is a state of mind
As is the whole of the software development lifecycle. And it was pretty obvious to me, even during my first exposure to coding, (on a TOPS programming course), that some people got it and others never would. I've always believed that it's a 'knack', that some people have and some don't.
OriginalGriff wrote: I can say with some confidence that I learned a lot more about debugging by buying an unreliable motorcycle that I did on any university course!
I think you've nailed it! As farmer's lads, my brother and I spent many hours fixing up all sorts of unreliable stuff - including a BSA Bantam 125; a Triumph Tiger Cub, a Lambretta 150; and a Triumph Tiger 350 - which was way too heavy, (and fast), for us. And, occasionally, (when they were working), actually riding them around the fields.
Any programming aptitude test should require applicants to figure out that a carburetor jet has muck in it - and be able to fix it! 
|
|
|
|
|
I can see your viewpoint.
On the other hand, I can't do anything with my hands in terms of mechanical things, construction, fixing the plumbing, etc. However, I used to be able to earn programming languages on my own (never took a course on a single one of them), write programs real fast, make few mistakes in writing them, debug my programs and systems written by others from core dumps (what the heck are they?), have an intuitive grasp of logic, understanding of systems at a high level, etc. That came in handy as a consultant too.
I think an analytical mind is sufficient to work in programming. In fixing tractors, motorcycles, automobiles, etc., you develop logical thinking because for all those things to work, you needed to gain an understanding of how those IC engines worked, how you had to time the spark for the engine to fire, etc.
If you were into construction, I can see how working with the HVAC (heating, ventilating and air conditioning) systems or the water heating system would help develop your thinking and troubleshooting ability.
However, if you only pounded nails day in and day out to frame the building or to nail the Sheetrock to the walls or just painted buildings for months on end, I don't see much benefit from those activities.
|
|
|
|
|
Zen and the Art of Motorcycle Maintenance.
|
|
|
|
|
Like you, I grew up with the manual and a compiler: we didn't have access to debuggers in those days, so we had to insert out own logging statements to try and narrow down where a bug might be. When I moved to embedded assembler, it got even worse - so I wrote my own "debugger" which showed registers and could show memory content. You still had to add code to enable it though!
I think what is the worst, is that never mind debugging, some of the next generation can't even read an error message and start fixing their own syntax errors.
That's fundamental: if it doesn't compile (or interpret) no debugger on the planet can help you!
But I agree - debugging is important and should be taught. But I suspect that those who teach this stuff don't know how to debug code (or even write it in many cases) and aren't even aware that a debugger exists, much less how useful it can be!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
The very first "larger" (i.e. 4000 instructions) program I wrote was a TRAC interpreter on the PDP-9 in assembler language (I had some experience with writing assembler programs on the PDP-8). (TRAC, Text Reckoning and Compiling was an interpreted language, essentially a big macro expander, it was popular in the late 60-ies and earliy 70-ties, search for Calvin Moors for details).
As it happened, the PDP-9 had an excellent debugger -named SCALP - and since the program contained
lots of pointers I really needed this debugger from time to time (the PDP-9 had just one accumulator, no further registers).
Ever since that time I told students - I kept working in academia - to pay attention to debugging and I gave some demonstrations. But giving a "course" in debugging, no. It is too dependent on the project being debugged, so the basics are that you can interrupt the processing (breakpoints), inspect registers and execute step by step.
Of course on the PDP-9 step by step means executing single instruction, while with e.g.
the current gnu debugger (I must admit, I develop under Linux) provides lots more possibilities.
As a side note: one of the nice "features" of the PDP-9 was that you could reduce the clock speed, and - when you were experiences - could follow the execution of the program on the lights on the control panel. Came in handy when your program was looping.
Conclusion:
yes, debugging should be taught, but preferably not in a class room someone explaining all the debugger commands on a blackboard. Guided experience is needed here.
|
|
|
|
|
Member 12982558 wrote: yes, debugging should be taught, but preferably not in a class room someone explaining all the debugger commands on a blackboard. Guided experience is needed here.
Totally agree. But even a blackboard lesson would be better than no lesson.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Member 12982558 wrote: Guided experience is needed here.
Absolutely true - but there's one precursor ingredient to debugging by whatever means: motivation.
Motivation goes beyond the coding - you need to want to do things and make them work. Solving the bugs could (should?) be as satisfying as finally getting it all working. I take my cue (or more, found a kindred spirit) in this quote often attributed to Hannibal:
"If I cannot find a way I'll make way!"
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I teach an Intro to SQL class (okay, I gave the class ONCE...then I changed jobs and after I settle down the new boss wants me to offer the class again). After class, the one thing I learned as an instructor, was that I need a How to Troubleshoot SQL section. Common errors in code and what the message means. I learned this because my student keeps sending me his code (I also now serve as his mentor) to help him debug. My fault...I didn't introduce him to what those red squiggly lines mean and how to understand the text that appears when you hover over the line.
Simple things like leaving the comma when removing/commenting out the last line in a select statement (and the reason why I suggest the comma goes at the BEGINNING of a line and not at the end!). As this is an introduction class, I don't want to get too deep into all the things that can go wrong with coding, just the things that happen to most coders (that means the beginners and the experienced SQL writers, too). Just to have a basis of what do you do. FIRST...Read the error! Either the pop-up when you go to run it, or what you see with the red line. Then, decide what to do about the message. Simple, right?
|
|
|
|
|
It's amazing how much the programming and debugging mind set applies to other aspects of our lives.
I'd hazard a guess at almost anything man made.
Jack of all trades, master of none, though often times better than master of one.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
