Cancelation of dependent services #1819
-
I appologies if I have missed something in the documetnaiton, but have tried reading both in axum, tower::Service and the axum examples. My question is (relatively sinple), how are services / requests that may be canceled best / idiomatically handled in axum / tower? (I.e. effectively the context.Context.Done() channel in golang). As a more direct use case I have a web service which accepts incoming requests to start long running simulations (order of minutes). In cases where the incoming http / tcp request is closed by the user i want to be able to both not start simulations for closed requests but also get notified in my handler if the underlying tcp connection is closed such that I can signal my simulation to stop directly. (I found #1094 but is not applicable since my "simulation" is hosted in a different thread I communicate with using channels. I guess i could create a custom type that has a custom Drop implementation to send a signal to my worker if it's dropped, it does feel a bit cumbersom - but maybe that is the ideomatic way to go?) Many thanks |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
axum doesn't have any knowledge of the underlying connection. All it knows is the tower When you figure out how to do it it would be nice to add it as an example to axum. I imagine its a somewhat common thing to need. |
Beta Was this translation helpful? Give feedback.
axum doesn't have any knowledge of the underlying connection. All it knows is the tower
Service
trait. Hyper manages the connections. So you somehow need to hook in at that level to do stuff when hyper closes a connection. I'm not really sure how to do that. Try asking in the hyper repo or in#hyper
in the tokio discord.When you figure out how to do it it would be nice to add it as an example to axum. I imagine its a somewhat common thing to need.