Docs: clarify how unregistering works with shared registrations

[gdmoore]

Python 3.8, using Autobahn|Py 20.3.1, and Crossbar from crossbario/crossbar:pypy3-20.2.1

What I'm trying to do is have a pool of workers handling an endpoint with shared registration (roundrobin), and after a set number of invocations, a worker will unregister itself and exit so that a fresh process can take its' place.

Steps:

• create two processes; each connects to Crossbar and registers an endpoint named endpoint with options=RegisterOptions(invoke="roundrobin")
• from a third process, begin calling endpoint repeatedly; it works as expected and alternates between the two registered processes
• have one of the processes unregister their endpoint by calling unregister() on the Registration object provided by register()
• from the third process, calling endpoint now appears to hang

Is this expected behaviour, or a bug? I am assuming bug since it hangs instead of returning a no callee error.

The behaviour I'd most like to see is that if someone unregisters an endpoint that is shared registration, calls continue to be routed to the other remaining registered endpoints. If that isn't a good approach in general then I can fairly easily work around this by managing the round robin myself with some RPC endpoint shuffling.

[gdmoore]

Actually I think this issue is invalid -- the hang appears to have been caused by my RPC callee attempting to unregister itself during the call, as opposed to after the call was complete.

[gdmoore]

The original issue is definitely incorrect but is the documentation right for this?

From https://crossbar.io/docs/How-Registrations-Work/ Using the registration ID, a callee can unregister the procedure at any time.

Based on the docs shouldn't I be able to get away with calling unregister in the context of the call?

[oberstet]

The behaviour I'd most like to see is that if someone unregisters an endpoint that is shared registration, calls continue to be routed to the other remaining registered endpoints.

yes, that's how it should behave.

to get away with calling unregister in the context of the call?

not sure what that means. registrations are tracked per callee, so with shared registrations, each callee can unregister independently. once the last callee unregisters, the router will destroy the registration.

[meejah]

It should maybe read, "any time, as long as it's in the next reactor loop". A common idiom for this in Twisted is reactor.callLater(0, unregister). But, this could be clarified in the docs, yes.

[oberstet]

OT, but thinking about "unregister" scenarios with shared regs: actually, I am wondering if we treat that right when using call queuing on shared regs, as in https://github.com/crossbario/crossbar-examples/tree/master/scaling-microservices/queued

[gdmoore]

meejah's response clarified it; I'm using asyncio so during my RPC call asyncio.get_event_loop().call_soon(unregister) works fine. Thanks.