Repository navigation
Fix call chain reentrancy - #5145
Conversation
|
I perf tested it, and do not see any measurable negative impact. |
|
@dotnet-bot test functional |
|
Thanks for the info. I will move forward with this design. Ben mentioned removing the enum and just keeping it as the default behavior. This will change the behavior, but since there is no perf impact and we consider the current behavior a bug I will take his suggestion. |
| /// <param name="message">Message to analyze</param> | ||
| private void CheckDeadlock(Message message) | ||
| /// <returns></returns> | ||
| private bool IsMessageACallChainLoop(Message message) |
There was a problem hiding this comment.
While the on-wire compatibility shouldn't be an issue between silos from 2.1.x and silos that will implement this logic, there might be issues during the deployment since we are changing the logic here.
But I don't think we have any way to address that...
There was a problem hiding this comment.
We could have release notes that say enable deadlock detection if you want it to work during upgrade.
|
Forgot to publish my reviews... dammit GitHub UI |
…re not 'InvokeMethodRequest's which caused a cast exception
77633ab to
66a6f51
Compare
|
@dotnet-bot test functional |
|
@benjaminpetit, I think I addressed all your comments. Let me know if there are any other changes you would like to see. |
benjaminpetit
left a comment
benjaminpetit
left a comment
There was a problem hiding this comment.
LGTM. I'll kick off a backward compat testing
This reverts commit 8d8cd70.
This reverts commit 8d8cd70.
4 participants
Current behavior is to only allow call chain re-entrancy on A->B->A or A->A. This adds a new option for allowing A->B->C->A. Also flow the reentrancy context via RequestContext so that it can be viewed and serialized by the application layer.
Passes call chain tests. Sending an early version for feedback on the approach.
Remaining questions: