gaussianrecurrence commented on pull request #800: URL: https://github.com/apache/geode-native/pull/800#issuecomment-832003167
> > Sending GET_CLIENT_PR_METADATA to a server for a replicated region generated an EXCEPTION response message, which the native client would then ignore. Convention in the Java client is to check for a bucket count of -1, indicating replicated region, and skip the metadata request in that case. > > @gaussianrecurrence > > > I wonder if it's best to add this behaviour to enqueueForMetadataRefresh instead. Maybe that function could be refactored, so instead of accepting the full path, it accepts the region object. This way it can be check if the region is partitioned or replicated. And if replicated, then don't add the request to the queue. > > Given the complexity of our dependency graph, I'm reluctant to pass around yet another reference to a `region` object that must be accounted for at shutdown, esp to a thread with dubious timing like the metadata service. We could, however, potentially save some network traffic by storing a map of region name to server region type in `ClientMetadataService` _if_ we knew it was not possible for server region type to change "on the fly". @pivotal-jbarrett do you know if this is the case? If so, we could save the server region type and never send GET_CLIENT_PARTITION_ATTRIBUTES for a known region with replicated type. I also wonder if the optimization is worth the effort, though, since metadata refresh isn't intended to be a high-frequency event. Sorry for the confusion, I thought you had the information about whether a region is partitioned or replicated just after you registered the region in the client. And as for the optimization you pointed out, as you said, metadata update should only happen upon rebalance, which is not a pretty common event, so I'd say there's really no save there. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
