cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Williams (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5302) Fix nodetool ring and status output format for IPv6 addresses
Date Mon, 04 Mar 2013 17:09:13 GMT


Brandon Williams commented on CASSANDRA-5302:

To be pedantic in return, this breaks the case where any ipv4/6 string representation isn't
uniform across the nodes.  For instance:

{noformat}  rack1       Up     Normal  70.02 KB        33.33%              -3074457345618258603
                rack1       Up     Normal  45.96 KB        33.33%              3074457345618258602
                 rack1       Up     Normal  57.91 KB        33.33%              -9223372036854775808

The middle address has one more character in the third quad, so it is offset by one.
> Fix nodetool ring and status output format for IPv6 addresses
> -------------------------------------------------------------
>                 Key: CASSANDRA-5302
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Tools
>            Reporter: Michał Michalski
>            Assignee: Michał Michalski
>            Priority: Trivial
>         Attachments: 5302.patch
> My pedantic nature can't stand having unaligned columns in nodetool outputs, which happens
when IP addresses are IPv6 ones:
> {noformat}michal@aperture$ nodetool -h myhost status
> Datacenter: DC1
> ==================
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> --  Address           Load       Owns (effective)  Host ID                          
    Token                                    Rack
> UN  2001:3c27:21:166:0:1:2:7  331.65 GB  100,0%            d557fb83-72f2-4e92-9f26-de6c788aada5
 85070591730234615865843651857942052864   rack2
> UN  2001:3c27:21:166:0:1:1:7  328.8 GB   100,0%            0461a4bf-97a6-447d-9d06-3b42ad1f702c
 0                                        rack1
> {noformat}
> I'm attaching a patch that fixes this problem for nodetool status / ring commands. It
does it by picking first item in nodes list (for nodetool ring it's first node in general,
for nodetool status it's first node in each DC) and uses its length as a field length for
> It bases on assumptions that it's imppossible to have 0 nodes in cluster/DC and the lenghts
of addresses are "similar". The alternative I'm considering too is finding the longest address
- it will be 100% accurate.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message