You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
asyncio.queues.QueueFull Error after X hours of running. #83
Error message recieved after running without issue for 17hrs or so.
2024-10-26 15:17:37,904 pytak INFO - Complete: <Task finished name='Task-3' coro=<RXWorker.run() done, defined at C:\Users\Administrator\AppData\Local\Programs\Python\Python313-32\Lib\site-packages\pytak\classes.py:236> exception=QueueFull()>
ERROR:asyncio:Task exception was never retrieved
future: <Task finished name='Task-3' coro=<RXWorker.run() done, defined at C:\Users\Administrator\AppData\Local\Programs\Python\Python313-32\Lib\site-packages\pytak\classes.py:236> exception=QueueFull()>
Traceback (most recent call last):
File "C:\Users\Administrator\AppData\Local\Programs\Python\Python313-32\Lib\site-packages\pytak\classes.py", line 246, in run
self.queue.put_nowait(data)
~~~~~~~~~~~~~~~~~~~~~^^^^^^
File "C:\Users\Administrator\AppData\Local\Programs\Python\Python313-32\Lib\asyncio\queues.py", line 166, in put_nowait
raise QueueFull
asyncio.queues.QueueFull
C:\adsbcot>
dump1090.exe still running.
TAK-server still running.
Results in CoTs no longer being sent to server.
A restart of the program enabled flow again adsbcot -c adsbcot.ini.
adsbcot is expected to exit when it encounters these types of errors. You should run it as a daemon with a process management tool like systemd, supervisord, et al. I know Windows has a process manager for these types of things, but I'm not familiar enough with it to offer advice on setup.
It seems like your queue has just filled. Best option would be to build a queue supervisor to manage the corrupt/full queues when max error is reached. Asyncio is not designed to be a message broker. To handle complexities in brokerage like architecture asyncio needs supervisor and queue sharding techniques to overcome slow server response. When lag is introduced one side of the client server needs to handle that lag. Either client or server should reduce load at one end or both to optimize. Technologies like Apache Kafka have design for handling lag. Asyncio would need to be extended to compete.
Hi, I believe this issue may still be present. It was reported as fixed in PyTAK v7.3.9, but I am still seeing the same queue full / TX worker stall behavior in both v7.3.12 and v7.6.1.
The application keeps running, but the queue fills and COT output stops until PyTAK/ADSBCOT is restarted.
Has anyone found a workaround or confirmed whether this issue is fully resolved in the newer versions?
Activity
ampledata commentedon Jan 3, 2025
adsbcot is expected to exit when it encounters these types of errors. You should run it as a daemon with a process management tool like systemd, supervisord, et al. I know Windows has a process manager for these types of things, but I'm not familiar enough with it to offer advice on setup.
Zuilf456WQ commentedon Aug 29, 2025
Had the same issue, event when increasing the queue size in the file config. Any idea what cause that?
jkaniuka commentedon Feb 23, 2026
I also had this issue, increasing
MAX_IN_QUEUE/MAX_OUT_QUEUEsize did not help 😕Topher33 commentedon Mar 9, 2026
It seems like your queue has just filled. Best option would be to build a queue supervisor to manage the corrupt/full queues when max error is reached. Asyncio is not designed to be a message broker. To handle complexities in brokerage like architecture asyncio needs supervisor and queue sharding techniques to overcome slow server response. When lag is introduced one side of the client server needs to handle that lag. Either client or server should reduce load at one end or both to optimize. Technologies like Apache Kafka have design for handling lag. Asyncio would need to be extended to compete.
kd2var commentedon Sep 10, 2026
Hi, I believe this issue may still be present. It was reported as fixed in PyTAK v7.3.9, but I am still seeing the same queue full / TX worker stall behavior in both v7.3.12 and v7.6.1.
The application keeps running, but the queue fills and COT output stops until PyTAK/ADSBCOT is restarted.
Has anyone found a workaround or confirmed whether this issue is fully resolved in the newer versions?