Hi All,
I want to extend Ryu to query one of our devices using PySNMP. It will then
present a ReST API to a GUI.
I've written my own snmp_rest.py inside ryu/app and added this to the
command-line, e.g:
bin/ryu-manager --ofp-tcp-listen-port 6653 --verbose --observe-links \
ryu/app/ofctl_rest.py \
ryu/app/rest_topology.py \
ryu/app/snmp_rest.py \
--wsapi-port 8091 \
--snmp-host 10.0.116.19
The snmp_rest calls hand off to functions in our own pysnmp_api.py and
these, in turn, make use of PySNMP's synchronous "one-liner" functions,
which have their own dispatch/event loop working to send and receive SNMP
packets until the request is completed.
This is with Ryu version OF1.4 (?) and PySNMP 4.3.2.
Everything seems to work fine. Sort of.
Except, a couple of the SNMP requests take a looooong time.
And while the those requests are running, no other ReST calls are accepted
by the Ryu controller.
To prove this, I copied snmp_rest.py to snmp_rest_2.py, changed all the
names to have a '2' in them (including the ReST "paths"), restarted Ryu
with both snmp_rest.py and snmp_rest_2.py on the command-line.
With some tracing added, I can see that the wsgi server accepts the first
request, passes it to the snmp_rest handler, the handler then uses PySNMP
to start the request and then the wsgi server does *nothing* else until the
SNMP request completes and the results are sent back to the caller. The
wsgi server accepts the second request and sends this off to the
snmp_rest_2 handler ....
2016-08-18 17:44:14.145 INFO ryu.lib.hub (10884) accepted
('10.0.116.151', 40724)
2016-08-18 17:44:14.146 DEBUG ryu.app.snmp_rest get_neighbor_hosts: enter
2016-08-18 17:44:14.147 DEBUG ryu.app.snmp_rest _get_neighbor_hosts:
enter
2016-08-18 17:44:14.147 DEBUG ryu.pysnmp_api get_neighbor_host_list:
enter
2016-08-18 17:44:14.147 DEBUG ryu.pysnmp_api query: enter
2016-08-18 17:44:14.147 DEBUG ryu.pysnmp_api make_query: enter
# notice time gap due to "long" query time ...
2016-08-18 17:44:15.928 DEBUG ryu.pysnmp_api make_query: leave
2016-08-18 17:44:15.979 DEBUG ryu.pysnmp_api query: leave
2016-08-18 17:44:15.979 DEBUG ryu.pysnmp_api get_neighbor_host_list:
leave
2016-08-18 17:44:15.979 DEBUG ryu.app.snmp_rest _get_neighbor_hosts:
leave
2016-08-18 17:44:15.979 DEBUG ryu.app.snmp_rest get_neighbor_hosts: leave
2016-08-18 17:44:15.980 INFO ryu.lib.hub 10.0.116.151 - - [18/Aug/2016
17:44:15] "GET /api/v1.0/neighbor_hosts HTTP/1.1" 200 35883 1.834026
# first query satisfied and *now* the wsgi server finally accepts another
ReST request ...
2016-08-18 17:44:15.980 INFO ryu.lib.hub (10884) accepted
('10.0.116.151', 40726)
2016-08-18 17:44:15.981 DEBUG ryu.app.snmp_rest_2 get_neighbor_hosts:
enter
2016-08-18 17:44:15.981 DEBUG ryu.app.snmp_rest_2 _get_neighbor_hosts:
enter
2016-08-18 17:44:15.981 DEBUG ryu.pysnmp_api get_neighbor_host_list:
enter
2016-08-18 17:44:15.981 DEBUG ryu.pysnmp_api query: enter
2016-08-18 17:44:15.981 DEBUG ryu.pysnmp_api make_query: enter
2016-08-18 17:44:18.013 DEBUG ryu.pysnmp_api make_query: leave
2016-08-18 17:44:18.068 DEBUG ryu.pysnmp_api query: leave
2016-08-18 17:44:18.068 DEBUG ryu.pysnmp_api get_neighbor_host_list:
leave
2016-08-18 17:44:18.069 DEBUG ryu.app.snmp_rest_2 _get_neighbor_hosts:
leave
2016-08-18 17:44:18.069 DEBUG ryu.app.snmp_rest_2 get_neighbor_hosts:
leave
2016-08-18 17:44:18.069 INFO ryu.lib.hub 10.0.116.151 - - [18/Aug/2016
17:44:18] "GET /api/v1.0/neighbor_hosts_2 HTTP/1.1" 200 35883 2.088872
Can anyone please explain what is going on ?
I thought each Ryu "app" got it's own thread ?
I was hoping that this meant that two requests to the same app would cause
the second to block but that a second request to a second app would *not*
block ?
However, it seems that the wsgi server is also restricted to one thread ?
Can anyone please suggest ways around this ?
Can we give the wsgi server more threads ?
Should the snmp_rest app create a new thread to handle the request ?
Has anyone else integrated use of PySNMP (querying other Agents, not acting
as one itself - I've seen the 6-part patches) into Ryu ?
Any suggestions gratefully received !
Graham.
--
*Graham Hudspith Zeetta Networks Limited*Software Engineer Engine
Shed, Station Approach,
gra...@zeetta.com Temple Meads,
Bristol,
BS1 6QH
United Kingdom
zeetta.com <http://www.zeetta.com/>
------------------------------------------------------------------------------
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
