autobahn with uvloop policy won't work

[italomaia]

If uvloop event policy is set, autobahn server won't handshake with client.

To reproduce this, just use the following:

import asyncio
import uvloop

# use uvloop loop policy
asyncio.set_event_loop_policy(uvloop.EventLoopPolicy())

[meejah]

That should affect the global asycnio event-loop, right?

Possibly see also crossbario/txaio#97 and #747 (comment) but I think those are different issues -- you're only trying to use one event-loop here, correct?

I'm not very familiar with how the event-loop-policies work in asyncio; does it matter when get_event_loop was called? That is, if txaio grabbed its loop before you called set_event_loop_policy, would it have gotten a different event-loop instance?

[agronholm]

@italomaia I think you're setting the event loop policy after calling txaio.use_asyncio(). If not, can you share with us a script that reproduces this?

[OOPMan]

@meejah I'm testing uvloop with some Python 3 Crossbar components right now and it seems to work fine. In fact, comparing the VIRT/RES usage between uvloop and the default event loop I noticed that uvloop seems to be vastly more resource efficient

[meejah]

Okay, thanks for the update!

[oberstet]

comparing the VIRT/RES usage between uvloop and the default event loop I noticed that uvloop seems to be vastly more resource efficient

@OOPMan Interesting! Was this running an AutobahnPython component in a guest worker, or did you swap out the loop in Crossbar.io itself? (running the component in a container or router worker). Because, if the former, we could profit from these savings in CB itself ..

[agronholm]

But Crossbar uses Twisted, not asyncio right? So how would one switch to uvloop in Crossbar?

[OOPMan]

@oberstet I was just using uvloop in a guest component, as last time I checked it was still not possible to run Python 3 components inside a container or router worker?

[oberstet]

@agronholm Yeah, this is what I assumed would be possible with what @OOPMan does. Actually, not sure. Maybe I misunderstand. But here https://gist.github.com/ldjebran/4febf298232a6fd86871df25d4dc00dd

[oberstet]

@OOPMan Ahh, ok. Well, Crossbar.io and components running embedded run fine on Python 2 and 3, but always on top of Twisted. It might be possible to run it on Twisted with asyncioreactor using uvloop. Hence I am interested when hearing about lower resource consumption. When your component is written to the asyncio API of the Python standard library however, I'm afraid you cannot run those inside container/router workers, as that would require Crossbar.io itself be implemented only using say txaio, not Twisted stuff - and that is out of scope, because we use a lot more from Twisted than only the event loop;)

[oberstet]

However, to be fair, the comparison is more sorts of Twisted ecosystem vs the asyncio ecosystem, and being able to tap into both would be of course awesome! With Twisted gaining more asyncio native support at the API level from syntax to native asyncio Futures, and the perspective of running Twisted on top of the same uvloop that drives asyncio components, that could be a start at least ..

[OOPMan]

@oberstet Indeed. For now I would be happy with Guests that can host more than one component though :-)

[oberstet]

Yeah, I understand. So, in fact, I don't see anything why we couldn't have the Crossbar.io container worker shell implemented also in an aslo flavor and make that available as a new worker subtype: twisted or asyncio. We could do that for container workers in Crossbar.io. Not for router workers. However, Crossbar.io container workers already bring the benefit you are after: ability to run, manage and monitor many components in a single process.

[agronholm]

@OOPMan Do you know about asphalt-wamp? Would that sort of thing work for you?

[OOPMan]

@agronholm Probably in theory but I kinda prefer the organisation features of distinct component classes. As it stands I would have to refactor a large amount of my code and config to use asphalt

[meejah]

Yeah, I think an asyncio container option would be good (that would mean: each component in that container would have to be asyncio-based).

[oberstet]

each component in that container would have to be asyncio-based

yeah, indeed. this feature would NOT allow for containers with mixed components from Twisted and asyncio - either or. And mixed on a per container worker basis, but not within one container worker.

[OOPMan]

That makes sense to me. Mixing Twisted/Asyncio components makes no sense anyway :-)

I guess you could add a type field to the container config with possible values of twisted or asyncio?

[oberstet]

Yeah, some subtype==twisted|asyncio for type=="container", that would indeed be the idea

[oberstet]

No mixed containers, and no router workers (in asyncio flavor) would be the restrictions

[meejah]

I filed crossbario/crossbar#1107 to track the "asyncio container worker" feature.