Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Fix for FLUO-938 #941

Closed
wants to merge 10 commits into from
Closed

WIP: Fix for FLUO-938 #941

wants to merge 10 commits into from

Conversation

kennethmcfarland
Copy link
Contributor

No description provided.


// Note the size of the cache is in megabytes
public static final String TX_INFO_CACHE_SIZE = FLUO_IMPL_PREFIX + ".tx.failed.cache.size.mb";
/* TODO: What is a reasonable default size? Currently CacheBuilder does not specify a size in TxInfoCache.java */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It indirectly specifies a size by specifying at weight and weigher. A weigher could return anything, in this case it returns size. The TxStatusWeigher returns the size + 24 (there is not coment, but I assume the 24 is some estimated overhead). Currently its specifies a max weight of 10,000,000, so that would be a good default. Need to look for other config that has a size in mb and see if multiplies by 10^6 or 2^20, it would be good to be consistent.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did some digging and found three precedents. In FluoConfigurationImpl we have a commit memory which has a unit of bytes. In FluoYarnConfig we have fluo.yarn.worker.max.memory.mb these end up being passed to Twill and it seems that Twill has a SizeUnit class. However the Twill SizeUnit class does not document if MEGA is 10^6 or 2^20. Based on past experience I think it may 2^20, but not sure. I would say multiply by 2^20 for now.

*
* @param conf
* @return The shelf life of entries before they will be evicted if not accessed
* TODO: What timeunit would make most sense? Currently TxCacheInfo uses TimeUnit.MINUTES
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats a very good question. I looked at some time props in FluoConfiguration and the timeunits are mostly well documented because of your previous change. Need to document the timeunit for zookeeper timeout, this could be a new help wanted issue, would you like to open that?

I did find one prop with a pattern I really liked in FluoConfiguration

public FluoConfiguration setTransactionRollbackTime(long time, TimeUnit tu) {
    return setPositiveLong(TRANSACTION_ROLLBACK_TIME_PROP, tu.toMillis(time));
  }

I like two things about this pattern :

  • In the java API it uses timeunit, so that makes the code very clear and explicit.
  • Internally it converts everything to milliseconds and the prop name ends with ms.

Something that transaction rollback time didn't do that would have been nice would be to accept a timeunit on the getter. For cache timeout, this could be something like long getTxInfoCacheTimeout(FluoConfiguration conf, TimeUnit tu) and it will return the timeout in the specified unit.

This makes me think it would be nice to have a SizeUnit, I am not sure if this is a good idea or not. May be worthwhile opening an issue to discuss. Could make config API nicer.

@keith-turner
Copy link
Contributor

@kpm1985 sorry I have not been able to look at your latest changes sooner. I plan on looking at them tomorrow afternoon.


/**
* Gets the time before stale entries in the cache are evicted based on age.
* This method returns a long representing the time in milliseconds.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can replace time in milliseconds with time in passed in unit.


public static long getTxIfoCacheTimeout(FluoConfiguration conf, TimeUnit tu) {
int minutes = getTxInfoCacheTimeout(conf);
return tu.toMillis((long) minutes);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be return tu.convert(minutes, TimeUnit.MINUTES). This will convert minutes to the passed in time unit.

* @param conf FluoConfiguration
* @return the time in minutes
*/
public static int getTxInfoCacheTimeout(FluoConfiguration conf) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method could be dropped and its functionality inlined in the method getTxIfoCacheTimeout(FluoConfiguration, TimeUnit)

}

public static final String TX_INFO_CACHE_TIMEOUT =
FLUO_IMPL_PREFIX + ".tx.failed.cache.expireTime";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could add a suffix of minutes like .tx.failed.cache.expireTime.minutes

@kennethmcfarland
Copy link
Contributor Author

kennethmcfarland commented Oct 17, 2017 via email

Copy link
Contributor

@keith-turner keith-turner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this code looks good and is ready to be called by TxInfoCache constructor. Changing the internal units from minutes to milliseconds could be done as a follow on issue or in this PR.

}

public static final String TX_INFO_CACHE_TIMEOUT =
FLUO_IMPL_PREFIX + ".tx.failed.cache.expireTime.minutes";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think minutes makes sense for this property. However I am thinking we should change the unit to milliseconds for consistency. Some other time based configs may need more granularity. Going forward, I think it would be nice if all new time based configs added had the same unit. This results in a less confusing experience when considering the config as a whole.

We can use a suffix of .ms for the property name.

public static long getTxIfoCacheTimeout(FluoConfiguration conf, TimeUnit tu) {
long minutes = (long) conf.getInt(TX_INFO_CACHE_TIMEOUT, TX_INFO_CACHE_TIMEOUT_DEFAULT);
if (minutes <= 0) {
throw new IllegalArgumentException("Timout must positive for " + TX_INFO_CACHE_TIMEOUT);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replace Timout must positive with Timeout must be positive.

*/

public static long getTxIfoCacheTimeout(FluoConfiguration conf, TimeUnit tu) {
long minutes = (long) conf.getInt(TX_INFO_CACHE_TIMEOUT, TX_INFO_CACHE_TIMEOUT_DEFAULT);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does conf have a getLong() method?

public static final long TX_INFO_CACHE_SIZE_DEFAULT = 10000000;

/**
* Gets the value of the property {@value #TX_INFO_CACHE_SIZE} if set,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this can be dropped as it is well covered in the @return docs.

* @return The size of the cache value from the property value {@value #TX_INFO_CACHE_SIZE}
* if it is set, else the value of the default value {@value #TX_INFO_CACHE_SIZE_DEFAULT}
*
* @since 1.2.0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding @since here is optional as this is not public API.

…es to be consistent, use conf.getLong which no longer needs boxing or casting, remove @SInCE tags for private class. -Kenneth McFarland
@kennethmcfarland
Copy link
Contributor Author

I changed the data type for the default property to simply be a long instead of an int. Same functionality, no more boxing or casting and can use conf.getLong().

*/

public static long getTxIfoCacheTimeout(FluoConfiguration conf, TimeUnit tu) {
long minutes = conf.getLong(TX_INFO_CACHE_TIMEOUT, TX_INFO_CACHE_TIMEOUT_DEFAULT);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should change this var name from minutes to something like millis

if (minutes <= 0) {
throw new IllegalArgumentException("Timeout must positive for " + TX_INFO_CACHE_TIMEOUT);
}
return tu.convert(minutes, TimeUnit.MINUTES);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should change the timeunit from MINUTES to MILLISECONDS


public static final String TX_INFO_CACHE_TIMEOUT =
FLUO_IMPL_PREFIX + ".tx.failed.cache.expireTime.ms";
public static final long TX_INFO_CACHE_TIMEOUT_DEFAULT = 24 * 60;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should set this to 24 * 60 * 1000

@kennethmcfarland
Copy link
Contributor Author

kennethmcfarland commented Oct 18, 2017 via email

@keith-turner
Copy link
Contributor

@kpm1985 these changes look great. After make the cache code call these new config methods, this will be ready to merge.

@kennethmcfarland
Copy link
Contributor Author

@keith-turner Thank you, I've modified the constructor to take the new methods

@kennethmcfarland
Copy link
Contributor Author

kennethmcfarland commented Oct 19, 2017 via email

Copy link
Contributor

@keith-turner keith-turner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good. Thanks again @kpm1985

asfgit pushed a commit that referenced this pull request Oct 19, 2017
@kennethmcfarland kennethmcfarland deleted the FLUO-938 branch October 19, 2017 08:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants