[sn_client] Client is not prepared for connection reuse. #2060
Comments
|
I could reuse a connection earlier, like in the end of 2023, so I'd say it's a regression. |
|
I have the same problem with |
|
I was executing Probably this setup was problematic, because now, when I connect also in async command fired from frontend, like the rest of commands (faucet and register), connection is not lost. I don't close the issue in case you decided, that my first approach was ok, and it should be supported in API. |
|
Did you try doing it before calling the builder, in Or in a I haven't bothered yet. For now I create it inside each async handler when it runs. |
|
I'm using Tauri 2, so it has main.rs with |
|
I'm using Tauri 2 as well, (it does still have So same Q applies in I'll make a note of this topic and maybe try different options at some point. One trade-off occurred to me. Keeping the client alive as you are avoids the need to connect each time, but maybe it also removes the possibility of parallel access? If every thread is queued waiting for the MutEx instead of making its own client, all fetches and other interactions might be forced to be sequential. If you make a separate client to get each resource, they all take a bit longer to start but might overlap and be faster for that kind of access. What do you think? |
|
Autonomi uses async/await, so I wonder, maybe when you use async-aware Mutex, the calls can do their work in parallel somehow? |
|
await is just that - the thread stops until the called function returns. The parallel part is that other threads continue. I think Mutex is a way to ensure shared values can be written and read by different threads in a deterministic way, but that can lead to deadlocks - two threads waiting on each other. The parallel feature is set up, usually in main() where a kind of loop is executed which checks to see if each thread can run one after the other, and skips any that are waiting for something. That's my vague understanding, although I'm not sure if thread is the correct term. vdash uses this approach to handle updates to multiple logfiles intermingled with an event handler which both handles keyboard input and updates the display. It all looks like it's happening in parallel, but really it's just running the first thing that it finds has something to do until that has completed, or has hit an await, or is waiting for a lock on share data etc. I've no idea if there is a recommended way to use the Client so I've steared clear of anything clever for now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm getting an error "Failed to receive transfer due to InvalidTransfer(\"Internal messaging channel was dropped\")" on call to
Client::receive(). A client, that was made byClient::new()was kept in Tauri managed state.Same operations in immediate form (connect, load wallet, receive – one after another) resulted in a successful cashnotes reception.
sn_clientversion 0.109.0(more discusson: https://forum.autonomi.community/t/reusing-a-connection/40243)
The text was updated successfully, but these errors were encountered: