SRM Load-Balancer on Collector Hosts Dropping Balancing Property Of Device(s)

Hi All.

SRM 5.0.0. HITACHI VSP ARRAY discovered with REST API via single collector instance(Note no multiple instances or multiple collectors involved - which are known to cause issues).
But Load Balancer on Collector Host(Hitachi Collect) is giving multiple 'Dropping' errors like:
AbstractDecisionTree::dispatchValue(): Missing required balancing property device for value HDS-REST-Collector74XXXXLUN00:02:BARequests... dropping! 
WARNING  --  -- AbstractDecisionTree::dispatchValue(): Missing required balancing property device for value HDS-REST-Collector74XXXXLUN00:02:BALatency... dropping! 
WARNING  --  -- AbstractDecisionTree::dispatchValue(): Missing required balancing property device for value HDS-REST-Collector74XXXXLUN00:02:BAReadLatency... dropping!

-  There are no errors in Hitachi-device-manager-collector Logs. Totally clean logs.
-  As a try (KB Article: 000030933)Performance Polling period in Solution Pack (Device Manager Collect) increased to 60 minutes. No luck. Still dropping.
-  Thought about KB Article: 000199345, but no idea which file to modify. May be not applicable.
-  Could it be:  KB: 000173587: The Load Balancer Connector (LBC) fails to recover after it goes into failover mode. But how to confirm this.
-  Found exactly matchig KB:000059671 - Performance data missing for Hitachi arrays.  But that KB has LUN IDs seems changing. In our case the LUN00:02 remains same. Deos this means only one LUN is affected. Others will be fine.

-  Also, this point has been taken care already: Cross-Reference Array Serial Number: Cross-reference the array serial number with data from capacity collection to add the necessary device property to the collected performance data. Avoid Separate Collection Instances or Hosts: We have Single Collector instance.
-  When we restart the Load-Balancer Service, these 'Dropping' errors goes away.  But then seen again after 15-20 minutes.

Please advise if anyone has some tips or pointers regarding this. 

Thanks.