Open alissa-tung opened 6 months ago
- will calls on
ServerSocket::request
returnedMainLoop::new_client
applies Tower layers?- did I miss something or some methods when logging on trait methods fn notify, fn emit and fn call
Unfortunately, no at least for now. It will enqueue the message and send it to the peer directly without extra handlers. You can wrap the *Socket
to do that though that will change the type.
I think Tower layers are mainly used to modular services construction, so the local connection API *Socket
does not apply. We can wrap tower layers on it, but I don't know how useful it is besides for logging purpose. Also the delay you measured on *Socket::request
would be your protocol peer's handling delay, which is outside your control.
- what is the event in the library?
It is mentioned in LspService::emit
. It's a custom message passing method to do stuff synchronously in the main loop, or trigger specific works in the main loop from other threads. Eg. trigger server exit on some conditions maybe from another thread (used by client_monitor
here), diagnostic refresh after some delay (timer tick event example here), and etc. Since the event handling is always executed synchronously in the main thread, you can use &mut self
without locking and don't need to tangle with async-request reordering.
Thank you for developing this library, and
Hello, I had tried two ways creating Tower layers to make some logs:
fn notify
,fn emit
andfn call
forward
feature, mock the server and client like whatexamples/interceptor.rs
do, logging on trait methodsfn notify
,fn emit
andfn call
both approach applies logs for requests from server to client, but does not work for the requests that I filed from client with
ServerSocket::request
, where theServerSocket
instance is returned byMainLoop::new_client
.My questions are:
ServerSocket::request
returnedMainLoop::new_client
applies Tower layers?fn notify
,fn emit
andfn call
event
in the library?I had also tried to use the builder function
MainLoop::new_client
's server socket argument, userouter.request::<ACustomRequest>(|router_state, request| { logging here; return here })
. butMainLoop::new_client
do.request::<MainLoop::new_client>(....)
does not work, the callback is not fired.request::<MainLoop::new_client>(....)
callback, calling the.request
ofserver_socket
yields theResult<_, async_lsp:Error>
, but not theResult<_, async_lsp:ResponseError>
which is required by therouter.request
callback