salt/master.py:
- If ZMQ is not importable, use `tornado.ioloop.IOLoop` as the loop class.
- Check HAS_ZMQ before using any zmq.* content.
- Did not touch `FloMWorker` usage of zmq.*. This is only used when the
transport is RAET.
salt/minion.py:
- If ZMQ is not importable, use `tornado.ioloop.IOLoop` as the loop class.
- Check HAS_ZMQ before using any zmq.* content.
salt/transport/ipc.py:
- Added `IPCMessagePublisher`. This is intended to function much like
ZMQ's zmq.PUB sockets. Used in implementing utils/event.py to function
without ZMQ.
- Added `IPCMessageSubscriber`. This is intended to function much like
ZMQ's zmq.SUB sockets. Used in implementing utils/event.py to function
without ZMQ. What makes this class a bit different is that the associated
IO Loop is meant to not be running when it is used. Due to this, it is
recommended that the caller create a new IO Loop for this purpose. The
reason for this is that the `get_event()` API may be invoked from
anywhere, whether or not there is a current IO Loop that is running in
the thread of the invocation.
salt/utils/async.py:
- If ZMQ is not importable, use `tornado.ioloop.IOLoop` as the loop class.
salt/utils/event.py:
- Implemented using `salt.transport.ipc` instead of ZMQ.
- zmq.PUB ==> `IPCMessagePublisher`
- zmq.SUB ==> `IPCMessageSubscriber`
- zmq.PUSH ==> `IPCMessageClient`
- zmq.PULL ==> `IPCMessageServer`
Signed-off-by: Sergey Kizunov <sergey.kizunov@ni.com>
There was a problem wherein two sockets would race to see which was connected first,
causing unit.utils.event_test.TestSaltEvent.test_event_multiple_clients to fail from
time to time. This gives a little breathing room to the second socket.
This also only does the pub connect if necessary on SaltEvent instantation.
Require all multitasking contexts to subscribe to their events so one call to get_event for one tag does not discard events that should be saved for a subsequent call to get_event with another tag.
Use blocking get_event in batching with very small timeout.
Fixes#25998
Once subscribed to publisher SUB socket gets collecting all incoming
messages that is unwanted behavior for fire-only events.
Fixed by using listen=<True|False> constructor argument.
pyzmq 13.0.x was the first version to support *any* tornado in pyzmq, and since 14.0.x they have changed the API (IMO into a more sensible one). This conditionally changes the name to match the new API's naming
Before the fix in #18363 get_event would return None on the first non-matching event (since wait was 0), this is to verify that get_event works properly with a wait of 0
PendingEventsBase implements all the pending_events queue management
Make both normal SaltEvent and raetevent.SaltEvent inherit from this to
standardise the get_event interface.
Update tests for event.SaltEvent (Couldn't find tests for
raetevent.SaltEvent)
On Fedora 20, we hit an issue, at least, similar to #3618.
While debugging it, I've found that the runtests process keeps eating
memory.
Using `clean_proc` has at least, allowed the runtests to finish without
triggering #3618.
The previous default was not dropping unrelated event, however, this
could cause memory leaks, so, the current default is dropping those
events.
We now test for both behaviours.
