[GitHub] [accumulo] ctubbsii opened a new issue, #3072: MetadataLocationObtainer has undocumented confusing behavior

[GitBox <gi...@apache.org>]

ctubbsii opened a new issue, #3072:
URL: https://github.com/apache/accumulo/issues/3072

   While reviewing #2861, I noticed that the `more` field wasn't really used for much. It was just used for one additional lookup. However, the value of `more` was never assigned again. It looked like this was originally supposed to be part of a loop and the `more` value being true kept it in the loop. However, looking at this code further, I can't tell what any of it is doing. It looks like the `if` should be a `while` loop, but this is not clear. Perhaps only one additional lookup needs to be done if `more` is true, but there are no comments explaining why this would be the case, and it's not obvious to me. Some comments in here would be really nice, and if there is a bug and this should be a loop, that should be fixed.
   
   https://github.com/apache/accumulo/blob/6d3aeccd8e86853bb8cf88b7590673787e127d0a/core/src/main/java/org/apache/accumulo/core/metadata/MetadataLocationObtainer.java#L114-L123
   


-- 
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.

To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [accumulo] keith-turner commented on issue #3072: MetadataLocationObtainer has undocumented confusing behavior

[GitBox <gi...@apache.org>]

keith-turner commented on issue #3072:
URL: https://github.com/apache/accumulo/issues/3072#issuecomment-1307103808

   Looking at the code I am trying to understand when it might trigger. Looking on the server side there three reasons a scan can stop when there is still data.
   
   https://github.com/apache/accumulo/blob/d3a327740d02c4262f7860067f133772390e3975/server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/TabletBase.java#L282
   
   The intent of the metadatalocationobtainer is to read ahead and get locations of multiple rows when asked for a single location.  This populates the client cache for possible future reads.
   
   My guess is that this case is saying I only got one metadata location and there are more, so maybe the tsever kicked me out early for some reason lets make one attempt to get a few more locations.  If that is the reason, not sure if this is worthwhile.  Later client location cache misses would cause subsequent metadata reads anyway.
   
   Of the three tablet server side conditions that cause the scan to send back a batch of data, it seems like only two would trigger this case.  One being the total size of the scan buffer, which could be caused by a large metadata row.  The other being the timeout.  Given we are using the whole row iterator, it does not seem like the condition for the number of entries would trigger on the server side.
   
   It may be useful to add some logging for this case and see if it triggers under the suspected conditions, or if there is some unanticipated reason.


-- 
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.

To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org