pycapnp

pycapnp copied to clipboard

With reference to the following design: [https://groups.google.com/g/capnproto/c/t2wPNzZ4MGQ]

Here, subscribe() returns a subscription object. This object has no methods. But, when the capability is dropped, then the destructor will run on the server side. Atn that point, you can remove the subscription.

A big advantage of this approach is that it handles connection failures gracefully. If the client randomly disconnects, the subscription capability is automatically dropped, thus unsubscribing the client. This way you don't end up stuck sending messages to a disconnected subscriber.

It also solves your problem because you can remember arbitrary metadata about the subscriber within the Subscription object, so you know what to remove when it's destroyed.

And #208 is probably related.

My specific problem: When a capability is dropped (for example a subscriber is killed), the server-side (publisher-side) reference to that subscriber is not deleted. In a c++ version of the same interface, the suggestion above from Kenton Varda works as expected.

My workaround:
For now, the server catches disconnects by detecting the eof on the reader, and then removes the reference to the subscriber associated with that reader.

The limitation with my workaround is that only one interface/capability can be used per connection. Watching the socket in order to detect when a local object goes out of scope also feels hacky.

It seems like pycapnp just never releases connections? In my code I see a bunch of open connections to the server for capabilities that are clearly out of scope on the Python side, but don't disconnect until you stop Python.