First of all, the use of "Vs" is probably not the best choice. "Vs" is for two comparable things.
I think "userToConnectionsMap" might be better.
I am wondering whether introducing a separate metrics class is better. (Something similar to RpcDetailedMetrics) For typical metrics, a counter is simply incremented and the diff shows the rate. If users are only interested in instantaneous counts and do not care at all about cumulative counts, the approach in the patch might be okay. But I am thinking cumulative values are useful too.
That's a good idea and may be required to for detailed analysis about each user's usage. In simple terms there could be separate instances of RpcDetailedMetrics for each user, Just an Idea. I feel this could be done in a follow-up jira and detailed discussions could be made.
If we are to proceed with the proposed approach, I suggest simply synchronize on the lock object inside incrUserConnections() and decrUserConnections() and lose the private methods. Then no need to have AtomicInteger. The ideal way will be range-locking the map, but I don't know whether there is any known good implementation of it. In any case, the number of rpc reader threads is typically small, so this level of synchronization/monitor lock should be okay.
In this jira only simple count of connections can be exposed as a metric, as title says.
Brahma Reddy Battula, please update the patch with simple synchronization, as suggested by Kihwal Lee.