by eterm on 5/8/25, 12:11 PM with 186 comments
by eterm on 5/8/25, 12:11 PM
Screaming into the void of the blogosphere is catharsis for getting my SO question closed.
And because I know you're all nosy, the SO question is here: https://stackoverflow.com/questions/79605462/high-cpu-usage-... . Please feel free to point out more ways in which I screwed up asking my SO question.
by hakunin on 5/8/25, 5:52 PM
I posted a question[1]. Got some answers, but not quite complete. Then someone came along and provided a good detailed answer. A couple of upvotes later, that answer got deleted by Community Bot. I voted to undelete it, but it still needs another vote to undelete. So I ended up copying it into my own notes blog[2].
I'm not sure why the best answer was deleted. It would've been a loss if it wasn't preserved somewhere I think.
[1]: https://stackoverflow.com/q/73954228/155351
[2]: https://notes.max.engineer/creating-common-interfaces-in-gol...
by bytefish on 5/9/25, 3:22 AM
The CoreWCF folks would be delighted to have a reproducible example, and they are best suited for answering the question. They have written CoreWCF after all! And if you don’t feel comfortable with raising issues? There’s also a Discussion feature on GitHub, where you can ask more free form questions.
And once you fixed or analyzed the issue with the CoreWCF team, you could write a blog post about it and share it with anyone having a similar issue.
That’s how I do these things.
by darrylb42 on 5/9/25, 4:55 PM
"Bindings MAY provide for streaming when processing messages. That is, SOAP nodes MAY begin processing a received SOAP message as soon as the necessary information is available. SOAP processing is specified in terms of SOAP message infosets (see 5. SOAP Message Construct). Although streaming SOAP receivers will acquire such XML infosets incrementally, SOAP processing MUST yield results identical to those that would have been achieved if the entire SOAP envelope were available prior to the start of processing. For example, as provided in 2.6 Processing SOAP Messages, identification of targeted SOAP header blocks, and checking of all mustUnderstand attributes is to be done before successful processing can proceed. Depending on the representation used for the XML infoset, and the order in which it is transmitted, this rule might limit the degree to which streaming can be achieved."
https://www.w3.org/TR/soap12-part1/
The critical note is the output for streamed, or buffered must the the same so it does not look like infinite streams can be supported.
I also played with your sample application to see if there was any indication of the connection dropping.
I had an interesting result switching to the NetTcp binding. On the client it is unable to exit until the max size of the incoming message is hit. The server continues running as there are no sent message quotas.
by palata on 5/8/25, 12:42 PM
After a while, I stopped having to post questions about "common frameworks", either because I could do with the official docs of because there was already a StackOverflow answer for my question.
What was becoming more common was that I would have a question similar to an existing unanswered one. Or that my question would never receive an answer (presumably because my questions were becoming more tricky/niche). So what I started doing was answering my own question (or answering those existing unanswered ones) after solving it on my own. Still, it was fine and I was contributing.
And for some reason, a few years ago my questions started being closed for no apparent reason other than "those who reviewed it have no clue and think that it is invalid". Many times they closed even though I had posted both the question and the answer at the same time (as a way to help others)! The first few times, I fought to get my question reopened and guess what? They all got a few tens of votes in the following year. Not so useless, eh?
Still, that toxic moderation hasn't changed. If anything, it has gotten worse. So I stopped contributing to StackOverflow entirely. If I find information there, that's great, if not, I won't go and add it once I find a solution for myself. I am usually better off opening an issue or discussion directly with the upstream project, bypassing StackOverflow's moderation.
I heard people mentioning that LLMs were hurting StackOverflow badly. I'm here to say that what pushed me away was the toxic moderation, not LLMs.
by phkahler on 5/8/25, 1:05 PM
Another old problem was notable users. There was a guy famous for his presence and answering tons of question (I forgot his name). He was actually pretty good but... he was not an expert in all the areas he'd participate in, but his answers would sometimes win because he was articulate, not because it was the best.
by yakz on 5/8/25, 12:59 PM
https://learn.microsoft.com/en-us/dotnet/api/system.servicem...
https://learn.microsoft.com/en-us/dotnet/api/system.servicem...
Could you use these to cancel the stream?
by cadamsdotcom on 5/8/25, 12:42 PM
Is there some kind of `IClosableStream` you can implement? That’d give you a `Closed` method, which you can then use to let either your server or stream know that it’s time to stop reading (or the stream reached EOF) - even if it’s done with a flag that’s set when the client disconnects.
Maybe there’s already an optional `Close` method you’re not overriding?
by eYrKEC2 on 5/8/25, 10:39 PM
Ask a question.
Ignore the trolls.
Get a question answered that would have taken you another day to solve.
Make money.
by jgalt212 on 5/8/25, 1:00 PM
Interesting point. I'm going to see if they similarly struggle generating VBA code vs generating Visual Basic code.
by busymom0 on 5/8/25, 10:09 PM
I posted this iOS Swift Programming question today:
https://stackoverflow.com/questions/79612931/ios-custom-oper...
and was instantly downvoted and then voted to closed. I do not think this question was worth downvoting or closing. There's no hits on the warning I was getting.
People on SO nowadays seem way too eager to downvote and close.
by dkackman11 on 5/8/25, 10:41 PM
by jiggawatts on 5/9/25, 9:08 AM
The right place for this kind of question is the GitHub Issue tracker for CoreWCF, where you'll find several related issues. You're not the first one to hit bugs in streaming mode, which is... fragile. Just turning HTTPS on or off can break it: https://github.com/CoreWCF/CoreWCF/issues/1391
Unbounded streaming is something WCF was not designed to support, and hence CoreWCF doesn't support it either. CancellationTokens, etc... might improve things in case of accidental disconnection of a client session, but in general WCF expects streamed responses to have a finite length and be explicitly terminated with an end-of-stream by the server.
E.g.: read the end of this section: https://learn.microsoft.com/en-us/dotnet/framework/wcf/featu...
"Streamed transfers end and the message is closed when the stream reaches the end of file (EOF). When sending a message (returning a value or invoking an operation), you can pass a FileStream and the WCF infrastructure subsequently pulls all the data from that stream until the stream has been completely read and reached EOF."
Fundamentally, WCF is a message-oriented RPC system. It has many issues with streaming: it has to be explicitly enabled, it is incompatible with many features, etc...
Just "read between the lines" in your stack trace! It mentions XML encoding in several places, but XML as used in RPC uses a "tree" structure which must be terminated with closing tags.
You might be able to shoehorn unbounded streams into CoreWCF by implementing custom channels and encodings, but at that point it isn't really WCF any more!
The bug is that CoreWCF really should give up and stop writing if the client is disconnected. Stepping through its code, it does look like it loses track of the CancellationToken at some point, probably riiiight here: https://github.com/CoreWCF/CoreWCF/blob/067f83b490332120f45e...
Note the comments surrounding it talking about things like "TODO: Verify that the cancellation token is honored for timeout" and "Since HTTP streams don't support timeouts, we can't just use TimeoutStream here." That sounds unfinished to me.
I can't be sure, but there seem to be some design flaws that also contribute to this bug. E.g.: CoreWCF uses synchronous writes to ASP.NET Core's pipeline, which is... also a buggy mess because it is so rarely used.
Then, somehow, it is still writing to a socket that is long gone, which is really odd. It really does feel like there's at least a DoS security bug here, either in ASP.NET when operating in sync mode or in CoreWCF. The issue is that malicious clients could easily request many large responses, disconnect, and the server would keep processing the requests for hours and hours.
by xyst on 5/8/25, 1:47 PM
Seems like an issue with not closing resources properly. Looking at your server code, seems the Close and Dispose methods are not overridden. Try that?
by incoming1211 on 5/8/25, 10:58 PM
SO is trash now-a-days.
by BrandoElFollito on 5/8/25, 10:01 PM
Now at 200k+ rep I cannot stand it anymore. Whenever I ask a question that does not make me bow backwards or discuss how my Python code looks in assembly it gets downvoted almost immediately. Go and Typescript are tags that being frustration.
Now compare this with many other Stack Exchange sites.
A question about cooking or LaTeX gets nice, coloriant answers, even when they are basic.
I get it that they are one or two orders of magnitude less crowded but this may mean that SO passed its scale limit and is done.
by neonsunset on 5/8/25, 1:22 PM
(although I have no idea how active CoreWCF owners are w.r.t this)
by bitbasher on 5/8/25, 2:10 PM