Description of problem:
in 5.5.0 and 5.5.2, the handling of an exception creates a cascade of issues regarding the collection of performance data

Version-Release number of selected component (if applicable):
5.5.0 and 5.5.2

How reproducible:
customer environment only

Steps to Reproduce:
1. deploy one appliance
2. use a scvmm, vmware, azure, amazon, openstack provider each (small environments)
3. enable performance collection

Actual results:
the following trace causes the interruption of all performance capture :

[----] I, [2016-02-29T03:08:20.304407 #13515:e4f994]  INFO -- : MIQ(MiqQueue.put_or_update) Message id: [4201000002602406],  id: [], Zone: [default], Role: [ems_metrics_collector], Server: [], Ident: [], Target id: [], Instance id: [4201
000000000068], Task id: [], Command: [ManageIQ::Providers::Microsoft::InfraManager::Host.perf_capture], Timeout: [600], Priority: [100], State: [ready], Deliver On: [], Data: [], Args: ["realtime"], Requeued
[----] E, [2016-02-29T03:08:20.405466 #13515:e4f994] ERROR -- : MIQ(MiqQueue#deliver) Message id: [4201000002940378], Error: [undefined method `metrics_collector_queue_name' for nil:NilClass]
[----] E, [2016-02-29T03:08:20.405662 #13515:e4f994] ERROR -- : [NoMethodError]: undefined method `metrics_collector_queue_name' for nil:NilClass  Method:[rescue in deliver]
[----] E, [2016-02-29T03:08:20.406202 #13515:e4f994] ERROR -- : /var/www/miq/vmdb/app/models/metric/ci_mixin/capture.rb:19:in `queue_name_for_metrics_collection'
/var/www/miq/vmdb/app/models/metric/ci_mixin/capture.rb:69:in `perf_capture_queue'
/var/www/miq/vmdb/app/models/metric/capture.rb:127:in `block in perf_capture_timer'
/var/www/miq/vmdb/app/models/metric/capture.rb:112:in `each'
/var/www/miq/vmdb/app/models/metric/capture.rb:112:in `perf_capture_timer'
/var/www/miq/vmdb/app/models/miq_queue.rb:345:in `block in deliver'
/opt/rh/rh-ruby22/root/usr/share/ruby/timeout.rb:89:in `block in timeout'
/opt/rh/rh-ruby22/root/usr/share/ruby/timeout.rb:34:in `block in catch'
/opt/rh/rh-ruby22/root/usr/share/ruby/timeout.rb:34:in `catch'
/opt/rh/rh-ruby22/root/usr/share/ruby/timeout.rb:34:in `catch'
/opt/rh/rh-ruby22/root/usr/share/ruby/timeout.rb:104:in `timeout'
/var/www/miq/vmdb/app/models/miq_queue.rb:341:in `deliver'
/var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:106:in `deliver_queue_message'
/var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:134:in `deliver_message'
/var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:151:in `block in do_work'
/var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:145:in `loop'
/var/www/miq/vmdb/app/models/miq_queue_worker_base/runner.rb:145:in `do_work'
/var/www/miq/vmdb/app/models/miq_worker/runner.rb:334:in `block in do_work_loop'
/var/www/miq/vmdb/app/models/miq_worker/runner.rb:331:in `loop'
/var/www/miq/vmdb/app/models/miq_worker/runner.rb:331:in `do_work_loop'
/var/www/miq/vmdb/app/models/miq_worker/runner.rb:153:in `run'
/var/www/miq/vmdb/app/models/miq_worker/runner.rb:128:in `start'
/var/www/miq/vmdb/app/models/miq_worker/runner.rb:29:in `start_worker'
/var/www/miq/vmdb/lib/workers/bin/worker.rb:2:in `<top (required)>'
/opt/rh/cfme-gemset/gems/railties-4.2.5.1/lib/rails/commands/runner.rb:60:in `load'
/opt/rh/cfme-gemset/gems/railties-4.2.5.1/lib/rails/commands/runner.rb:60:in `<top (required)>'
/opt/rh/cfme-gemset/gems/railties-4.2.5.1/lib/rails/commands/commands_tasks.rb:123:in `require'
/opt/rh/cfme-gemset/gems/railties-4.2.5.1/lib/rails/commands/commands_tasks.rb:123:in `require_command!'
/opt/rh/cfme-gemset/gems/railties-4.2.5.1/lib/rails/commands/commands_tasks.rb:90:in `runner'
/opt/rh/cfme-gemset/gems/railties-4.2.5.1/lib/rails/commands/commands_tasks.rb:39:in `run_command!'
/opt/rh/cfme-gemset/gems/railties-4.2.5.1/lib/rails/commands.rb:17:in `<top (required)>'
/var/www/miq/vmdb/bin/rails:4:in `require'
/var/www/miq/vmdb/bin/rails:4:in `<main>'



Expected results:
the exception does not stop the collection for all providers covered by the appliance

Additional info:
this is a single appliance to cover a lot of providers, which may be part of the issue here, but the handling of the error likely is the cause of all performance collection and this looks to be a bug in error handling.
trace is from 5.5.2