GemTalk / RemoteServiceReplication

MIT License
0 stars 4 forks source link

Service Leaks #133

Open kurtkilpela opened 2 years ago

kurtkilpela commented 2 years ago

It is possible to leak a service. When replicating a Server, we strongly retain it under the assumption that the remote side will successfully reify the Server into a Client.

If we replicate a Service, in the transitive closure, before the Client would be created, we can end up having a strongly-retained Server without an associated Client. This would mean the Server would never be subject to garbage collection.

This situation is recoverable if the Server is later part of a successful replication.

martinmcclure commented 2 years ago

Under what conditions would the client service not be created on the remote side? Can the remote side send a packet back in those cases?

kurtkilpela commented 2 years ago

We send a list of Service instances that need to be reified. When a Server is replicated, we strongly retain it, assuming a Client will be successfully reified remotely. If an error occurs, for instance, a Service is not compatible remotely, and this happens before the associated Client was reified, we will abort the process an a Client will never have been created.

It isn't as simple as sending a packet back in those cases. We need to retain information about whether the Service had previously been replicated or not. If so, we don't want to weakly retain a Server. If not, we may have already created the Client remotely.

The replication process needs to be made more sophisticated to properly handle these cases.

kurtkilpela commented 2 years ago

There is some sort of state machine here but it seems to manifest, in part, on both sides of the Connection.