[jira] [Updated] (KUDU-1192) Periodically flush glog buffers from a thread
[ https://issues.apache.org/jira/browse/KUDU-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Lipcon updated KUDU-1192: -- Labels: newbie (was: ) > Periodically flush glog buffers from a thread > - > > Key: KUDU-1192 > URL: https://issues.apache.org/jira/browse/KUDU-1192 > Project: Kudu > Issue Type: Improvement >Reporter: Mike Percy > Labels: newbie > > If a tserver or master is started and there are no live tablets, glog will > buffer the output indefinitely which prevents startup messages from > appearing. This is confusing and might look like the server is hung. > There is a flag called --logbufsecs that controls how long glog will buffer > data before flushing, but it's lazy; if another log message doesn't come in > after that time, nothing will trigger the flush. There is no auto-flush > thread. > The solution is to run a thread that periodically flushes all of the logs by > calling google::FlushLogFiles(INFO). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (KUDU-1828) Add capability to rebalance tablets across tablet servers
[ https://issues.apache.org/jira/browse/KUDU-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Lipcon resolved KUDU-1828. --- Resolution: Duplicate Fix Version/s: n/a > Add capability to rebalance tablets across tablet servers > - > > Key: KUDU-1828 > URL: https://issues.apache.org/jira/browse/KUDU-1828 > Project: Kudu > Issue Type: New Feature > Components: consensus, ops-tooling, tablet >Reporter: Mike Percy > Fix For: n/a > > > It would be useful to be able to rebalance a list of tablets across a set of > tablet servers in the case that the distribution of tablets became very > imbalanced or a new tablet server was added to the cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (KUDU-1767) Reordering of client operations from the same KuduSession is possible
[ https://issues.apache.org/jira/browse/KUDU-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15813718#comment-15813718 ] Mike Percy edited comment on KUDU-1767 at 1/10/17 3:29 AM: --- After discussing this issue with a couple of folks, I am marking this issue Won't Fix for the following reasons: # This behavior does not violate strict serializability because we are talking about operations that occur simultaneously from Kudu's perspective. # There are workarounds for the observed behavior. Systems that want to write in a particular order can choose to flush one batch at a time to avoid reordering. If single-key ordering conflicts are the primary concern, care can also be taken by client programs to flush an update to a single key before apply()ing a following update to that key while still maintaining some parallelism at load time. was (Author: mpercy): After discussing this issue with a couple of folks, I am marking this issue Won't Fix for the following reasons: # This behavior does not violate strict serializability because we are talking about operations that occur simultaneously from Kudu's perspective. # There are workarounds for the observed behavior. For systems that want to write in a particular order, then can choose to flush one batch at a time to avoid reordering. If single-key ordering conflicts are the primary concern, care can also be taken by client programs to flush an update to a single key before apply()ing the following update to that key. > Reordering of client operations from the same KuduSession is possible > - > > Key: KUDU-1767 > URL: https://issues.apache.org/jira/browse/KUDU-1767 > Project: Kudu > Issue Type: Bug > Components: client, tablet >Affects Versions: 1.1.0 >Reporter: Mike Percy >Priority: Critical > Fix For: n/a > > > It is possible for client operations written via the same KuduSession to be > reordered on the server side in MANUAL_FLUSH and AUTO_BACKGROUND_FLUSH modes. > This violates our desired consistency guarantees. > This may occur because we allow concurrent flushes from the client for > throughput reasons and there is nothing enforcing the well-ordering of lock > acquisition from a single client session on the server side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (KUDU-1767) Reordering of client operations from the same KuduSession is possible
[ https://issues.apache.org/jira/browse/KUDU-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Percy resolved KUDU-1767. -- Resolution: Won't Fix Fix Version/s: n/a After discussing this issue with a couple of folks, I am marking this issue Won't Fix for the following reasons: # This behavior does not violate strict serializability because we are talking about operations that occur simultaneously from Kudu's perspective. # There are workarounds for the observed behavior. For systems that want to write in a particular order, then can choose to flush one batch at a time to avoid reordering. If single-key ordering conflicts are the primary concern, care can also be taken by client programs to flush an update to a single key before apply()ing the following update to that key. > Reordering of client operations from the same KuduSession is possible > - > > Key: KUDU-1767 > URL: https://issues.apache.org/jira/browse/KUDU-1767 > Project: Kudu > Issue Type: Bug > Components: client, tablet >Affects Versions: 1.1.0 >Reporter: Mike Percy >Priority: Critical > Fix For: n/a > > > It is possible for client operations written via the same KuduSession to be > reordered on the server side in MANUAL_FLUSH and AUTO_BACKGROUND_FLUSH modes. > This violates our desired consistency guarantees. > This may occur because we allow concurrent flushes from the client for > throughput reasons and there is nothing enforcing the well-ordering of lock > acquisition from a single client session on the server side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KUDU-1825) kudu-jepsen reports non-linearizable history for 'kill-all-tservers' scenario
[ https://issues.apache.org/jira/browse/KUDU-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Serbin updated KUDU-1825: Attachment: ts-5.log ts-4.log ts-3.log > kudu-jepsen reports non-linearizable history for 'kill-all-tservers' scenario > - > > Key: KUDU-1825 > URL: https://issues.apache.org/jira/browse/KUDU-1825 > Project: Kudu > Issue Type: Bug >Reporter: Alexey Serbin > Attachments: history.txt, linear.svg, master.log, ts-1.log, ts-2.log, > ts-3.log, ts-4.log, ts-5.log > > > One of the iterations of the kudu-jepsen test hit non-linearizable history of > opertions: http://sandbox.jenkins.cloudera.com/view/Kudu/job/kudu-jepsen/82/ > It's necessary to create a reproducible scenario for that and fix the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KUDU-1825) kudu-jepsen reports non-linearizable history for 'kill-all-tservers' scenario
[ https://issues.apache.org/jira/browse/KUDU-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Serbin updated KUDU-1825: Attachment: ts-2.log > kudu-jepsen reports non-linearizable history for 'kill-all-tservers' scenario > - > > Key: KUDU-1825 > URL: https://issues.apache.org/jira/browse/KUDU-1825 > Project: Kudu > Issue Type: Bug >Reporter: Alexey Serbin > Attachments: history.txt, linear.svg, master.log, ts-1.log, ts-2.log, > ts-3.log, ts-4.log, ts-5.log > > > One of the iterations of the kudu-jepsen test hit non-linearizable history of > opertions: http://sandbox.jenkins.cloudera.com/view/Kudu/job/kudu-jepsen/82/ > It's necessary to create a reproducible scenario for that and fix the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KUDU-1825) kudu-jepsen reports non-linearizable history for 'kill-all-tservers' scenario
[ https://issues.apache.org/jira/browse/KUDU-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Serbin updated KUDU-1825: Attachment: master.log > kudu-jepsen reports non-linearizable history for 'kill-all-tservers' scenario > - > > Key: KUDU-1825 > URL: https://issues.apache.org/jira/browse/KUDU-1825 > Project: Kudu > Issue Type: Bug >Reporter: Alexey Serbin > Attachments: history.txt, linear.svg, master.log, ts-1.log > > > One of the iterations of the kudu-jepsen test hit non-linearizable history of > opertions: http://sandbox.jenkins.cloudera.com/view/Kudu/job/kudu-jepsen/82/ > It's necessary to create a reproducible scenario for that and fix the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KUDU-1825) kudu-jepsen reports non-linearizable history for 'kill-all-tservers' scenario
[ https://issues.apache.org/jira/browse/KUDU-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Serbin updated KUDU-1825: Attachment: ts-1.log > kudu-jepsen reports non-linearizable history for 'kill-all-tservers' scenario > - > > Key: KUDU-1825 > URL: https://issues.apache.org/jira/browse/KUDU-1825 > Project: Kudu > Issue Type: Bug >Reporter: Alexey Serbin > Attachments: history.txt, linear.svg, master.log, ts-1.log > > > One of the iterations of the kudu-jepsen test hit non-linearizable history of > opertions: http://sandbox.jenkins.cloudera.com/view/Kudu/job/kudu-jepsen/82/ > It's necessary to create a reproducible scenario for that and fix the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KUDU-1829) Support cross-datacenter replication
Mike Percy created KUDU-1829: Summary: Support cross-datacenter replication Key: KUDU-1829 URL: https://issues.apache.org/jira/browse/KUDU-1829 Project: Kudu Issue Type: New Feature Components: consensus Reporter: Mike Percy We would like to ultimately support cross-datacenter replication. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KUDU-1828) Add capability to rebalance tablets across tablet servers
Mike Percy created KUDU-1828: Summary: Add capability to rebalance tablets across tablet servers Key: KUDU-1828 URL: https://issues.apache.org/jira/browse/KUDU-1828 Project: Kudu Issue Type: New Feature Components: consensus, ops-tooling, tablet Reporter: Mike Percy It would be useful to be able to rebalance a list of tablets across a set of tablet servers in the case that the distribution of tablets became very imbalanced or a new tablet server was added to the cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KUDU-1827) Add capability and tool to gracefully decommission a tablet server
[ https://issues.apache.org/jira/browse/KUDU-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Percy updated KUDU-1827: - Issue Type: New Feature (was: Bug) > Add capability and tool to gracefully decommission a tablet server > -- > > Key: KUDU-1827 > URL: https://issues.apache.org/jira/browse/KUDU-1827 > Project: Kudu > Issue Type: New Feature > Components: consensus, ops-tooling, tablet >Reporter: Mike Percy > > It would be useful to be able to decommission a tablet server gracefully, by > taking it out of the candidate for getting new tablets and re-replicating its > data to other servers before taking it out of tablet Raft configurations and > shutting it down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KUDU-1827) Add capability and tool to gracefully decommission a tablet server
Mike Percy created KUDU-1827: Summary: Add capability and tool to gracefully decommission a tablet server Key: KUDU-1827 URL: https://issues.apache.org/jira/browse/KUDU-1827 Project: Kudu Issue Type: Bug Components: consensus, ops-tooling, tablet Reporter: Mike Percy It would be useful to be able to decommission a tablet server gracefully, by taking it out of the candidate for getting new tablets and re-replicating its data to other servers before taking it out of tablet Raft configurations and shutting it down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (KUDU-100) Supporting RLE for 64-bit integer data types
[ https://issues.apache.org/jira/browse/KUDU-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Haijie Hong resolved KUDU-100. -- Resolution: Fixed Assignee: Haijie Hong Fix Version/s: 1.1.0 > Supporting RLE for 64-bit integer data types > > > Key: KUDU-100 > URL: https://issues.apache.org/jira/browse/KUDU-100 > Project: Kudu > Issue Type: New Feature > Components: cfile, util >Affects Versions: Backlog >Reporter: Alex Feinberg >Assignee: Haijie Hong > Fix For: 1.1.0 > > > Currently RLE encoder does not handle 64-bit integer data types: this is due > to the fact that BitReader/BitWriter do not handle bit widths over 32 bits. > This should be possible to (preferably) fix at BitReader/BitWriter level or > work around at RleEncoder level. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KUDU-1826) timestamp propagation APIs missing from synchronous Java client
Todd Lipcon created KUDU-1826: - Summary: timestamp propagation APIs missing from synchronous Java client Key: KUDU-1826 URL: https://issues.apache.org/jira/browse/KUDU-1826 Project: Kudu Issue Type: Improvement Components: client Affects Versions: 1.2.0 Reporter: Todd Lipcon The sync Java client (KuduClient) doesn't seem to have APIs available for getting or setting the propagated timestamp. It also seems like the APIs are currently using 'long' which is going to be problematic when we implement KUDU-611. Instead we should have a "token"-based API which returns and takes an opaque byte[]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KUDU-1825) kudu-jepsen reports non-linearizable history for 'kill-all-tservers' scenario
[
https://issues.apache.org/jira/browse/KUDU-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15813237#comment-15813237
]
Alexey Serbin commented on KUDU-1825:
-
Thank you for attaching those files already.
I'm carving out the appropriate parts of the kudu-tserver and kudu-master logs.
Will update the script to put those into archive of the kudu-jenkins job
artifacts.
>From the {{history.txt}}, the following snippet correspond to the operations
>in the SVG file (spanning between '1 :invoke :write 7' and '1 :ok :write 7'):
{noformat}
1 :invoke :write 7
5 :invoke :read nil
2 :invoke :write 4
4 :invoke :read nil
9 :invoke :read nil
0 :invoke :read nil
:nemesis:info :start {"aserbin-kudu-jepsen-ts-1.gce.cloudera.com"
[:killed :kudu-tserver], "aserbin-kudu-jepsen-ts-5.gce.cloudera.com" [:killed
:kudu-tserver], "aserbin-kudu-jepsen-ts-2.gce.cloudera.com" [:killed
:kudu-tserver], "aserbin-kudu-jepsen-ts-3.gce.cloudera.com" [:killed
:kudu-tserver], "aserbin-kudu-jepsen-ts-4.gce.cloudera.com" [:killed
:kudu-tserver]}
3 :invoke :write 8
:nemesis:info :stop nil
9 :ok :read 2
8 :ok :read 2
:nemesis:info :stop {"aserbin-kudu-jepsen-ts-1.gce.cloudera.com"
[:started :kudu-tserver], "aserbin-kudu-jepsen-ts-5.gce.cloudera.com" [:started
:kudu-tserver], "aserbin-kudu-jepsen-ts-2.gce.cloudera.com" [:started
:kudu-tserver], "aserbin-kudu-jepsen-ts-3.gce.cloudera.com" [:started
:kudu-tserver], "aserbin-kudu-jepsen-ts-4.gce.cloudera.com" [:started
:kudu-tserver]}
9 :invoke :read nil
9 :ok :read 2
8 :invoke :read nil
8 :ok :read 2
9 :invoke :read nil
9 :ok :read 2
8 :invoke :read nil
8 :ok :read 2
8 :invoke :read nil
8 :ok :read 2
7 :ok :read 2
9 :invoke :read nil
9 :ok :read 2
6 :ok :read 2
0 :ok :read 2
0 :invoke :write 3
6 :invoke :read nil
6 :ok :read 2
8 :invoke :read nil
8 :ok :read 2
7 :invoke :read nil
7 :ok :read 2
9 :invoke :read nil
9 :ok :read 2
4 :ok :read 2
8 :invoke :read nil
8 :ok :read 2
9 :invoke :read nil
9 :ok :read 2
5 :ok :read 2
4 :invoke :read nil
4 :ok :read 2
8 :invoke :read nil
8 :ok :read 2
9 :invoke :read nil
9 :ok :read 2
6 :invoke :read nil
6 :ok :read 2
7 :invoke :read nil
7 :ok :read 2
9 :invoke :read nil
9 :ok :read 2
5 :invoke :read nil
5 :ok :read 2
4 :invoke :read nil
4 :ok :read 2
2 :ok :write 4
8 :invoke :read nil
8 :ok :read 2
6 :invoke :read nil
6 :ok :read 2
7 :invoke :read nil
7 :ok :read 2
7 :invoke :read nil
7 :ok :read 2
9 :invoke :read nil
9 :ok :read 2
8 :invoke :read nil
8 :ok :read 2
6 :invoke :read nil
6 :ok :read 2
5 :invoke :read nil
5 :ok :read 2
8 :invoke :read nil
8 :ok :read 2
4 :invoke :read nil
4 :ok :read 2
4 :invoke :read nil
4 :ok :read 2
7 :invoke :read nil
7 :ok :read 2
2 :invoke :write 4
2 :ok :write 4
8 :invoke :read nil
8 :ok :read 2
9 :invoke :read nil
9 :ok :read 2
6 :invoke :read nil
6 :ok :read 2
5 :invoke :read nil
5 :ok :read 2
2 :invoke :read nil
2 :ok :read 4
4 :invoke :write 0
9 :invoke :read nil
9 :ok :read 2
9 :invoke :read nil
9 :ok :read 2
7 :invoke :read nil
7 :ok :read 2
8 :invoke :read nil
8 :ok :read 2
2 :invoke :write 5
2 :ok :write 5
6 :invoke :read nil
6 :ok :read 2
9 :invoke :read nil
9 :ok :read 2
5 :invoke :read nil
5 :ok :read 2
9 :invoke :read nil
9 :ok :read 2
2 :invoke :write 7
2 :ok :write 7
6 :invoke :read nil
6 :ok :read 2
7 :invoke :read nil
7 :ok :read 2
6 :invoke :read nil
6 :ok :read 2
5 :invoke :read nil
5 :ok :read 2
2 :invoke :read nil
2 :ok :read 7
5 :invoke :read nil
5 :ok :read 2
5 :invoke :read nil
5 :ok :read 2
8 :invoke :read nil
8 :ok :read 2
8 :invoke :read nil
8 :ok :read 2
2 :invoke :read nil
2 :ok :read
[jira] [Updated] (KUDU-1825) kudu-jepsen reports non-linearizable history for 'kill-all-tservers' scenario
[ https://issues.apache.org/jira/browse/KUDU-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Lipcon updated KUDU-1825: -- Attachment: history.txt linear.svg Attaching the SVG and history file for this run. >From my understanding of these, it looks like somehow we are reading a value >'2' even though we never wrote that value. The '2' must be leftover from an >earlier test run or somesuch, and perhaps shows up as readable just after the >servers restart. Merits further investigation. > kudu-jepsen reports non-linearizable history for 'kill-all-tservers' scenario > - > > Key: KUDU-1825 > URL: https://issues.apache.org/jira/browse/KUDU-1825 > Project: Kudu > Issue Type: Bug >Reporter: Alexey Serbin > Attachments: history.txt, linear.svg > > > One of the iterations of the kudu-jepsen test hit non-linearizable history of > opertions: http://sandbox.jenkins.cloudera.com/view/Kudu/job/kudu-jepsen/82/ > It's necessary to create a reproducible scenario for that and fix the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KUDU-1825) kudu-jepsen reports non-linearizable history for 'kill-all-tservers' scenario
[ https://issues.apache.org/jira/browse/KUDU-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15813148#comment-15813148 ] Todd Lipcon commented on KUDU-1825: --- Can you upload or paste relevant logs into this JIRA so that contributors without access to internal Cloudera jenkins can take a look? > kudu-jepsen reports non-linearizable history for 'kill-all-tservers' scenario > - > > Key: KUDU-1825 > URL: https://issues.apache.org/jira/browse/KUDU-1825 > Project: Kudu > Issue Type: Bug >Reporter: Alexey Serbin > > One of the iterations of the kudu-jepsen test hit non-linearizable history of > opertions: http://sandbox.jenkins.cloudera.com/view/Kudu/job/kudu-jepsen/82/ > It's necessary to create a reproducible scenario for that and fix the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KUDU-1825) kudu-jepsen reports non-linearizable history for 'kill-all-tservers' scenario
Alexey Serbin created KUDU-1825: --- Summary: kudu-jepsen reports non-linearizable history for 'kill-all-tservers' scenario Key: KUDU-1825 URL: https://issues.apache.org/jira/browse/KUDU-1825 Project: Kudu Issue Type: Bug Reporter: Alexey Serbin One of the iterations of the kudu-jepsen test hit non-linearizable history of opertions: http://sandbox.jenkins.cloudera.com/view/Kudu/job/kudu-jepsen/82/ It's necessary to create a reproducible scenario for that and fix the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KUDU-1504) Add a tool to force a Raft config change
[ https://issues.apache.org/jira/browse/KUDU-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15812824#comment-15812824 ] Dinesh Bhat commented on KUDU-1504: --- Isn't KUDU-1721 meant to address this as a 'feature' ? Do you see KUDU-1721, KUDU-1330 and this JIRA as 3 independent work items ? > Add a tool to force a Raft config change > > > Key: KUDU-1504 > URL: https://issues.apache.org/jira/browse/KUDU-1504 > Project: Kudu > Issue Type: New Feature > Components: consensus, ops-tooling >Affects Versions: 0.9.0 >Reporter: Mike Percy > > It would be useful to implement a tool that allowed for an > administrator-controlled "forced" configuration change. This type of thing is > useful as a "parachute" if, for example, 2 nodes of a 3-node configuration > were permanently offline. An administrator may wish to accept whatever > potential data loss occurred and force the configuration to be composed of a > single node so that it could come back online and then grown back to a larger > configuration size again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KUDU-1643) Prune hash partitions based on IN-list predicates
[ https://issues.apache.org/jira/browse/KUDU-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15812590#comment-15812590 ] Dan Burkert commented on KUDU-1643: --- [~honghaijie] just contributed this to the C++ side in ab76440e9c244. Once the Java version is fixed up similarly we can close this out. > Prune hash partitions based on IN-list predicates > - > > Key: KUDU-1643 > URL: https://issues.apache.org/jira/browse/KUDU-1643 > Project: Kudu > Issue Type: Sub-task > Components: client, tablet >Reporter: Dan Burkert >Assignee: Haijie Hong > > KUDU-1363 is adding support for IN-list predicates, but neither the C++ > client or Java client takes advantage of IN-list predicates for pruning hash > partitions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KUDU-1771) Java client "connection refused" errors logged as "connection reset"
[ https://issues.apache.org/jira/browse/KUDU-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15812412#comment-15812412 ] Jean-Daniel Cryans commented on KUDU-1771: -- Yeah that seems fine, "connection reset" acts like a catchall error message but it does seem like we could be more specific based on the caller site context. > Java client "connection refused" errors logged as "connection reset" > > > Key: KUDU-1771 > URL: https://issues.apache.org/jira/browse/KUDU-1771 > Project: Kudu > Issue Type: Improvement > Components: client >Affects Versions: 1.1.0 >Reporter: Todd Lipcon > > When the Java client tries to connect to a server which is down, it generates > an error string like: org.apache.kudu.client.RecoverableException: [Peer Kudu > Master - vd0340.halxg.cloudera.com:7051] Connection reset > This makes it sound like it connected and got disconnected, when in fact that > host was not listening at all. This misleads the user when they try to > troubleshoot the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
