impala-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Kornacker (Code Review)" <>
Subject [Impala-ASF-CR] IMPALA-4856: Port ImpalaInternalService to KRPC
Date Tue, 25 Apr 2017 03:23:20 GMT
Marcel Kornacker has posted comments on this change.

Change subject: IMPALA-4856: Port ImpalaInternalService to KRPC

Patch Set 5:

File be/src/runtime/data-stream-mgr.h:

Line 77: /// After the first batch has been received, the sender continues to send batches,
one at
> No, for a couple of reasons:
follow-on questions:
- should the queue be sized in terms of bytes or rows/row batches? the latter would probably
lead to steadier behavior
- regarding point 2: with correct flow control, i don't see how the receiver stalling would
still allow the senders to fill up the queue.

let's talk in person tomorrow, rather than a back & forth over comments.

Line 84: /// notified when the batch has been processed, or added to the batch queue,
> I'm not sure which part you're referring to - but yes, in general this is h
let's discuss tomorrow, i'm wondering if this feature can be avoided.

Line 131: /// is reached, the RPC will be considered failed, and the channel and sender will
> In the queued batch case, we could look to see if the queue had any more ca
i think we should size the queue in terms of batches, not total bytes. the sender itself can
keep track of total bytes.

Line 245:   /// If the stream would exceed its buffering limit as a result of queuing this
> I feel that rvalues do make ownership explicit. You can't pass a non-tempor
i think this is inferior to passing a pointer to the context and stipulating that the caller
becomes the owner. also, move() is still more expensive than passing a pointer, and also more
opaque (you don't know what's getting copied, unless you know the details of every field in
the struct).

i really don't see any upside to a move() here.
File be/src/runtime/data-stream-mgr.h:

Line 124: /// execution. Senders do not block in TransmitData() RPCs, and may be cancelled
at any
what do you mean, they don't block in transmitdata rpcs? they have to wait for a response,

Line 133: /// stream to continue correct operation.
where did the 120s come from again?

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: I95229290566a8ccffd80ed2d74c1c57cf1479238
Gerrit-PatchSet: 5
Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-Owner: Henry Robinson <>
Gerrit-Reviewer: Anonymous Coward #168
Gerrit-Reviewer: Henry Robinson <>
Gerrit-Reviewer: Marcel Kornacker <>
Gerrit-Reviewer: Sailesh Mukil <>
Gerrit-HasComments: Yes

View raw message