seifert / ipcqueue Goto Github PK

Hi,

We're getting the QueueError "no system resources" error meaning the mqueue does not exist. We implemented a 12FA retry loop, and ended up running out of filehandles. Checking via /proc/PID/fd on Linux shows these filehandles are to blame:

lrwx------ 1 root root 64 Aug 4 23:47 994 -> /BarToFoo
lrwx------ 1 root root 64 Aug 4 23:47 995 -> /FooToBar
lrwx------ 1 root root 64 Aug 4 23:47 996 -> /BarToFoo
lrwx------ 1 root root 64 Aug 4 23:47 997 -> /FooToBar
lrwx------ 1 root root 64 Aug 4 23:47 998 -> /BarToFoo
lrwx------ 1 root root 64 Aug 4 23:47 999 -> /FooToBar

Between retries, we're not saving objects with the handles in them anywhere that would prevent the gc from releasing them. They're being created via posixmq.Queue("/FooToBar", serializer=...) and saved only as a private attribute of a class, ~2-4 functions calls deep from the exception handler that implements the retry loop. I wouldn't say I'm 100% certain but I know from having maintained a similar module that leaks are 99% of the maintenance of a dynamic language to C library binding module. Platform is linux/arm64hf.

Thanks for writing ipcqueue!

This error message is highly confusing when dealing with two services communicating over posixmq. As IPC message queues have various tunables for things like the queue size, message size, and there as global system limits that specify the maximum amount of memory that may be allocated to posixmq at any one time, you might end up thinking you got it wrong and keep increasing the queue size or system limits. However the problem is simply that the other process is not running, or has a typo in their MQ name or something. And then this is bad because too much buffering in general can lead to processing delays and lag in your "realtime" channel, especially with python as a consumer

For the specific case where the mqueue does not exist, the error should be closer to "No such file or directory" or "Message Queue has not been created" (for read-only queues)

It'd be useful to be able to register a Python callback for when new messages are received either using a signal or a thread.