pdxcodemonkey commented on pull request #784: URL: https://github.com/apache/geode-native/pull/784#issuecomment-820761119
> Wow, this seems like really drastic action but I guess if it is consistent with the Java client... > > I would suggest that we also trigger the metadata update here. Clearly we have some metadata but it is incomplete. We should attempt to get the latest. Shouldn't be necessary, AFAIK, and might be dangerous. In the new test code, you'll notice the keys are strings. This is because the server is supposed to return a flag telling us to update the metadata after a PUT to the wrong server (again as I understand it). For some reason (per @boglesby) Geode doesn't set this flag for integer keys, BUT... with string keys it does. When geode-native sees this it triggers another metadata update, and the metadata we get back from the server _has empty buckets_. Thus, it's a perfectly normal situation to have "incomplete" metadata, and not at all an indication that we're stale and must re-request. Probably the effect of re-requesting is innocuous - in the case of the new test, for instance, we'd just get back complete metadata after it was too late to affect the PUTALL request. In the situation where we have a server that's unreachable from the client, however, I could see it getting us into a feedback loop, where we request metadata be cause we're missing buckets, then get back metadata containing buckets for the "bad" server, then remove those buckets from the metadata, then discover missing buckets and request metadata _again_, and so on. -- 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]
