Back to bug 1311597
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Flavio Percoco | 2016-02-24 19:40:01 UTC | Status | NEW | ASSIGNED |
| Red Hat Bugzilla Rules Engine | 2016-02-24 19:40:05 UTC | Target Release | 8.0 | 7.0 |
| RHEL Program Management | 2016-02-24 19:45:07 UTC | Keywords | ZStream | |
| Flavio Percoco | 2016-02-24 20:35:53 UTC | CC | mkrcmari | |
| Assignee | fpercoco | vstinner | ||
| Flags | needinfo?(mkrcmari) | |||
| Marian Krcmarik | 2016-02-24 22:39:58 UTC | Flags | needinfo?(mkrcmari) | |
| John Skeoch | 2016-04-18 08:11:14 UTC | CC | yeylon | srevivo |
| Victor Stinner | 2016-07-28 14:37:50 UTC | CC | vstinner | |
| Victor Stinner | 2016-10-12 08:32:17 UTC | Status | ASSIGNED | POST |
| Victor Stinner | 2016-10-14 12:39:51 UTC | Status | POST | MODIFIED |
| Fixed In Version | python-oslo-messaging-1.8.3-6.el7ost | |||
| Doc Text | Oslo Messaging used the "shuffle" strategy to select a RabbitMQ host from the list of RabbitMQ servers. When a node of the cluster running RabbitMQ was restarted, each OpenStack service connected to this server reconnected to a new RabbitMQ server. Unfortunately, this strategy does not handle dead RabbitMQ servers correctly; it can try to connect to the same dead server multiple times in a row. The strategy also leads to increased reconnection time, and sometimes it may lead to RPC operations timing out because no guarantee is provided on how long the reconnection process will take. With this update, Oslo Messaging uses the "round-robin" strategy to select a RabbitMQ host. This strategy provides the least achievable reconnection time and avoids RPC timeout when a node is restarted. It also guarantees that if K of N RabbitMQ hosts are alive, it will take at most N - K + 1 attempts to successfully reconnect to the RabbitMQ cluster. |
|||
| errata-xmlrpc | 2016-11-28 19:45:24 UTC | Status | MODIFIED | ON_QA |
| Udi Shkalim | 2016-12-11 16:43:20 UTC | Flags | needinfo?(mkrcmari) | |
| Marian Krcmarik | 2016-12-12 09:19:07 UTC | Status | ON_QA | VERIFIED |
| Flags | needinfo?(mkrcmari) | |||
| Pablo Iranzo Gómez | 2016-12-21 07:47:31 UTC | CC | pablo.iranzo | |
| Flags | needinfo?(vstinner) | |||
| Pablo Iranzo Gómez | 2017-01-03 11:18:32 UTC | CC | rcernin | |
| Flags | needinfo?(vstinner) | needinfo?(rcernin) | ||
| Scott Lewis | 2017-01-11 18:55:06 UTC | Target Milestone | ga | async |
| Deepti Navale | 2017-01-13 02:12:15 UTC | CC | dnavale | |
| Doc Text | Oslo Messaging used the "shuffle" strategy to select a RabbitMQ host from the list of RabbitMQ servers. When a node of the cluster running RabbitMQ was restarted, each OpenStack service connected to this server reconnected to a new RabbitMQ server. Unfortunately, this strategy does not handle dead RabbitMQ servers correctly; it can try to connect to the same dead server multiple times in a row. The strategy also leads to increased reconnection time, and sometimes it may lead to RPC operations timing out because no guarantee is provided on how long the reconnection process will take. With this update, Oslo Messaging uses the "round-robin" strategy to select a RabbitMQ host. This strategy provides the least achievable reconnection time and avoids RPC timeout when a node is restarted. It also guarantees that if K of N RabbitMQ hosts are alive, it will take at most N - K + 1 attempts to successfully reconnect to the RabbitMQ cluster. | Oslo Messaging used the 'shuffle' strategy to select a RabbitMQ host from the list of RabbitMQ servers. When a node of the cluster running RabbitMQ was restarted, each OpenStack service connected to this server reconnected to a new RabbitMQ server. Unfortunately, this strategy does not handle dead RabbitMQ servers correctly; it can try to connect to the same dead server multiple times in a row. The strategy also leads to increased reconnection time, and sometimes may lead to RPC operations timing out because no guarantee is provided on how long the reconnection process will take. With this update, Oslo Messaging uses the 'round-robin' strategy to select a RabbitMQ host. This strategy provides the least achievable reconnection time and avoids RPC timeout when a node is restarted. It also guarantees that if K of N RabbitMQ hosts are alive, it will take at most N - K + 1 attempts to successfully reconnect to the RabbitMQ cluster. |
||
| errata-xmlrpc | 2017-01-18 01:13:48 UTC | Status | VERIFIED | RELEASE_PENDING |
| errata-xmlrpc | 2017-01-19 13:27:11 UTC | Status | RELEASE_PENDING | CLOSED |
| Resolution | --- | ERRATA | ||
| Last Closed | 2017-01-19 08:27:11 UTC | |||
| Robin Cernin | 2021-02-01 02:40:18 UTC | Flags | needinfo?(rcernin) |
Back to bug 1311597