I was running QPID 10 with the patches from QPID-3333 (see https://issues.apache.org/jira/browse/QPID-3333 ) and noticed there appeared to be a memory leak.
>>> import cqpid >>> import gc >>> inContent=["a", "b"] >>> msg=cqpid.Message(inContent) >>> outContent=msg.content >>> id(inContent)==id(outContent) False >>> len(gc.get_objects()) 7938 >>> for i in xrange(10000): outContent=msg.content; ... >>> len(gc.get_objects()) 17932 Every time we point outContent to a new msg.content, the object it had been pointing at should have a reference count of zero, and be available for garbage collection, however it looks like our reference counting is off so these objects end up never getting deleted. The same is also true of messages that contain maps. I know of no issue if the message does not contain a list or a map (I also believe empty lists and maps are not affected by this). It looks like the change to qpid::messaging::Message:_get_content in 0013-Handle-amqp-list-and-amqp-map-content.patch that lets msg.content return a list or map is what is letting us see the problem, although the actual cause is a deeper issue with reference counting. Anthony (the original developer behind QPID-3333) put together a patch to modify the way references are incremented which I am attaching, although it is not well tested and it appears the memory increase still exists with it, so works still needs to be done. Since getting maps or lists out of messages was not particularly important, we simply circumvented this issue by editing qpid::messaging::Message:_get_content to not call decodeList or decodeMap, but the general map/list reference counting issue probably warrants some further looking into. Eric Harris Analyst Princeton Consultants, Inc. 2 Research Way Princeton, NJ 08540 609.987.8787 ext. 415 ehar...@princeton.com
--------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:users-subscr...@qpid.apache.org