impala-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vuk Ercegovac (Code Review)" <>
Subject [Impala-ASF-CR] IMPALA-4704: Turns on client connections when local catalog initialized.
Date Tue, 31 Oct 2017 07:19:57 GMT
Vuk Ercegovac has posted comments on this change. ( )

Change subject: IMPALA-4704: Turns on client connections when local catalog initialized.

Patch Set 16:

File be/src/service/impala-server.h:
PS16, Line 105: /// TODO: The state of a running query is currently not cleaned up if the
> Let's document the startup procedure and the reasoning behind it here
PS16, Line 1014:   /// Flag that records if backend and/or client services have been started.
> Clarify the meaning of "and/or" here. The distinction seems important. Will
clarified the comment.

we can use "is_ready", but I think of metrics as a view on internal state, so I'd prefer to
not have internal state depend on them. any preferences on the topic?
PS16, Line 1017:   boost::mutex services_started_lock_;
> std::atomic_bool instead of this lock?
File be/src/service/
PS16, Line 1626:   // Register this backend only if services have been started.
> Feels clearer to me to check this at the caller. Can be hard to reason abou
had it at the caller before-- agreed that its clearer there.
PS16, Line 1933: Status ImpalaServer::Init(int32_t thrift_be_port, int32_t beeswax_port,
> Why reformat fn args? Seemed ok the way it was.
File tests/custom_cluster/
PS16, Line 24:   """Impalad must wait for the catalog prior to opening up client ports.
> Specify the waiting condition more precisely. An impalad must wait for the 
PS16, Line 54:     self.expect_connection(self.cluster.impalads[0])
> Ideally we'd also check the internal service
added a comment when issuing a query. a query will catch two cases: (1) impalad registered
prematurely is caught by query fragment metrics and (2) query failure if the impalad registered
as a backend but could not run a fragment.
PS16, Line 59:   def test_query_subset(self):
> Can we combine this test wit the one above? They seem very similar
PS16, Line 71:     self.cluster.impalads[0].service.get_metric_value('impala-server.ready',
> I'm wondering whether this can be flaky. We often use self.wait_for_metric_

To view, visit
To unsubscribe, visit

Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I52b881cba18a7e4533e21a78751c2e35c3d4c8a6
Gerrit-Change-Number: 8202
Gerrit-PatchSet: 16
Gerrit-Owner: Vuk Ercegovac <>
Gerrit-Reviewer: Alex Behm <>
Gerrit-Reviewer: Balazs Jeszenszky <>
Gerrit-Reviewer: Dan Hecht <>
Gerrit-Reviewer: Dimitris Tsirogiannis <>
Gerrit-Reviewer: Michael Brown <>
Gerrit-Reviewer: Philip Zeyliger <>
Gerrit-Reviewer: Vuk Ercegovac <>
Gerrit-Comment-Date: Tue, 31 Oct 2017 07:19:57 +0000
Gerrit-HasComments: Yes

  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message