Add separate send queue for kbfs file edit messages skipping the outbox #23530
Conversation
|
Can you please wait for me to review this as well before you merge? I'll look tomorrow. |
|
Probably can't work this way, I'd like the calls from KBFS to still return to it immediately. |
joshblum
force-pushed
the
joshblum/kbfs-queue-HOTPOT-2100
branch
from
e13b398 to
26600b5
Compare
|
|
||
| s.delivering = true | ||
| s.shutdownCh = make(chan struct{}) | ||
| s.eg.Go(func() error { return s.deliverLoop(s.shutdownCh) }) |
There was a problem hiding this comment.
changed to support multiple loops
| s.Debug(ctx, "stopping") | ||
| close(s.shutdownCh) | ||
| s.delivering = false | ||
| go func() { |
There was a problem hiding this comment.
block cb until loops finish
| defer s.Trace(ctx, func() error { return err }, "Queue")() | ||
|
|
||
| // KBFSFILEEDIT msgs skip the traditional outbox | ||
| if msg.ClientHeader.Conv.TopicType == chat1.TopicType_KBFSFILEEDIT { |
There was a problem hiding this comment.
skip outbox for kbfs files
| return true | ||
| } | ||
|
|
||
| func (s *Deliverer) kbfsDeliverLoop(shutdownCh chan struct{}) error { |
There was a problem hiding this comment.
read off of kbfs queue and do send
joshblum
changed the title
joshblum
changed the title
|
With no more KBFS changes, there's no need to wait for my review anymore. But I'm curious how this fixes the actual deadlock in the original report. is it just an orthogonal fix that will slow down the processing of kbfs edit requests? Or does it fix the actual, persistent deadlock observed in that issue? |
|
@strib I'll look further into the deadlock, this PR is just to address the load on the chat system. |
joshblum
force-pushed
the
joshblum/kbfs-queue-HOTPOT-2100
branch
from
b316d3d to
de28afa
Compare
…ox (#23530) * Limit the number of concurrent KBFS chat posts, use post local instead of nonblock rpc * pseudo nonblock * deliverer * Fix kbfs loop * merge
No description provided.