Aaron Fabbri commented on HADOOP-13452:

Thanks for review [~liuml07].

{quote}Is the LruHashMap always supposed to access the entries via mruGet()? 

I was trying to have the flexibility of allowing caller to only call get() when 
it doesn't need to MRU the entry.  I only use the plain get() once, and you 
could argue it could be an mruGet() instead.

{quote}And for fixed size, we can override the removeEldestEntry() 
I do that. This code looks the same as mine, except I do not override load 
factor to 1.0 (which saves space at expense of runtime).

{quote}Basically we can simply make operating methods synchronized instead of 
synchronized blocks? This should improve readability if no obvious performance 

I can do that for the functions where the critical section is the whole method. 
 I like the explicit block style (often I don't notice synchronized in 
signatures for some reason), but I'm happy to change it.  I don't think it is 
addressed in style guide.

Or can we simply use the off-the-shelf org.apache.commons.collections.map.LRUMap
I didn't know that existed.  I'm happy to use it.  One concern is that it 
subclasses a deprecated, non-Java API linked hash map implementation. 

> S3Guard: Implement access policy for intra-client consistency with in-memory 
> metadata store.
> --------------------------------------------------------------------------------------------
>                 Key: HADOOP-13452
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13452
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: fs/s3
>            Reporter: Chris Nauroth
>            Assignee: Aaron Fabbri
>         Attachments: HADOOP-13452.001.patch
> Implement an S3A access policy based on an in-memory metadata store.  This 
> can provide consistency within the same client without needing to integrate 
> with an external system.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

Reply via email to