Proxy for expensive API requests #736
Conversation
scohen
force-pushed
the
api-proxy
branch
2 times, most recently
from
518cb51 to
476cd92
Compare
apps/remote_control/lib/lexical/remote_control/api/proxy/state.ex
Outdated
Show resolved
Hide resolved
apps/remote_control/lib/lexical/remote_control/api/proxy/state.ex
Outdated
Show resolved
Hide resolved
apps/remote_control/lib/lexical/remote_control/api/proxy/state.ex
Outdated
Show resolved
Hide resolved
apps/remote_control/lib/lexical/remote_control/api/proxy/records.ex
Outdated
Show resolved
Hide resolved
|
@zachallaun can you please respond to the comments? |
scohen
force-pushed
the
api-proxy
branch
2 times, most recently
from
4c93891 to
985e8a8
Compare
|
@scohen I was having a hard time articulating my thoughts on the proxy state stuff, so I went ahead and implemented two changes that I think help to simplify things. They could be taken individually (with some changes), so I'd recommend looking at the two commits separately: |
apps/remote_control/lib/lexical/remote_control/api/proxy/state.ex
Outdated
Show resolved
Hide resolved
When doing complicated refactors, the language server will often spam remote_control with a ton of operations when the refactor is going on. These operations will slow down both the editor and remote_control so that it's not particularly usable. In order to mitigate this, certain operations, like project compilation, can be buffered and completed when the refactor has completed. This PR implements a proxy module that buffers these complicated operations, and monitors the calling process. When that process exits, the buffered operations are emitted in remote_control, allowing them to complete without disrupting the refactor.
* Use mfa record for proxied broadcasts * Add sequence number to proxied mfa's to track order --------- Co-authored-by: Zach Allaun <[email protected]>
|
To summarize my exploration today, I found that removing |
|
Additionally, I tried integrating this PR with the Rename module branch, and I found that the renaming can be completed instantly. However, we can't avoid a series of @scohen I hope you can take a look at this commit when you have time; maybe I'm using the API.Proxy method incorrectly. |
|
@scottming removing the locks is the likely cause for the queueing you’re seeing. That’s not the correct path forward |
In testing, I found two deadlocks. The first was that the build server was using RemoteControl.call to invoke itself rather than `GenServer.call`. This created an additional lock, and was unnecessary, because it's running locally. The second was more insidious. The proxy module made a bunch of separate calls to other modules, which in turn woud call `Build.with_lock`, which would then be run inside the proxy's process. This would cause fairly frequent locks in the proxy process. Moving these calls into tasks, fixes things, but creates the need for an additional `draining` state of the proxy, which it enteres if there are in-flight requests when `start_buffering` is called.
When doing complicated refactors, the language server will often spam remote_control with a ton of operations when the refactor is going on. These operations will slow down both the editor and remote_control so that it's not particularly usable. In order to mitigate this, certain operations, like project compilation, can be buffered and completed when the refactor has completed.
This PR implements a proxy module that buffers these complicated operations, and monitors the calling process. When that process exits, the buffered operations are emitted in remote_control, allowing them to complete without disrupting the refactor.