| 2015-03-20 00:22:11 |
Rohit Jaiswal |
bug |
|
|
added bug |
| 2015-03-20 00:22:16 |
Rohit Jaiswal |
ceilometer: assignee |
|
Rohit Jaiswal (rohit-jaiswal-3) |
|
| 2015-03-20 00:25:01 |
Rohit Jaiswal |
summary |
Collector keeps on requeueing a message in case of a persistent error from dispatcher when requeueing is enabled |
Collector keeps on requeueing and retrying a message in case of a persistent error from dispatcher when requeueing is enabled |
|
| 2015-03-20 00:25:34 |
Rohit Jaiswal |
description |
When requeue_sample_on_dispatcher_error is enabled in ceilometer.conf, the collector will try to requeue the sample if it gets an error from the dispatcher.
When the sample gets requeued, it will get picked up again and dispatched to the storage layer. If the same underlying error condition prevails, the error will be raised back to the collector and the message will be requeued again. This cyclical process will continue until the error is gone(in which case the sample is not requeued again) or the collector/ RMQ are restarted.
In such scenario, when there is an persistent error condition, frequent retrying puts extra load on storage db and the messaging layer (rabbit), since the message and potentially more samples keep getting requeued and not cleared from the queue.
There should be a configurable upper limit to cap the number of requeues of samples/events by Collector in case of dispatcher error. |
When requeue_sample_on_dispatcher_error is enabled in ceilometer.conf, the collector will try to requeue the sample if it gets an error from the dispatcher.
When the sample gets requeued, it will get picked up again and dispatched to the storage layer. If the same underlying error condition prevails, the error will be raised back to the collector and the message will be requeued again. This cyclical process will continue until the error is gone(in which case the sample is not requeued again) or the collector/ RMQ are restarted.
In this scenario, when there is an persistent error condition, frequent retrying puts extra load on storage db and the messaging layer (rabbit), since the message and potentially more samples keep getting requeued and not cleared from the queue.
There should be a configurable upper limit to cap the number of requeues of samples/events by Collector in case of dispatcher error. |
|
| 2015-03-20 00:27:37 |
Rohit Jaiswal |
description |
When requeue_sample_on_dispatcher_error is enabled in ceilometer.conf, the collector will try to requeue the sample if it gets an error from the dispatcher.
When the sample gets requeued, it will get picked up again and dispatched to the storage layer. If the same underlying error condition prevails, the error will be raised back to the collector and the message will be requeued again. This cyclical process will continue until the error is gone(in which case the sample is not requeued again) or the collector/ RMQ are restarted.
In this scenario, when there is an persistent error condition, frequent retrying puts extra load on storage db and the messaging layer (rabbit), since the message and potentially more samples keep getting requeued and not cleared from the queue.
There should be a configurable upper limit to cap the number of requeues of samples/events by Collector in case of dispatcher error. |
When requeue_sample_on_dispatcher_error is enabled in ceilometer.conf, the collector will try to requeue the sample if it gets an error from the dispatcher.
When the sample gets requeued, it will get picked up again and dispatched to the storage layer. If the same underlying error condition prevails, the error will be raised back to the collector and the message will be requeued again. This cyclical process will continue until the error is gone(in which case the sample is not requeued again) or the collector/ RMQ are restarted.
In this scenario, when there is an persistent error condition, frequent retrying puts extra load on storage db and the messaging layer (rabbit), since the message and potentially more samples keep getting requeued and not cleared from the queue.
It does not make sense to keep retrying continuously in case of a persistent error condition.
There should be a configurable upper limit to cap the number of requeues of samples/events by Collector in case of dispatcher error. |
|
| 2015-03-20 00:29:21 |
Rohit Jaiswal |
description |
When requeue_sample_on_dispatcher_error is enabled in ceilometer.conf, the collector will try to requeue the sample if it gets an error from the dispatcher.
When the sample gets requeued, it will get picked up again and dispatched to the storage layer. If the same underlying error condition prevails, the error will be raised back to the collector and the message will be requeued again. This cyclical process will continue until the error is gone(in which case the sample is not requeued again) or the collector/ RMQ are restarted.
In this scenario, when there is an persistent error condition, frequent retrying puts extra load on storage db and the messaging layer (rabbit), since the message and potentially more samples keep getting requeued and not cleared from the queue.
It does not make sense to keep retrying continuously in case of a persistent error condition.
There should be a configurable upper limit to cap the number of requeues of samples/events by Collector in case of dispatcher error. |
When requeue_sample_on_dispatcher_error is enabled in ceilometer.conf, the collector will try to requeue the sample if it gets an error from the dispatcher.
When the sample gets requeued, it will get picked up again and dispatched to the storage layer. If the same underlying error condition prevails, the error will be raised back to the collector and the message will be requeued again. This cyclical process will continue until the error is gone(in which case the sample is not requeued again) or the collector/ RMQ are restarted.
In this scenario, when there is an persistent error condition, frequent retrying puts extra load on storage db and the messaging layer (rabbit), since the message and potentially more samples keep getting requeued and not cleared from the queue.
It does not make sense to keep retrying continuously in case of a persistent error condition.
There should be a configurable upper limit to cap the number of requeues of samples/events by Collector in case of dispatcher error.
eg. requeue_sample_on_dispatcher_error_max_retries |
|
| 2015-03-20 02:29:29 |
Rohit Jaiswal |
description |
When requeue_sample_on_dispatcher_error is enabled in ceilometer.conf, the collector will try to requeue the sample if it gets an error from the dispatcher.
When the sample gets requeued, it will get picked up again and dispatched to the storage layer. If the same underlying error condition prevails, the error will be raised back to the collector and the message will be requeued again. This cyclical process will continue until the error is gone(in which case the sample is not requeued again) or the collector/ RMQ are restarted.
In this scenario, when there is an persistent error condition, frequent retrying puts extra load on storage db and the messaging layer (rabbit), since the message and potentially more samples keep getting requeued and not cleared from the queue.
It does not make sense to keep retrying continuously in case of a persistent error condition.
There should be a configurable upper limit to cap the number of requeues of samples/events by Collector in case of dispatcher error.
eg. requeue_sample_on_dispatcher_error_max_retries |
When requeue_sample_on_dispatcher_error is enabled in ceilometer.conf, the collector will try to requeue the sample if it gets an error from the dispatcher.
When the sample gets requeued, it will get picked up again and dispatched to the storage layer. If the same underlying error condition prevails, the error will be raised back to the collector and the message will be requeued again. This cyclical process will continue until the error is gone(in which case the sample is not requeued again) or the collector/ RMQ are restarted.
In this scenario, when there is an persistent error condition, frequent retrying puts extra load on storage db and the messaging layer (rabbit), wasting collector CPU cycles since the message and potentially more samples keep getting requeued and not cleared from the queue.
It does not make sense to keep retrying continuously in case of a persistent error condition.
There should be a configurable upper limit to cap the number of requeues of samples/events by Collector in case of dispatcher error.
eg. requeue_sample_on_dispatcher_error_max_retries |
|
| 2015-03-20 04:52:42 |
Rohit Jaiswal |
summary |
Collector keeps on requeueing and retrying a message in case of a persistent error from dispatcher when requeueing is enabled |
Collector continuously re-queues sample when dispatcher reports persistent error when requeue is enabled |
|
| 2015-03-23 15:12:56 |
gordon chung |
ceilometer: status |
New |
Triaged |
|
| 2016-04-23 02:47:58 |
ZhiQiang Fan |
ceilometer: status |
Triaged |
New |
|
| 2016-04-23 02:48:00 |
ZhiQiang Fan |
ceilometer: assignee |
Rohit Jaiswal (rohit-jaiswal-3) |
|
|
| 2016-09-01 18:22:39 |
Milan Potdar |
bug |
|
|
added subscriber Milan Potdar |
| 2016-11-02 14:10:15 |
gordon chung |
ceilometer: status |
New |
Triaged |
|
| 2016-11-02 14:10:19 |
gordon chung |
ceilometer: importance |
Undecided |
Medium |
|
| 2017-06-15 12:32:58 |
gordon chung |
ceilometer: status |
Triaged |
Won't Fix |
|
