These APIs (for example) all require &mut self
pub async fn send_non_blocking<T: SerializeMessage + Sized>(&mut self,message: T) -> Result<SendFuture, Error>pub async fn ack(&mut self, msg: &Message<T>) -> Result<(), ConsumerError>pub async fn nack(&mut self, msg: &Message<T>) -> Result<(), ConsumerError>
That makes sharing connections between many tokio tasks more difficult than I'd like.
Today I work around this by making an actor like worker that owns the connection and many clients send requests with oneshots to wait for completion. This is more non-trivial than I'd like.
I looked into why sending requires mutability and I found:
- send_non_blocking calls send_non_blocking on the specific producer in the multi producer
- That calls sends on either the single or partition with your message
- That calls send_raw on the producer
- Which calls send_inner
- Which can call reconnect which requires replacing our connection with the new one
- It also replaces the batch settings which requires mut
- Also looking into it more the partitioned topic code also needs mutable to walk the partitions for round robin=
These APIs (for example) all require
&mut selfpub async fn send_non_blocking<T: SerializeMessage + Sized>(&mut self,message: T) -> Result<SendFuture, Error>pub async fn ack(&mut self, msg: &Message<T>) -> Result<(), ConsumerError>pub async fn nack(&mut self, msg: &Message<T>) -> Result<(), ConsumerError>That makes sharing connections between many tokio tasks more difficult than I'd like.
Today I work around this by making an actor like worker that owns the connection and many clients send requests with oneshots to wait for completion. This is more non-trivial than I'd like.
I looked into why sending requires mutability and I found: