ska-sa / aiokatcp Goto Github PK

The type registration system currently only uses __mro__, which means it doesn't work with ABCs like numbers.Integral. In Python 3, types like numpy.int64 don't inherit from int, so they currently crash if set as sensor values or otherwise used in katcp messages.

One approach is to change the type registration system to work with isinstance and to register ABCs instead of concrete classes. That needs some investigation because mypy doesn't work well with the numbers ABCs.

An alternative is to modify the sensor class to cast value updates to the sensor's registered type. That would fix the problem of setting a sensor to a numpy integer (but with the side effect that reading back the value gives you a different type of object from what you set), but wouldn't help for other messages.

When the server sends informs to a client that is disconnected, it causes a log message of

socket.send() raised exception

to be repeated each time. For example, run this server, connect a client and issue ?sensor-sampling ticks event, then kill the client.

#!/usr/bin/env python3
import asyncio
import logging

import aiokatcp


class Server(aiokatcp.DeviceServer):
    VERSION = 'test-1.0'
    BUILD_STATE = 'test-1.0.0'

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.sensor = aiokatcp.Sensor(int, 'ticks', 'stuff')
        self.sensors.add(self.sensor)


async def main():
    server = Server('localhost', 4444)
    await server.start()
    while True:
        await asyncio.sleep(0.1)
        server.sensor.value += 1

if __name__ == '__main__':
    logging.basicConfig()
    logging.warning('Startup!')
    loop = asyncio.get_event_loop()
    loop.run_until_complete(main())
    loop.close()

It is most likely related to python/asyncio#301, although not caused by it (since that bug was fixed in 3.5.1). In particular, it may be necessary to change the API for out-of-band informs to use coroutines so that the queue can be drained.

If a client connects and immediately disconnects, it can cause this exception trace, which should be handled a bit more gracefully:

Exception in connection handler [192.168.6.62:39646]
Traceback (most recent call last):

  File "/home/kat/ve3/lib/python3.5/site-packages/aiokatcp/connection.py", line 200, in _done_callback
    task.result()

  File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result
    raise self._exception

  File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step
    result = coro.throw(exc)

  File "/home/kat/ve3/lib/python3.5/site-packages/aiokatcp/connection.py", line 183, in _run
    msg = await read_message(self.reader)

  File "/home/kat/ve3/lib/python3.5/site-packages/aiokatcp/connection.py", line 94, in read_message
    raw = await stream.readuntil()

  File "/usr/lib/python3.5/asyncio/streams.py", line 574, in readuntil
    yield from self._wait_for_data('readuntil')

  File "/usr/lib/python3.5/asyncio/streams.py", line 457, in _wait_for_data
    yield from self._waiter

  File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__
    yield self  # This tells Task to wait for completion.

  File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup
    future.result()

  File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result
    raise self._exception

  File "/usr/lib/python3.5/asyncio/selector_events.py", line 662, in _read_ready
    data = self._sock.recv(self.max_size)

ConnectionResetError: [Errno 104] Connection reset by peer

I've enabled Python 3.7 in Travis and can't currently make the tests pass. There is some difference in how issubclass behaves that is breaking the type registration system.