Fix:deal the panic when invoker destroy #358
Conversation
protocol/dubbo/dubbo_invoker.go
Outdated
| @@ -47,6 +47,7 @@ var ( | |||
|
|
|||
| // DubboInvoker ... | |||
There was a problem hiding this comment.
add comment for this file, pls.
Codecov Report
@@ Coverage Diff @@
## develop #358 +/- ##
===========================================
- Coverage 66.74% 66.55% -0.19%
===========================================
Files 150 150
Lines 7936 7960 +24
===========================================
+ Hits 5297 5298 +1
- Misses 2137 2157 +20
- Partials 502 505 +3
Continue to review full report at Codecov.
|
pantianying
changed the title
| @@ -110,11 +120,20 @@ func (di *DubboInvoker) Invoke(ctx context.Context, invocation protocol.Invocati | |||
| // Destroy ... | |||
| func (di *DubboInvoker) Destroy() { | |||
| di.quitOnce.Do(func() { | |||
There was a problem hiding this comment.
someone check this pls: Can this be async
There was a problem hiding this comment.
the reqNum is used for judging if dubbo invoker is available ? Why not use isAvailable() func instead?
There was a problem hiding this comment.
This is used to check whether there are any stock requests in the invoker during destroy
|
@flycash I think maybe graceful down should consider the issue. |
| } | ||
|
|
There was a problem hiding this comment.
In extreme cases, infinite circulation possible? Should we control the upper limit？
There was a problem hiding this comment.
In extreme cases，there is always a request in the invoker that has not ended. If it is forcibly destroyed, it may cause a program panic. The severity of this result is greater than adding a loop.
Fix:deal the panic when invoker destroy
Merge pull request #358 from pantianying/addRlockForDubboInvoker
What this PR does:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: