Clarify documentation of JMS configuration parameter refresh


The documentation for '' property states that "The refresh period should be higher that the expected copy time." which is misleading imo. It should read "The refresh period represents the least amount of time that slaves will be out of sync with the master. It is recommended that the refresh period be higher than the expected copy time, however if the value becomes insufficient then the default implementation of FSSlaveDirectoryProvider will prevent multiple copies from occurring simultaneously using a mutex lock. It's safe to set this value low anticipating that as your index grows the lock will be used appropriately."

Based on the code, I believe the default value to be very high... but that's a separate issue.




Sanne Grinovero
March 26, 2012, 4:39 PM

Hi, thanks you're right that statement is quite outdated.

I'm not sure however on the wording "least amount of time": a copy might just have happened.


It is recommended that the refresh period be higher than the expected copy time; if a copy operation is still being performed when the next refresh triggers, the second refresh is skipped: it's safe to set this value low even when the copy time is not known.

Or since the refresh parameter is documented in the configuration table, I'd be tempted to just remove the tip (with no replacement).

Eli Colner
March 26, 2012, 10:27 PM

Yes, good point. I agree also about removing the tip. It seems clear enough to mention that overlapping copies are ignored. The user should be able to optimize for their requirements based on knowing there's room for some error. I was confused about what to expect as the index grows and the copy operation start to finish grows with it... I feel much better after looking at the code


Sanne Grinovero


Eli Colner


Suitable for new contributors

Yes, likely

Pull Request


Feedback Requested


Time tracking



Fix versions

Affects versions