`cls.instance_map` was growing unbounded. This was because
`io_loop.close()` was invoked before `stream.close()`. The stategy used
to fix this issue was discussed in pull request #28530 and can be
summarized as follows:
The `close()` method on the async object will be called if it exists.
This will be called before the `io_loop.close()` to give the async object
the opportunity to close its stream. The del of the async object will
continue to happen after io_loop.close(). This is to maintain the fix
from pull request #27343.
Per file change details:
salt/utils/async.py:
- Implemented the close logic described above.
salt/transport/ipc.py:
- Ensured that `close()` may be invoked more than once safely.
- In IPCServer, `self.stream` was never actually used. Removed
references to it to avoid confusion.
salt/transport/zeromq.py:
- Ensured that `close()` may be invoked more than once safely.
salt/transport/tcp.py:
- Ensured that `close()` may be invoked more than once safely.
- Changed `destroy()` methods to `close()` methods since they involved
a stream that should be closed before `io_loop.close()`.
- In SaltMessageClient, added more checks for `self._closing`. This
makes exit cleaner by not attempting to reconnect while closing.
- Removed the code associate with pull request #28113. This code is
no longer needed now that the stream is closed before the io_loop.
Signed-off-by: Sergey Kizunov <sergey.kizunov@ni.com>
So, this is an unusual problem. The issue was the with the introduction of an ordereredict representer to the yaml renderer inside the grains module, it was staying bound even outside of that module. This ends up breaking some types of rendering for anything that calls either safe_load or safe_dump after the ordereddict representer was attached.
I experimented a bunch with trying to centralize this inside the salt.serializers.yaml class. At the end of the day, it ended up adding a bunch of overhead and tracking to that module and made it fairly dirty just to handle a one-off case. If this becomes a problem in the future, I feel like we can revisit it then.
I also experimented with trying to create special yaml subclasses with yaml serialization hints inside them. While this worked fine for serialization, it's not supported in the pyyaml safe deserialization methods and so that approach was abandoned.
This should fix the failing serializer tests in 2015.8 and develop.
This way we have a consistent return method that some interal callers (fileclient) who don't care about the decoding of the message can just use.
Fixes#28477
