)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"change_message_id":"39d5553d58cdeafb092dbe0bf7ed23dc3716c019","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"e88073fc_dfedfded","updated":"2026-04-22 13:27:09.000000000","message":"After further testing, I\u0027m not sure if this fix is good as-is; it seems like it may cause a performance regression on parallel vif port binding, still investigating.","commit_id":"1785b3c2ede6de72f5369b3b26d20182a61a6ed6"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"8315897385aff2c35fc085c55e3f28c5fdcdc8b1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"c9b19ecd_c34d4928","updated":"2026-05-13 07:18:51.000000000","message":"We would need explicit testing of this feature, something similar to that was done in https://review.opendev.org/c/openstack/neutron/+/985722/3/neutron/tests/unit/plugins/ml2/drivers/ovn/mech_driver/ovsdb/test_maintenance.py","commit_id":"1785b3c2ede6de72f5369b3b26d20182a61a6ed6"},{"author":{"_account_id":10273,"name":"Adam Harwell","email":"flux.adam@gmail.com","username":"rm_you"},"change_message_id":"21ed8db0c2e9568e7787ad2a2ef9a2b766e155ef","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"8eed9fd6_e484e528","updated":"2026-04-22 08:28:32.000000000","message":"ok so, I found this bug in the process of searching for what was exploding my thread count, and while I believe the bug is real, it is very much not the actual root cause. I don’t think this one is very easy to hit… the other one is the important one, but we can merge this too if you’d like to just shore stuff up I believe.","commit_id":"1785b3c2ede6de72f5369b3b26d20182a61a6ed6"}],"neutron/notifiers/batch_notifier.py":[{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"8315897385aff2c35fc085c55e3f28c5fdcdc8b1","unresolved":true,"context_lines":[{"line_number":22,"context_line":"        self.callback \u003d callback"},{"line_number":23,"context_line":"        self.batch_interval \u003d batch_interval"},{"line_number":24,"context_line":"        self._mutex \u003d threading.Lock()"},{"line_number":25,"context_line":"        self._executor \u003d concurrent.futures.ThreadPoolExecutor(max_workers\u003d1)"},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"    def queue_event(self, event):"},{"line_number":28,"context_line":"        \"\"\"Called to queue sending an event with the next batch of events."}],"source_content_type":"text/x-python","patch_set":1,"id":"c011ead3_01129382","line":25,"range":{"start_line":25,"start_character":63,"end_line":25,"end_character":76},"updated":"2026-05-13 07:18:51.000000000","message":"This could be a problem due when used in the L3 agent or the Placement API.\n\nThe L3 agent has a pool executor of up to 32 threads [1].\n\nIn the Neutron API, we mainly use it for the Placement API, to push the notification events.\n\nAlthough we should indeed limit the number of threads to be spawned, we should have a bigger limit here. For the Placement API I can\u0027t state how many threads we should need (the event notifications should be fast) but for the L3 agent I would said to increase this number up to 32.\n\nIn any case, I would make the `max_workers` variable an input variable of the class itself, making the default value 32.\n\n```\nclass BatchNotifier:\n    def __init__(self, batch_interval, callback, thread_workers\u003d32):\n```\n\n[1]https://github.com/openstack/neutron/blob/a479df9aa4196ba6ab80c47c256ee284f02d053c/neutron/agent/l3/agent.py#L324-L325","commit_id":"1785b3c2ede6de72f5369b3b26d20182a61a6ed6"}]}