Hello everybody, the following points are relevant to the ZMQ Java binding only. I don't know if there is a more specific mailing list so I am posting here...
I use the library for a mobile application where allocation/deallocation counts ... well for every byte. I noticed so far 2 main leaks related to the closing of Java pipes. One is very recent, the other one ... not so much. While pretty new into this project, I would like to discuss these before filling an issue or proposing a patch. 1) a very recent commit (related to issue #200) in Ctx.destroySocket() removed the call to Socket.close(). As far as I can see, this inhibits closing the sockets in the cycle: ZContext.createSocket() <do your work> ZContext.destroySocket() ZContext.close(), leading to a "Too Many Opened Files" exception quite fast. Right now I reverted the commit locally and everything works, It seems that there is an attempt to get closer to the more usual closing paradigm of Java, so before any of my move, I would be interested if somebody could provide me some input about that. 2) the second leak is related to the zmq package, while using one of the ZMQ.poll() method. The closing of the Selector is done in one finalize method, which is not a guarantee of calling and adds penalty performance on creation and destruction. I have a stress test and may have a patch that would allow the poll selector to be automatically closed without modifying user code in one condition: that the context is closed in the same thread where is called the zmq.ZMQ.poll(...) method. If not, users would be forced to call an extra method in this thread. That is so far the best solution I found ... But this raises the question of lib compatibility. To which I know nothing. What are your thoughts about this? Frederic PS: please forgive my mispellings and language mistakes, I am not english native.
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
