Open gdmoore opened 4 years ago
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.
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?
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.
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.
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
meejah's response clarified it; I'm using asyncio so during my RPC call asyncio.get_event_loop().call_soon(unregister)
works fine. Thanks.
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:
endpoint
withoptions=RegisterOptions(invoke="roundrobin")
endpoint
repeatedly; it works as expected and alternates between the two registered processesunregister()
on the Registration object provided byregister()
endpoint
now appears to hangIs 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.