SeamlessReferencedObjectIsLost about pharothings HOT 7 CLOSED

Hm. I tried to reproduce it but I got different behavior.
When I connected again and switch to the browser I got BasysRemotePeerClosed error when I changed selection.

Can you give me more details how to get SeamlessReferencedObjectIsLost?

from pharothings.

But let me explain the current logic:
Currently #disconnect is implemented as very hardcore operation. It performs "remotePeer destroy" which is not safe way to continue work then. Destroy operation has no idea about how received remote objects (proxies) are used in the image. If they are stored somewhere in domain code they will become broken and therefore users will become broken which is what we see in these scenarios. So #destroy assumes that all users of remote objects will be manually closed/removed (like all "remote windows" will be closed).
If it is not ensured it then opened remote browser is became broken. Even worse it did not get a chance to release subscriptions on the remote image and it left broken proxies there. Basically it corrupts the image state.

To fix this situation we need to change #disconnect semantics. It should not destroy the network. It should just cleanup client tools on the remote side. It is what it does now but we should remove #destroy part.

Problem here is that we will never cleanup caches anymore because we do not have garbage collection for them. And It is a reason why it is done with destroy right now. It is the only way to manually clean the communication level (Seamless part).

from pharothings.

I thought more about it. Without solving complex garbage collection task we just need a fallback logic on the server side (where we connect the TelePharo).
It should react on unhandled Seamless exceptions and completely clean all registered remote tools. So TelePharo knows where on server it registers remote objects. So server part of this system can perform required cleanup to recover the original state.

from pharothings.

We analysed the problem more. What we think is happening is that there are Announcers around that have registered objects that are not valid anymore.

This would explain the behaviour: we can use the browser, we can use the inspector. Just when we save we get the error.

We put a halt in the server side #signal method and saw that we get the error when the announcer of some subclass of ClyQueryResult tries to execute the announcement.

We see that this announcer has an announcement subscription where the subscriber is a SeamlessMissingObject.

So it seems that there are announcers on the server side that are from the old browser that, if we accept a method, try get delivered, but as they are old, the underlying connection is closed.

The question is how to fix that... to test the theory, we could, in #signal, try to remove the faulty announcement subcriptions? This way the error would happen once and then would fix itself?
Or is there a better place?

from pharothings.

pharo-ide/TelePharo#30

from pharothings.

Sorry, I forgot to answer. Ping me next time if I am silent

from pharothings.

Fixed in TelePharo issue pharo-ide/TelePharo#30

from pharothings.