[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-3062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16513845#comment-16513845
 ] 

Christine Poerschke commented on ZOOKEEPER-3062:
------------------------------------------------


Thanks [~andorm] for the quick feedback on my initial patch!

bq. ... Isn't this property exposed via JMX / Jetty / 4LWs? ..

Yes, once you know that the property exists then its value can be inspected in 
different ways. Mentioning the property name in the warning is to help users 
learn (or remember) about the existence of the property. Logging the property 
value as well can help with log interpretation e.g. "Last week this ensemble 
logged X warnings, this week it's logging Y warnings, why is that? Oh yeah, we 
changed the fsync.warningthresholdms threshold the other day!" scenarios.

bq. ... Please remove unit test to verify constant values. It doesn't make any 
sense to me.

Done.

The {{FileTxnLogTest.testConstantsUnchanged}} method was a 
{{SomeClassTest.testConstantsUnchanged}} style test where
{code}
Assert.assertEquals("magicSystemProperty", SomeClass.MAGIC_SYSTEM_PROPERTY);
{code}
is intended to fail if in future anyone ever changed {{SomeClass.java}} e.g. 
like this
{code}
- static final String MAGIC_SYSTEM_PROPERTY = "magicSystemProperty";
+ static final String MAGIC_SYSTEM_PROPERTY = "someClass.magicSystemProperty";
{code}
though obviously {{SomeClassTest.java}} could be changed at the same time 
and/or it might very apparent anyhow that changing 
{{SomeClass.MAGIC_SYSTEM_PROPERTY}} would break backwards compatibility.

> mention fsync.warningthresholdms in FileTxnLog LOG.warn message
> ---------------------------------------------------------------
>
>                 Key: ZOOKEEPER-3062
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3062
>             Project: ZooKeeper
>          Issue Type: Task
>            Reporter: Christine Poerschke
>            Priority: Minor
>         Attachments: ZOOKEEPER-3062.patch, ZOOKEEPER-3062.patch
>
>
> The
> {code}
> fsync-ing the write ahead log in ... took ... ms which will adversely effect 
> operation latency. File size is ... bytes. See the ZooKeeper troubleshooting 
> guide
> {code}
> warning mentioning the {{fsync.warningthresholdms}} configurable property 
> would make it easier to discover and also when interpreting historical vs. 
> current logs or logs from different ensembles then differences in 
> configuration would be easier to spot.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to