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
// super.shutdownImpl will only shutdown requests registered for
// receiving or sending. There may also be requests that are registered
// for neither sending nor receiving which need to be shutdown.
this.request_set.shutdownAll(e);
). (There is no way that the requests can continue operating after the connection is shut down.)
The client should have similar logic, but it is more complicated as the client just has a single RequestSet which is shared by all connections. Thus, the client would need to cancel all requests that are associated with the connection which has been shut down. Most of the time, these will be registered with the connection for sending or receiving, so are easy to spot. However, it's also possible for a request to be in a state where it's waiting for some other event to occur (e.g. the user to call resume() on its controller). There is currently no way to detect requests in this state and cancel them properly if a connection is shut down.
How exactly this would need to work varies by request type:
For all-nodes requests this is obvious: each request-on-conn is tied to single connection.
Single-node and round-robin request-on-conns may switch between connections over their lifetime. We'd have to track which requests were using which connection in order to be able to cancel them.
The text was updated successfully, but these errors were encountered:
The node cancels all requests in a connection's
RequestSet
, when the connection is shut down (seeswarm/src/swarm/neo/node/Connection.d
Lines 162 to 165 in 02dfdeb
The client should have similar logic, but it is more complicated as the client just has a single
RequestSet
which is shared by all connections. Thus, the client would need to cancel all requests that are associated with the connection which has been shut down. Most of the time, these will be registered with the connection for sending or receiving, so are easy to spot. However, it's also possible for a request to be in a state where it's waiting for some other event to occur (e.g. the user to callresume()
on its controller). There is currently no way to detect requests in this state and cancel them properly if a connection is shut down.How exactly this would need to work varies by request type:
The text was updated successfully, but these errors were encountered: