dlmarion commented on issue #3213:
URL: https://github.com/apache/accumulo/issues/3213#issuecomment-1470173125

   > My mental model for tracking loading / unloading is that this is 
implementing a cache. This description
   > 
   > > The TabletServer keeps track of the KeyExtent and last access time for 
each online onDemand tablet
   > > seems to be describing LRU behavior.
   > 
   > Tracking the last access time can be expensive. How often does the access 
time get updated? If it is updated only on loading, then this seems that it 
would act more like "expireAfter", where it would be eligible for removal an a 
fixed time period.
   
   In my current PR for unloading, the last access time is set when the tablet 
is loaded, updated when TabletServer.getOnlineExtent() is called, and removed 
when the tablet is unloaded.
   
   >  In that case, what would prevent a tablet from being unloaded while a 
scan is in progress? Updating on every "next()" seems like it could be 
prohibitively expensive. The sweet spot would seem to be something that is 
tracking tablet usage so that tablet being used in active scans would not be 
unnecessarily unloaded. Maybe the last access is updated on init and on 
tear-down?
   
   I think I found a solution using the existing metrics that are tracked. I 
added it in 
https://github.com/dlmarion/accumulo/pull/38/commits/33fa498fe5272400a3da88645be01d56f097f845
   
   > 
   > The TableServers are going to need to gather sufficient metrics that 
unloader implementations can make determinations - while things like row / key 
knowledge will be custom, usage and access times will need to be provided.
   > 
   > As a "base" implementation, we could provide a time-based cleaner thread 
and as a extension, something triggered on low memory conditions?
   
   


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

Reply via email to