-
Notifications
You must be signed in to change notification settings - Fork 522
Conversation
} | ||
protected int TransitionToState(int state) | ||
{ | ||
#pragma warning disable CS0420 // A reference to a volatile field will not be treated as volatile |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't disabling this potentially dangerous?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is a spurious compile warning though perhaps I can just go
int prevState = _frameState;
rather than
int prevState = Volatile.Read(ref _frameState);
and not get the error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, my worry is that passing volatile fields as ref (or out) may have different behavior on different CPU architectures.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now you raise is... changed to normal int
and changed all reads to Volatile.Read
as while volatile
gives compiler guarantees which is enough on Intel; it doesn't give CPU guarantees which may nor be enough on arm. (Don't know how the traditional C# memory memory model works on other chipssets). Also I'm using the value with Interlocked
which wants ref
Also I've rolled two flags into one state and added some extras; so safety first.
07c3768
to
13dc4ef
Compare
Added keep-alive as: |
{ | ||
SocketInput?.AbortAwaiting(); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: add newline
6dfcabc
to
c8566a2
Compare
Just need to add tests (I think) |
Yes, please 😄 |
Check pointing. Still needs more work in light of #566 (comment) |
Should have it finished tomorrow. |
@@ -388,6 +387,22 @@ void ISocketOutput.Write(ArraySegment<byte> buffer, bool immediate, bool chunk) | |||
|
|||
Task ISocketOutput.WriteAsync(ArraySegment<byte> buffer, bool immediate, bool chunk, CancellationToken cancellationToken) | |||
{ | |||
if (cancellationToken.IsCancellationRequested) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want to register with the cancellation token for writes that actually result in an incomplete task being returned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done; not sure perf effects; but on the plus side I've removed some boxing and unboxing 😜
Checkpoint |
@@ -238,6 +239,14 @@ public void GetResult() | |||
var error = _awaitableError; | |||
if (error != null) | |||
{ | |||
if (error is OperationCanceledException) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrong error handling
Question on how to handle error in |
build stalls when merged with the dotnet update - investigating |
😞 Try setting |
Having a little look as it works without the merge; trying just upping threads e.g. |
|
||
private static TimeSpan GetTimeout(IConfiguration configuration, string configurationKey, int defaultSeconds) | ||
{ | ||
var timeoutString = configuration[configurationKey]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not pass timeoutString directly to this method?
Thread count didn't help; got a failed restore second time; third time (without Might be a dotnet cli issue instead |
@benaadams Yeah, we think it might be dotnet, or the xunit console runner is doing something funny. |
@benaadams Did you see it hang consistently? I've only seen it hang on AppVeyor, can't repro on my box. |
No; but also get on/off restore issues with (e.g. delete directory; then do fresh get from github) |
We should be able to add this for rc2. Do you still think you can write some test cases for this? Thanks! |
I'd like advice on test cases; waiting for timeouts and CI never seem to mix well... |
To clarify further; the timeouts are in seconds so can't go finer than that; and CI is flakey with timeout numbers ;-/ Write write some see how it goes |
I would make timeouts very short (maybe a tenth of a second) and verify that you get 500 responses (header timeout) or the that connection is gracefully (keepalive timeout)/ungracefully(execution timeout). Also verify that ongoing reads get aborted in the event you are in the executing phase. You can be very generous with the amount of time you wait for the timeouts to trigger. I wouldn't mind if we waited 10 seconds (100 times what they are set to) for the timeouts to trigger. Hopefully that will be long enough for travis/appveyor. If not, we can adjust. |
Oh. And this isn't urgent. Feel free to wait until we get AppVeyor and Travis passing again (maybe someday 😞) so you can verify the timeouts work. |
Obviously I need to get it in before #623 - think of the merge! ;-) |
/cc @halter73 away for a week; so won't be able to rebase or make changes during that time. |
using Microsoft.AspNetCore.Server.Kestrel.Filter; | ||
|
||
namespace Microsoft.AspNetCore.Server.Kestrel | ||
{ | ||
public interface IKestrelServerInformation | ||
{ | ||
TimeSpan ExecutionTimeout { get; set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
KeepAlive and HeadersComplete are reasonable, but I don't think we need or want ExecutionTimeout at the server level.
A) The same functionality can be provided in app/middleware code.
B) The timeout is un-enforceable. You can't force an app to abandon a request, you can only close the socket and trip the token. The RequestAborted CancellationToken is at best a hint. There are no thread aborts like v4.
C) There are known scenarios this breaks with long running requests. It's one more setting on the server to hunt down and fiddle with when that happens.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🆗
I'm pretty confused. Is there currently an ExecutionTimeout in Kestrel? If so, how to we stop it, or change it? I'm getting a WCF timeout that I can't explain unless it's something going on with a Kestrel request timeout. |
There's no execution timeout in kestrel (which isn't possible to do with async requests because if there's no thread running then there's nothing to time out). How would kestrel affect your WCF service? The ASP.NET core module has a 2 minute timeout for requests, maybe you're running into that? |
For #464, #483, #484
Still needs