)]}'
{"oslo/messaging/_drivers/amqpdriver.py":[{"author":{"_account_id":6159,"name":"Flavio Percoco Premoli","display_name":"flaper87","email":"flavio.percoco@flyrlabs.com","username":"flaper87"},"change_message_id":"0549b449a9d44ebdcc813c2613e95c1cd1b624fa","unresolved":false,"context_lines":[{"line_number":122,"context_line":""},{"line_number":123,"context_line":"    def cleanup(self):"},{"line_number":124,"context_line":"        # Closes listener connection"},{"line_number":125,"context_line":"        if self.conn is not None:"},{"line_number":126,"context_line":"            self.conn.close()"},{"line_number":127,"context_line":""},{"line_number":128,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"baada198_62bc4a07","line":125,"updated":"2014-07-03 14:12:45.000000000","message":"Why do you need to check for nulless here? When can this conn be None?","commit_id":"ceeac8728ac1af48523970befec1e91296f47ecd"},{"author":{"_account_id":2813,"name":"Mehdi Abaakouk","email":"sileht@sileht.net","username":"sileht"},"change_message_id":"333ad11d3462a74226276da96a55ec17efe98f2e","unresolved":false,"context_lines":[{"line_number":412,"context_line":"        conn \u003d self._get_connection(pooled\u003dFalse)"},{"line_number":413,"context_line":""},{"line_number":414,"context_line":"        listener \u003d AMQPListener(self, conn)"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"        # passing listener object as a weakref proxy to connection"},{"line_number":417,"context_line":"        # so that it will be garbage collected after stopping"},{"line_number":418,"context_line":"        # messaging server"}],"source_content_type":"text/x-python","patch_set":6,"id":"1abeadc6_26cfd2b1","line":415,"updated":"2014-08-20 08:33:14.000000000","message":"I prefer to have a explicit connection close when the listener need to be deleted.\n\nI think we cannot rely on the garbage collector for this, we can\u0027t know in advance when the connection will be closed with the garbage collector. \n\nAnd if not closing the connection results to a message lost, we continue to have the issue if the garbage collector deletes the connection too late.","commit_id":"6c4d8d0fd6aed558ab2409a5418525a43ebb9453"},{"author":{"_account_id":7763,"name":"Alexei Kornienko","email":"akornienko@mirantis.com","username":"akornienko"},"change_message_id":"076b099325983393e36b34d552c7026c185d894b","unresolved":false,"context_lines":[{"line_number":412,"context_line":"        conn \u003d self._get_connection(pooled\u003dFalse)"},{"line_number":413,"context_line":""},{"line_number":414,"context_line":"        listener \u003d AMQPListener(self, conn)"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"        # passing listener object as a weakref proxy to connection"},{"line_number":417,"context_line":"        # so that it will be garbage collected after stopping"},{"line_number":418,"context_line":"        # messaging server"}],"source_content_type":"text/x-python","patch_set":6,"id":"1abeadc6_905e1711","line":415,"in_reply_to":"1abeadc6_26cfd2b1","updated":"2014-08-20 10:05:36.000000000","message":"1) I don\u0027t like the idea of explicit connection close because it means that we can have \"broken\" objects at runtime. My POV is that if object exists it should be in \"working\" state. Lets assume that we have 2 users of the driver. 1 explicitly closes the connnection so the 2nd one will be broken and would have to deal with this somehow.\n\n2) IMHO it normal to rely on GC. Connection will be kept alive while there are users of the driver object. If we\u0027ll keep driver internals as an acyclic graph (by using weakrefs) driver will be garbage collected right after last reference on it will be released by end-user application. In cpython it will be deleted by reference counted GC that happens immediately when object goes out of scope.\n\n3) Mehdi could you please explain this part a little bit? How not closing the connection could result in message loss?","commit_id":"6c4d8d0fd6aed558ab2409a5418525a43ebb9453"},{"author":{"_account_id":7763,"name":"Alexei Kornienko","email":"akornienko@mirantis.com","username":"akornienko"},"change_message_id":"eec08329edbc316cdc8a668e98db5318b4cf378c","unresolved":false,"context_lines":[{"line_number":412,"context_line":"        conn \u003d self._get_connection(pooled\u003dFalse)"},{"line_number":413,"context_line":""},{"line_number":414,"context_line":"        listener \u003d AMQPListener(self, conn)"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"        # passing listener object as a weakref proxy to connection"},{"line_number":417,"context_line":"        # so that it will be garbage collected after stopping"},{"line_number":418,"context_line":"        # messaging server"}],"source_content_type":"text/x-python","patch_set":6,"id":"1abeadc6_d035eff7","line":415,"in_reply_to":"1abeadc6_70a09b9f","updated":"2014-08-20 10:29:41.000000000","message":"!!Please note that my answer is mostly about rabbitmq I don\u0027t know qpid well enough so it may be wrong in qpid case.\n\n1) if listener object is garbage collected it\u0027s connection is also released and closed. In 99% of cases it\u0027s enough to cancel the consumers (1% is the problem that message broker will need some time to redeliver messages that was already delivered to this connection (see #3)).\n\n3) Bug report says \"Because of this messages are not processed properly.\" \n\nI think it may be because of the fact that we don\u0027t set pre-fetch count properly. \n\nWhat happens is that when a consumer is declared message broker sends *lots* of messages to the consumer e.g if a queue had 8000 messages they all will be delivered at once. Later this messages will stay in delivered/unacked state until consumer will be able to deal with them. Broker will only redeliver unacked messages when connection is closed (from what I know there is no separate timeout for this from broker side). This may lead to situation that while connection is open in the process we have messages that are \"lost in the pipe\" since broker thinks that they are delivered but we have not processed them and open connection prevents them from redelivering.\n\nI think that situation with missing pre-fetch settings should be fixed by a separate patch.","commit_id":"6c4d8d0fd6aed558ab2409a5418525a43ebb9453"},{"author":{"_account_id":12487,"name":"vigneshvar","email":"vigneshvar.a.s@gmail.com","username":"vigneshvar"},"change_message_id":"5c90a72d6dd6b83b7a999c007e3e5454997270d4","unresolved":false,"context_lines":[{"line_number":412,"context_line":"        conn \u003d self._get_connection(pooled\u003dFalse)"},{"line_number":413,"context_line":""},{"line_number":414,"context_line":"        listener \u003d AMQPListener(self, conn)"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"        # passing listener object as a weakref proxy to connection"},{"line_number":417,"context_line":"        # so that it will be garbage collected after stopping"},{"line_number":418,"context_line":"        # messaging server"}],"source_content_type":"text/x-python","patch_set":6,"id":"fa98f980_14456d42","line":415,"in_reply_to":"1abeadc6_905e1711","updated":"2014-09-12 07:32:50.000000000","message":"1) Just curious, this could be a dumb question, is there a real time scenario in openstack where the listeners are being shared (two users of the driver) and the service needs to restarted.","commit_id":"6c4d8d0fd6aed558ab2409a5418525a43ebb9453"},{"author":{"_account_id":2813,"name":"Mehdi Abaakouk","email":"sileht@sileht.net","username":"sileht"},"change_message_id":"38b9df9f318a8972d914074e53e2fc4e910b4dc4","unresolved":false,"context_lines":[{"line_number":412,"context_line":"        conn \u003d self._get_connection(pooled\u003dFalse)"},{"line_number":413,"context_line":""},{"line_number":414,"context_line":"        listener \u003d AMQPListener(self, conn)"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"        # passing listener object as a weakref proxy to connection"},{"line_number":417,"context_line":"        # so that it will be garbage collected after stopping"},{"line_number":418,"context_line":"        # messaging server"}],"source_content_type":"text/x-python","patch_set":6,"id":"1abeadc6_70a09b9f","line":415,"in_reply_to":"1abeadc6_905e1711","updated":"2014-08-20 10:18:51.000000000","message":"About 1), yes closing the connection is this case seems a bad idea, I think the listener must release their resources on the connection, perhaps having something that do the reverse of declare.*consumer method. And then the connection can be cleanly garbage collected if it have no more consumer.\n\nAbout 3), This is what the bug report says, I have not tried to figure out.","commit_id":"6c4d8d0fd6aed558ab2409a5418525a43ebb9453"},{"author":{"_account_id":1011,"name":"Tushar Patil","email":"tushar.vitthal.patil@gmail.com","username":"tpatil"},"change_message_id":"430b76ac8ccda731229156a611ec71882c2e0f1d","unresolved":false,"context_lines":[{"line_number":412,"context_line":"        conn \u003d self._get_connection(pooled\u003dFalse)"},{"line_number":413,"context_line":""},{"line_number":414,"context_line":"        listener \u003d AMQPListener(self, conn)"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"        # passing listener object as a weakref proxy to connection"},{"line_number":417,"context_line":"        # so that it will be garbage collected after stopping"},{"line_number":418,"context_line":"        # messaging server"}],"source_content_type":"text/x-python","patch_set":6,"id":"1abeadc6_4700d501","line":415,"in_reply_to":"1abeadc6_a73bb6cf","updated":"2014-08-23 03:05:30.000000000","message":"In my observation, there is no need to call gc.collect if there is more enough memory available on the machine running the unit tests.\n\nSimilar issue was seen in neutron unit tests reported in this bug.\nhttps://bugs.launchpad.net/neutron/+bug/1234857","commit_id":"6c4d8d0fd6aed558ab2409a5418525a43ebb9453"},{"author":{"_account_id":1011,"name":"Tushar Patil","email":"tushar.vitthal.patil@gmail.com","username":"tpatil"},"change_message_id":"fce91fdb9ea329cff991338eeedbff13d4f43e2e","unresolved":false,"context_lines":[{"line_number":412,"context_line":"        conn \u003d self._get_connection(pooled\u003dFalse)"},{"line_number":413,"context_line":""},{"line_number":414,"context_line":"        listener \u003d AMQPListener(self, conn)"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"        # passing listener object as a weakref proxy to connection"},{"line_number":417,"context_line":"        # so that it will be garbage collected after stopping"},{"line_number":418,"context_line":"        # messaging server"}],"source_content_type":"text/x-python","patch_set":6,"id":"1abeadc6_b6913949","line":415,"in_reply_to":"1abeadc6_d035eff7","updated":"2014-08-20 18:49:54.000000000","message":"About 3) I completely agree to what you have said.\nWe have tried sending SIGHUP signal to the nova-compute service 1-500 times (internally it stops the RPC server) and have verified the connection closes every time and the messages are always processed.\nTested using rabbitMQ.","commit_id":"6c4d8d0fd6aed558ab2409a5418525a43ebb9453"},{"author":{"_account_id":2813,"name":"Mehdi Abaakouk","email":"sileht@sileht.net","username":"sileht"},"change_message_id":"9baeb1fc87409a56e022edce253490cf619aedcb","unresolved":false,"context_lines":[{"line_number":412,"context_line":"        conn \u003d self._get_connection(pooled\u003dFalse)"},{"line_number":413,"context_line":""},{"line_number":414,"context_line":"        listener \u003d AMQPListener(self, conn)"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":"        # passing listener object as a weakref proxy to connection"},{"line_number":417,"context_line":"        # so that it will be garbage collected after stopping"},{"line_number":418,"context_line":"        # messaging server"}],"source_content_type":"text/x-python","patch_set":6,"id":"1abeadc6_a73bb6cf","line":415,"in_reply_to":"1abeadc6_d035eff7","updated":"2014-08-21 06:12:52.000000000","message":"Yeah message ack but not processed is an other problem\n\nSo, if we use weakref, I need to figure out why the test need to be garbage collected manually in teardrop","commit_id":"6c4d8d0fd6aed558ab2409a5418525a43ebb9453"}],"oslo/messaging/server.py":[{"author":{"_account_id":6159,"name":"Flavio Percoco Premoli","display_name":"flaper87","email":"flavio.percoco@flyrlabs.com","username":"flaper87"},"change_message_id":"0549b449a9d44ebdcc813c2613e95c1cd1b624fa","unresolved":false,"context_lines":[{"line_number":142,"context_line":"            self._executor.wait()"},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"        # Close listener connection after processing all messages"},{"line_number":145,"context_line":"        if self._listener is not None:"},{"line_number":146,"context_line":"            self._listener.cleanup()"},{"line_number":147,"context_line":"            self._listener \u003d None"},{"line_number":148,"context_line":""}],"source_content_type":"text/x-python","patch_set":2,"id":"baada198_771b2aca","line":145,"updated":"2014-07-03 14:12:45.000000000","message":"In theory you could also do:\n\n  self._executor.listener.cleanup()","commit_id":"ceeac8728ac1af48523970befec1e91296f47ecd"},{"author":{"_account_id":7536,"name":"Ilya Pekelny","email":"ipekelny@mirantis.com","username":"I159"},"change_message_id":"f264f9d92168d5e421ed7529939f48a6ef26d6d3","unresolved":false,"context_lines":[{"line_number":141,"context_line":"        if self._executor is not None:"},{"line_number":142,"context_line":"            self._executor.wait()"},{"line_number":143,"context_line":"            # Close listener connection after processing all messages"},{"line_number":144,"context_line":"            self._executor.listener.cleanup()"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"        self._executor \u003d None"}],"source_content_type":"text/x-python","patch_set":7,"id":"da9df570_46a3d4b1","line":144,"updated":"2014-09-26 09:40:13.000000000","message":"Should we close listener inside of `wait` method? And why if we do? This method seems to me like just a waiter.","commit_id":"f37800943e18edfa4754164772572b4caef18152"},{"author":{"_account_id":7536,"name":"Ilya Pekelny","email":"ipekelny@mirantis.com","username":"I159"},"change_message_id":"7deab72c4fef641f189723385c969febf13d8026","unresolved":false,"context_lines":[{"line_number":141,"context_line":"        if self._executor is not None:"},{"line_number":142,"context_line":"            self._executor.wait()"},{"line_number":143,"context_line":"            # Close listener connection after processing all messages"},{"line_number":144,"context_line":"            self._executor.listener.cleanup()"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"        self._executor \u003d None"}],"source_content_type":"text/x-python","patch_set":7,"id":"da9df570_bc664ceb","line":144,"in_reply_to":"da9df570_11fae842","updated":"2014-09-26 13:55:17.000000000","message":"Thank you for description!","commit_id":"f37800943e18edfa4754164772572b4caef18152"},{"author":{"_account_id":12487,"name":"vigneshvar","email":"vigneshvar.a.s@gmail.com","username":"vigneshvar"},"change_message_id":"b8869b84864cf46d4565045ff759bd5cd551256c","unresolved":false,"context_lines":[{"line_number":141,"context_line":"        if self._executor is not None:"},{"line_number":142,"context_line":"            self._executor.wait()"},{"line_number":143,"context_line":"            # Close listener connection after processing all messages"},{"line_number":144,"context_line":"            self._executor.listener.cleanup()"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"        self._executor \u003d None"}],"source_content_type":"text/x-python","patch_set":7,"id":"da9df570_710c14ee","line":144,"in_reply_to":"da9df570_46a3d4b1","updated":"2014-09-26 09:53:33.000000000","message":"I guess the wait method waits until all the messages are processed and then clears the executers (self._executor \u003d None). Since it makes sure that everything is clean. I think closing the listener seems perfect on wait method. Any suggestions ?","commit_id":"f37800943e18edfa4754164772572b4caef18152"},{"author":{"_account_id":8300,"name":"Abhijeet Malawade","email":"abhijeet.malawade@gmail.com","username":"abhijeet"},"change_message_id":"8a88b34d6d57dbc6d92d0a7be7071c950fa37021","unresolved":false,"context_lines":[{"line_number":141,"context_line":"        if self._executor is not None:"},{"line_number":142,"context_line":"            self._executor.wait()"},{"line_number":143,"context_line":"            # Close listener connection after processing all messages"},{"line_number":144,"context_line":"            self._executor.listener.cleanup()"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"        self._executor \u003d None"}],"source_content_type":"text/x-python","patch_set":7,"id":"da9df570_11fae842","line":144,"in_reply_to":"da9df570_710c14ee","updated":"2014-09-26 10:43:30.000000000","message":"I am closing listeners inside wait method because it\nis setting self._executor to None after processing all messages. So we will not be able to close listeners (self._executor.listener) outside of wait method.","commit_id":"f37800943e18edfa4754164772572b4caef18152"}]}