[jira] [Updated] (HBASE-20554) "WALs outstanding" message from CleanerChore is noisy

2019-02-01 Thread Andrew Purtell (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-20554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-20554:
---
Fix Version/s: (was: 1.5.0)

> "WALs outstanding" message from CleanerChore is noisy
> -
>
> Key: HBASE-20554
> URL: https://issues.apache.org/jira/browse/HBASE-20554
> Project: HBase
>  Issue Type: Bug
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Trivial
> Fix For: 3.0.0, 2.1.0, 1.3.3, 2.0.1, 1.4.5
>
> Attachments: HBASE-20554.patch
>
>
> WARN level "WALs outstanding" from CleanerChore should be DEBUG and are not 
> always correct. 
> I left a cluster configured for ITBLL (retaining all WALs for post hoc 
> analysis) and in the morning found the master log full of "WALs outstanding" 
> warnings from CleanerChore. 
> Should this really be a warning?
> {quote}
> 2018-05-09 16:42:03,893 WARN  
> [node-1.cluster,16000,1525851521469_ChoreService_2] cleaner.CleanerChore: 
> WALs outstanding under hdfs://node-1.cluster/hbase/oldWALs
> {quote}
> If someone has configured really long WAL retention then having WALs in 
> oldWALs will be normal. 
> Also, it seems the warning is sometimes incorrect.
> {quote}
> 2018-05-09 16:42:24,751 WARN  
> [node-1.cluster,16000,1525851521469_ChoreService_1] cleaner.CleanerChore: 
> WALs outstanding under hdfs://node-1.cluster/hbase/archive
> {quote}
> There are no WALs under archive/. 
> Even at DEBUG level, if it is not correct, then it can lead an operator to be 
> concerned about nothing, so better to just remove it.



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


[jira] [Updated] (HBASE-20554) "WALs outstanding" message from CleanerChore is noisy

2018-12-11 Thread Andrew Purtell (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-20554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-20554:
---
Fix Version/s: 1.3.3

> "WALs outstanding" message from CleanerChore is noisy
> -
>
> Key: HBASE-20554
> URL: https://issues.apache.org/jira/browse/HBASE-20554
> Project: HBase
>  Issue Type: Bug
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Trivial
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.3.3, 2.0.1, 1.4.5
>
> Attachments: HBASE-20554.patch
>
>
> WARN level "WALs outstanding" from CleanerChore should be DEBUG and are not 
> always correct. 
> I left a cluster configured for ITBLL (retaining all WALs for post hoc 
> analysis) and in the morning found the master log full of "WALs outstanding" 
> warnings from CleanerChore. 
> Should this really be a warning?
> {quote}
> 2018-05-09 16:42:03,893 WARN  
> [node-1.cluster,16000,1525851521469_ChoreService_2] cleaner.CleanerChore: 
> WALs outstanding under hdfs://node-1.cluster/hbase/oldWALs
> {quote}
> If someone has configured really long WAL retention then having WALs in 
> oldWALs will be normal. 
> Also, it seems the warning is sometimes incorrect.
> {quote}
> 2018-05-09 16:42:24,751 WARN  
> [node-1.cluster,16000,1525851521469_ChoreService_1] cleaner.CleanerChore: 
> WALs outstanding under hdfs://node-1.cluster/hbase/archive
> {quote}
> There are no WALs under archive/. 
> Even at DEBUG level, if it is not correct, then it can lead an operator to be 
> concerned about nothing, so better to just remove it.



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


[jira] [Updated] (HBASE-20554) "WALs outstanding" message from CleanerChore is noisy

2018-05-09 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-20554:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Pushed to branch-1.4 and up

> "WALs outstanding" message from CleanerChore is noisy
> -
>
> Key: HBASE-20554
> URL: https://issues.apache.org/jira/browse/HBASE-20554
> Project: HBase
>  Issue Type: Bug
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Trivial
> Fix For: 3.0.0, 2.1.0, 1.5.0, 2.0.1, 1.4.5
>
> Attachments: HBASE-20554.patch
>
>
> WARN level "WALs outstanding" from CleanerChore should be DEBUG and are not 
> always correct. 
> I left a cluster configured for ITBLL (retaining all WALs for post hoc 
> analysis) and in the morning found the master log full of "WALs outstanding" 
> warnings from CleanerChore. 
> Should this really be a warning?
> {quote}
> 2018-05-09 16:42:03,893 WARN  
> [node-1.cluster,16000,1525851521469_ChoreService_2] cleaner.CleanerChore: 
> WALs outstanding under hdfs://node-1.cluster/hbase/oldWALs
> {quote}
> If someone has configured really long WAL retention then having WALs in 
> oldWALs will be normal. 
> Also, it seems the warning is sometimes incorrect.
> {quote}
> 2018-05-09 16:42:24,751 WARN  
> [node-1.cluster,16000,1525851521469_ChoreService_1] cleaner.CleanerChore: 
> WALs outstanding under hdfs://node-1.cluster/hbase/archive
> {quote}
> There are no WALs under archive/. 
> Even at DEBUG level, if it is not correct, then it can lead an operator to be 
> concerned about nothing, so better to just remove it.



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


[jira] [Updated] (HBASE-20554) "WALs outstanding" message from CleanerChore is noisy

2018-05-09 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-20554:
---
Status: Patch Available  (was: Open)

> "WALs outstanding" message from CleanerChore is noisy
> -
>
> Key: HBASE-20554
> URL: https://issues.apache.org/jira/browse/HBASE-20554
> Project: HBase
>  Issue Type: Bug
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Trivial
> Fix For: 3.0.0, 2.1.0, 1.5.0, 2.0.1, 1.4.5
>
> Attachments: HBASE-20554.patch
>
>
> WARN level "WALs outstanding" from CleanerChore should be DEBUG and are not 
> always correct. 
> I left a cluster configured for ITBLL (retaining all WALs for post hoc 
> analysis) and in the morning found the master log full of "WALs outstanding" 
> warnings from CleanerChore. 
> Should this really be a warning?
> {quote}
> 2018-05-09 16:42:03,893 WARN  
> [node-1.cluster,16000,1525851521469_ChoreService_2] cleaner.CleanerChore: 
> WALs outstanding under hdfs://node-1.cluster/hbase/oldWALs
> {quote}
> If someone has configured really long WAL retention then having WALs in 
> oldWALs will be normal. 
> Also, it seems the warning is sometimes incorrect.
> {quote}
> 2018-05-09 16:42:24,751 WARN  
> [node-1.cluster,16000,1525851521469_ChoreService_1] cleaner.CleanerChore: 
> WALs outstanding under hdfs://node-1.cluster/hbase/archive
> {quote}
> There are no WALs under archive/. 
> Even at DEBUG level, if it is not correct, then it can lead an operator to be 
> concerned about nothing, so better to just remove it.



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


[jira] [Updated] (HBASE-20554) "WALs outstanding" message from CleanerChore is noisy

2018-05-09 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-20554:
---
Attachment: HBASE-20554.patch

> "WALs outstanding" message from CleanerChore is noisy
> -
>
> Key: HBASE-20554
> URL: https://issues.apache.org/jira/browse/HBASE-20554
> Project: HBase
>  Issue Type: Bug
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Trivial
> Fix For: 3.0.0, 2.1.0, 1.5.0, 2.0.1, 1.4.5
>
> Attachments: HBASE-20554.patch
>
>
> WARN level "WALs outstanding" from CleanerChore should be DEBUG and are not 
> always correct. 
> I left a cluster configured for ITBLL (retaining all WALs for post hoc 
> analysis) and in the morning found the master log full of "WALs outstanding" 
> warnings from CleanerChore. 
> Should this really be a warning?
> {quote}
> 2018-05-09 16:42:03,893 WARN  
> [node-1.cluster,16000,1525851521469_ChoreService_2] cleaner.CleanerChore: 
> WALs outstanding under hdfs://node-1.cluster/hbase/oldWALs
> {quote}
> If someone has configured really long WAL retention then having WALs in 
> oldWALs will be normal. 
> Also, it seems the warning is sometimes incorrect.
> {quote}
> 2018-05-09 16:42:24,751 WARN  
> [node-1.cluster,16000,1525851521469_ChoreService_1] cleaner.CleanerChore: 
> WALs outstanding under hdfs://node-1.cluster/hbase/archive
> {quote}
> There are no WALs under archive/. 
> Even at DEBUG level, if it is not correct, then it can lead an operator to be 
> concerned about nothing, so better to just remove it.



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


[jira] [Updated] (HBASE-20554) "WALs outstanding" message from CleanerChore is noisy

2018-05-09 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-20554:
---
Description: 
WARN level "WALs outstanding" from CleanerChore should be DEBUG and are not 
always correct. 

I left a cluster configured for ITBLL (retaining all WALs for post hoc 
analysis) and in the morning found the master log full of "WALs outstanding" 
warnings from CleanerChore. 

Should this really be a warning? Perhaps better logged at DEBUG level.

{quote}
2018-05-09 16:42:03,893 WARN  
[node-1.cluster,16000,1525851521469_ChoreService_2] cleaner.CleanerChore: WALs 
outstanding under hdfs://node-1.cluster/hbase/oldWALs
{quote}

If someone has configured really long WAL retention then having WALs in oldWALs 
will be normal. 

Also, it seems the warning is sometimes incorrect.

{quote}
2018-05-09 16:42:24,751 WARN  
[node-1.cluster,16000,1525851521469_ChoreService_1] cleaner.CleanerChore: WALs 
outstanding under hdfs://node-1.cluster/hbase/archive
{quote}

There are no WALs under archive/. 

Even at DEBUG level, if it is not correct, then it can lead an operator to be 
concerned about nothing, so better to just remove it.

  was:
WARN level "WALs outstanding" from CleanerChore should be DEBUG and are not 
always correct. 

I left a cluster configured for ITBLL (retaining all WALs for post hoc 
analysis) and in the morning found the master log full of "WALs outstanding" 
warnings from CleanerChore. 

Should this really be a warning? Perhaps better logged at DEBUG level.

{quote}
2018-05-09 16:42:03,893 WARN  
[node-1.cluster,16000,1525851521469_ChoreService_2] cleaner.CleanerChore: WALs 
outstanding under hdfs://node-1.cluster/hbase/oldWALs

If someone has configured really long WAL retention then having WALs in oldWALs 
will be normal. 

Also, it seems the warning is sometimes incorrect.

{quote}
2018-05-09 16:42:24,751 WARN  
[node-1.cluster,16000,1525851521469_ChoreService_1] cleaner.CleanerChore: WALs 
outstanding under hdfs://node-1.cluster/hbase/archive
{quote}

There are no WALs under archive/. 

Even at DEBUG level, if it is not correct, then it can lead an operator to be 
concerned about nothing, so better to just remove it.


> "WALs outstanding" message from CleanerChore is noisy
> -
>
> Key: HBASE-20554
> URL: https://issues.apache.org/jira/browse/HBASE-20554
> Project: HBase
>  Issue Type: Bug
>Reporter: Andrew Purtell
>Priority: Minor
>
> WARN level "WALs outstanding" from CleanerChore should be DEBUG and are not 
> always correct. 
> I left a cluster configured for ITBLL (retaining all WALs for post hoc 
> analysis) and in the morning found the master log full of "WALs outstanding" 
> warnings from CleanerChore. 
> Should this really be a warning? Perhaps better logged at DEBUG level.
> {quote}
> 2018-05-09 16:42:03,893 WARN  
> [node-1.cluster,16000,1525851521469_ChoreService_2] cleaner.CleanerChore: 
> WALs outstanding under hdfs://node-1.cluster/hbase/oldWALs
> {quote}
> If someone has configured really long WAL retention then having WALs in 
> oldWALs will be normal. 
> Also, it seems the warning is sometimes incorrect.
> {quote}
> 2018-05-09 16:42:24,751 WARN  
> [node-1.cluster,16000,1525851521469_ChoreService_1] cleaner.CleanerChore: 
> WALs outstanding under hdfs://node-1.cluster/hbase/archive
> {quote}
> There are no WALs under archive/. 
> Even at DEBUG level, if it is not correct, then it can lead an operator to be 
> concerned about nothing, so better to just remove it.



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