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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
