Hi Iwase,
Thanks for you fast reply.
We didn't tried out "eventlet.green.zmq" upfront, but for now we are not
able to get it working.
Do you have a basic example that successfully uses the
"eventlet.green.zmg'?
Besides the "eventlet.green.zmq" suggestion, do you happen to have any
other good direction that we might be able to apply?
Best regards,
Tom
2017-06-07 3:43 GMT+02:00 Iwase Yusuke <iwase.yusu...@gmail.com>:
> Hi Tom,
>
>
> On 2017年06月06日 20:54, Tom De Schepper wrote:
> > Hi all,
> >
> > Some colleagues and I are interested in using the Ryu controller
> together with a program of our own to control and monitor network
> components. To this extend, it is necessary to set up some form of
> communication between the programs. For that, we want to use the ZeroMQ
> framework (http://zguide.zeromq.org/page:all) that allows you to set up
> sockets between different components and handles the sending and receiving
> of messages. The idea is to make our own app at the Ryu side that listens
> and transmits messages to ZMQ and handles interaction with virtual switches
> in the network. However, we ran into issues when implementing the
> communication part in our Ryu app.
> >
> > We managed to made the app transmit messages by spawning a new hub with
> a function that contains a while loop and every second will transmit
> something. This works fine. However, the other way around won’t work. Upon
> initialization of the ZeroMQ communication elements (in the constructor of
> our app) all functionality blocks. In other words, opening the
> communication socket causes blocking of all other hubs/processes within
> Ryu. We have tried, without success, solving this in different manners, by
> using different communication models (e.g., pub-sub), threads, the Ryu hub
> class, the multiprocessing framework of Python, etc. .
> >
> > We have no idea what causes this blocking behavior and were wondering if
> somebody within the community would have an idea. We checked out the
> implementation of the Ryu hub class and noticed that it uses underneath
> eventlets/greenlets, but are not sure if the interaction with that might
> cause the problem.
>
> As you said, this problem seems to be caused by the compatibility between
> ZeroMQ and eventlet.
> GreenThread of eventlet is unexpectedly blocked if the native thread on
> which GreenThread working.
>
> Fist, have you tried "eventlet.green.zmq"?
> This module provides "greenthread aware version of pyzmq".
> http://eventlet.net/doc/modules/zmq.html
>
> If it does not work well, you need to spawn the native thread for ZeroMQ
> socket, I guess,
> but it might be difficult...
>
> Thanks,
> Iwase
>
>
> >
> > We would appreciate any comments or feedback.
> >
> > Thanks in advance and best regards!
> > Tom
> >
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> >
> >
> > _______________________________________________
> > Ryu-devel mailing list
> > Ryu-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/ryu-devel
> >
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
