←back to thread

My stackoverflow question was closed so here's a blog post about CoreWCF

(richardcocks.github.io)
123 points eterm | 1 comments | 08 May 25 12:11 UTC | HN request time: 0s | source
Show context
eterm ◴[08 May 25 12:11 UTC] No.43925356[source]▶
A post in which I try to rubber-duck a CoreWCF issue I've been having, because stackoverflow no longer seems suitable for asking questions about programming issues.

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.

replies(10): >>43925551 #>>43925669 #>>43925930 #>>43925975 #>>43926332 #>>43927351 #>>43931071 #>>43933405 #>>43933839 #>>43935803 #
npodbielski ◴[08 May 25 15:50 UTC] No.43927351[source]▶
Hey mate is it your post? I did glanced at it and it does not stop because server is not notified that client is not there.

Or at least that is my guess, since I stopped working with WCF about 2016 probably.

Anyway in newer version of .net you CancellationToken everywhere what would do exactly that: tell your server that client disconnected. That would be my first try on fixing it.

Use token that is sent via HTTP implementation to the endpoint, pass it to your stream and when it is cancelled, end the stream. Stream ends, endpoint finishes, not CPU load.

replies(1): >>43933445 #
1. treebeard901 ◴[09 May 25 03:02 UTC] No.43933445[source]▶
Yeah the stream isnt being closed properly as it is likely still trying to fill a buffer that no longer exists. The CancellationToken is a good idea regardless because you know once youve written the result, that you no longer need to wait for results.

Using has similar problems with things like database connections remaining open.