[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