You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today I needed to use a pretty non-standard configuration for lapin, and it was very hard to set up. I had difficulties setting up tokio as the executor and also using rustls with webpki root certs, but I think it's maybe better to focus on one issue at a time.
My biggest issue switching the runtime to tokio was requiring two other dependencies in the amqp-rs/ namespace (tokio-executor-trait and tokio-reactor-trait) and also ensuring they were in-sync with lapin itself.
I think that maybe lapin could offer a new tokio feature, that depends on these two (just like default-runtime does) and maybe also provide a ConnectionProperties constructor that automatically sets them up? Or maybe just using them in the Default implementation if the feature is enabled?
I may try this approach in a fork to simplify my downstream configuration. If it's ok by you, I could also work on a PR.
Thanks for your work on this project, by the way!
The text was updated successfully, but these errors were encountered:
When the tokio-runtume is enabled, the appropriate executor and reactor are passed-in by default, without requiring any set-up from the user. If this looks fine, I could roll a PR, but I'm also happy to make any necessary changes
Today I needed to use a pretty non-standard configuration for lapin, and it was very hard to set up. I had difficulties setting up tokio as the executor and also using rustls with webpki root certs, but I think it's maybe better to focus on one issue at a time.
My biggest issue switching the runtime to tokio was requiring two other dependencies in the amqp-rs/ namespace (
tokio-executor-trait
andtokio-reactor-trait
) and also ensuring they were in-sync with lapin itself.I think that maybe lapin could offer a new
tokio
feature, that depends on these two (just likedefault-runtime
does) and maybe also provide aConnectionProperties
constructor that automatically sets them up? Or maybe just using them in theDefault
implementation if the feature is enabled?I may try this approach in a fork to simplify my downstream configuration. If it's ok by you, I could also work on a PR.
Thanks for your work on this project, by the way!
The text was updated successfully, but these errors were encountered: