[jira] [Commented] (HBASE-6323) [replication] most of the source metrics are wrong when there's multiple slaves
[
https://issues.apache.org/jira/browse/HBASE-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13411021#comment-13411021
]
Elliott Clark commented on HBASE-6323:
--
Hold off on committing this. It looks like the metrics2 in hadoop2 is
incompatible with the metrics2 in hadoop1.
[replication] most of the source metrics are wrong when there's multiple
slaves
---
Key: HBASE-6323
URL: https://issues.apache.org/jira/browse/HBASE-6323
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.1, 0.94.0
Reporter: Jean-Daniel Cryans
Assignee: Elliott Clark
Fix For: 0.96.0, 0.94.2
Attachments: HBASE-6323-0.patch, HBASE-6323-1.patch,
HBASE-6323-2.patch
Most of the metrics in replication were written with 1 slave in mind but with
multiple slaves the issue really shows. Most of the metrics are set directly:
{code}
public void enqueueLog(Path log) {
this.queue.put(log);
this.metrics.sizeOfLogQueue.set(queue.size());
}
{code}
So {{sizeOfLogQueue}} is always showing the size of the queue that updated
the metric last.
I'm not sure what's the right way to fix this since we can't have dynamic
metrics. Merging them would work here but it wouldn't work so well with
{{ageOfLastShippedOp}} since the age can be different and it definitely
cannot be summed.
Assigning to Elliott since he seems to dig metrics these days.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6323) [replication] most of the source metrics are wrong when there's multiple slaves
[
https://issues.apache.org/jira/browse/HBASE-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13409868#comment-13409868
]
stack commented on HBASE-6323:
--
Looks good Mr. Elliott. Will give J-D honor of blessing it. I like your
moving classes under metrics package. Where is the bit where we deal w/
multiple slaves? Thats in one of the moved classes? Good stuff.
[replication] most of the source metrics are wrong when there's multiple
slaves
---
Key: HBASE-6323
URL: https://issues.apache.org/jira/browse/HBASE-6323
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.1, 0.94.0
Reporter: Jean-Daniel Cryans
Assignee: Elliott Clark
Fix For: 0.96.0, 0.94.2
Attachments: HBASE-6323-0.patch, HBASE-6323-1.patch
Most of the metrics in replication were written with 1 slave in mind but with
multiple slaves the issue really shows. Most of the metrics are set directly:
{code}
public void enqueueLog(Path log) {
this.queue.put(log);
this.metrics.sizeOfLogQueue.set(queue.size());
}
{code}
So {{sizeOfLogQueue}} is always showing the size of the queue that updated
the metric last.
I'm not sure what's the right way to fix this since we can't have dynamic
metrics. Merging them would work here but it wouldn't work so well with
{{ageOfLastShippedOp}} since the age can be different and it definitely
cannot be summed.
Assigning to Elliott since he seems to dig metrics these days.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6323) [replication] most of the source metrics are wrong when there's multiple slaves
[
https://issues.apache.org/jira/browse/HBASE-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13409875#comment-13409875
]
Elliott Clark commented on HBASE-6323:
--
Yes. The ReplicationSourceMetric class adds values to a global gauge and to a
gauge for just that source. When a source is stopped the values are subtracted
from the global gauge and the gauge for just that source is removed. Counters
are not subtracted since they represent things like the total number of log
edits shipped out and removing them doesn't really make sense.
Since there's only one sink ReplicationSinkMetrics doesn't really have that.
[replication] most of the source metrics are wrong when there's multiple
slaves
---
Key: HBASE-6323
URL: https://issues.apache.org/jira/browse/HBASE-6323
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.1, 0.94.0
Reporter: Jean-Daniel Cryans
Assignee: Elliott Clark
Fix For: 0.96.0, 0.94.2
Attachments: HBASE-6323-0.patch, HBASE-6323-1.patch
Most of the metrics in replication were written with 1 slave in mind but with
multiple slaves the issue really shows. Most of the metrics are set directly:
{code}
public void enqueueLog(Path log) {
this.queue.put(log);
this.metrics.sizeOfLogQueue.set(queue.size());
}
{code}
So {{sizeOfLogQueue}} is always showing the size of the queue that updated
the metric last.
I'm not sure what's the right way to fix this since we can't have dynamic
metrics. Merging them would work here but it wouldn't work so well with
{{ageOfLastShippedOp}} since the age can be different and it definitely
cannot be summed.
Assigning to Elliott since he seems to dig metrics these days.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6323) [replication] most of the source metrics are wrong when there's multiple slaves
[
https://issues.apache.org/jira/browse/HBASE-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13409881#comment-13409881
]
stack commented on HBASE-6323:
--
I'm +1 then.
[replication] most of the source metrics are wrong when there's multiple
slaves
---
Key: HBASE-6323
URL: https://issues.apache.org/jira/browse/HBASE-6323
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.1, 0.94.0
Reporter: Jean-Daniel Cryans
Assignee: Elliott Clark
Fix For: 0.96.0, 0.94.2
Attachments: HBASE-6323-0.patch, HBASE-6323-1.patch
Most of the metrics in replication were written with 1 slave in mind but with
multiple slaves the issue really shows. Most of the metrics are set directly:
{code}
public void enqueueLog(Path log) {
this.queue.put(log);
this.metrics.sizeOfLogQueue.set(queue.size());
}
{code}
So {{sizeOfLogQueue}} is always showing the size of the queue that updated
the metric last.
I'm not sure what's the right way to fix this since we can't have dynamic
metrics. Merging them would work here but it wouldn't work so well with
{{ageOfLastShippedOp}} since the age can be different and it definitely
cannot be summed.
Assigning to Elliott since he seems to dig metrics these days.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6323) [replication] most of the source metrics are wrong when there's multiple slaves
[
https://issues.apache.org/jira/browse/HBASE-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13409953#comment-13409953
]
Jean-Daniel Cryans commented on HBASE-6323:
---
I did a review with Elliott, basically there's 3 Copyright 2010 to remove and
ReplicationMetricsSource needs some refactoring because right now there's 3
methods that are almost identical.
[replication] most of the source metrics are wrong when there's multiple
slaves
---
Key: HBASE-6323
URL: https://issues.apache.org/jira/browse/HBASE-6323
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.1, 0.94.0
Reporter: Jean-Daniel Cryans
Assignee: Elliott Clark
Fix For: 0.96.0, 0.94.2
Attachments: HBASE-6323-0.patch, HBASE-6323-1.patch
Most of the metrics in replication were written with 1 slave in mind but with
multiple slaves the issue really shows. Most of the metrics are set directly:
{code}
public void enqueueLog(Path log) {
this.queue.put(log);
this.metrics.sizeOfLogQueue.set(queue.size());
}
{code}
So {{sizeOfLogQueue}} is always showing the size of the queue that updated
the metric last.
I'm not sure what's the right way to fix this since we can't have dynamic
metrics. Merging them would work here but it wouldn't work so well with
{{ageOfLastShippedOp}} since the age can be different and it definitely
cannot be summed.
Assigning to Elliott since he seems to dig metrics these days.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6323) [replication] most of the source metrics are wrong when there's multiple slaves
[
https://issues.apache.org/jira/browse/HBASE-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13408447#comment-13408447
]
Jean-Daniel Cryans commented on HBASE-6323:
---
Looks like it's the right way to go.
[replication] most of the source metrics are wrong when there's multiple
slaves
---
Key: HBASE-6323
URL: https://issues.apache.org/jira/browse/HBASE-6323
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.1, 0.94.0
Reporter: Jean-Daniel Cryans
Assignee: Elliott Clark
Fix For: 0.96.0, 0.94.2
Attachments: HBASE-6323-0.patch
Most of the metrics in replication were written with 1 slave in mind but with
multiple slaves the issue really shows. Most of the metrics are set directly:
{code}
public void enqueueLog(Path log) {
this.queue.put(log);
this.metrics.sizeOfLogQueue.set(queue.size());
}
{code}
So {{sizeOfLogQueue}} is always showing the size of the queue that updated
the metric last.
I'm not sure what's the right way to fix this since we can't have dynamic
metrics. Merging them would work here but it wouldn't work so well with
{{ageOfLastShippedOp}} since the age can be different and it definitely
cannot be summed.
Assigning to Elliott since he seems to dig metrics these days.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6323) [replication] most of the source metrics are wrong when there's multiple slaves
[
https://issues.apache.org/jira/browse/HBASE-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406107#comment-13406107
]
Elliott Clark commented on HBASE-6323:
--
bq.I'm not sure what's the right way to fix this since we can't have dynamic
metrics
We can. They are just annoying to make. But I think something like what we
have with regions is probably the right thing. A dynamic set for every source
and a rollup.
[replication] most of the source metrics are wrong when there's multiple
slaves
---
Key: HBASE-6323
URL: https://issues.apache.org/jira/browse/HBASE-6323
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.1, 0.94.0
Reporter: Jean-Daniel Cryans
Assignee: Elliott Clark
Fix For: 0.96.0, 0.94.2
Most of the metrics in replication were written with 1 slave in mind but with
multiple slaves the issue really shows. Most of the metrics are set directly:
{code}
public void enqueueLog(Path log) {
this.queue.put(log);
this.metrics.sizeOfLogQueue.set(queue.size());
}
{code}
So {{sizeOfLogQueue}} is always showing the size of the queue that updated
the metric last.
I'm not sure what's the right way to fix this since we can't have dynamic
metrics. Merging them would work here but it wouldn't work so well with
{{ageOfLastShippedOp}} since the age can be different and it definitely
cannot be summed.
Assigning to Elliott since he seems to dig metrics these days.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
