Hi Lucas, Thanks for updating the wiki. The updated motivation description looks good to me. One additional benefit of having a separate port for controller messages is that we can protect the control plane with something like IP table.
Reading the proposed change a bit more, I found it is a little weird to add the endpoints_for_controller section. It seems we only need to add a new endpoint named CONTROLLER to the endpoints section, and also add the corresponding protocol mapping to the listener security protocol map section. In the broker config, the listener-for-controller should just be listener-name-for-controller which is CONTROLLER. Another minor thing is that, in the "How can a controller learn about the dedicated endpoints exposed by brokers" section, you said For instance, with the sample json payload listed above, if the controller first determines inter-broker-lister-name to be "INTERNAL", then it knows to use the host name "host1.example.com", port 9093 and the security protocol PLAINTEXT to connect to the broker. should the port be 9092 instead? Thanks, Jiangjie (Becket) Qin On Tue, Aug 14, 2018 at 5:06 AM, Lucas Wang <lucasatu...@gmail.com> wrote: > @Becket > > Makes sense. I've updated the KIP by adding the following paragraph to the > motivation section > > > Today there is no separate between controller requests and regular data > > plane requests. Specifically (1) a controller in a cluster uses the same > > advertised endpoints to connect to brokers as what clients and regular > > brokers use for exchanging data (2) on the broker side, the same network > > (processor) thread could be multiplexed by handling a controller > connection > > and many other data plane connections (3) after a controller request is > > read from the socket, it is enqueued into the single FIFO requestQueue, > > which is used for all types of requests (4) request handler threads poll > > requests from the requestQueue and handles the controller requests with > the > > same priority as regular data requests. > > > > Because of the multiplexing at every stage of request handling, > controller > > requests could be significantly delayed under the following scenarios: > > > > 1. The requestQueue is full, and therefore blocks a network > > (processor) thread that has read a controller request from the socket. > > 2. A controller request is enqueued into the requestQueue after a > > backlog of data requests, and experiences a long queuing time in the > > requestQueue. > > > > > Please let me know if that looks ok or any other change you'd like to make. > Thanks! > > Lucas > > On Mon, Aug 13, 2018 at 6:33 AM, Becket Qin <becket....@gmail.com> wrote: > > > Hi Lucas, > > > > Thanks for the explanation. It might be a nitpick, but it seems better to > > mention in the motivation part that today the client requests and > > controller requests are not only sharing the same queue, but also a bunch > > of things else, so that we can avoid asking people to read the rejected > > alternatives. > > > > Thanks, > > > > Jiangjie (Becket) Qin > > > > > > > > > > > > > > > > On Fri, Aug 10, 2018 at 6:23 AM, Lucas Wang <lucasatu...@gmail.com> > wrote: > > > > > @Becket, > > > > > > I've asked for review by Jun and Joel in the vote thread. > > > Regarding the separate thread and port, I did talk about it in the > > rejected > > > alternative design 1. > > > Please let me know if you'd like more elaboration or moving it to the > > > motivation, etc. > > > > > > Thanks, > > > Lucas > > > > > > On Wed, Aug 8, 2018 at 3:59 PM, Becket Qin <becket....@gmail.com> > wrote: > > > > > > > Hi Lucas, > > > > > > > > Yes, a separate Jira is OK. > > > > > > > > Since the proposal has significantly changed since the initial vote > > > > started. We probably should let the others who have already voted > know > > > and > > > > ensure they are happy with the updated proposal. > > > > Also, it seems the motivation part of the KIP wiki is still just > > talking > > > > about the separate queue and not fully cover the changes we make now, > > > e.g. > > > > separate thread, port, etc. We might want to explain a bit more so > for > > > > people who did not follow the discussion mail thread also understand > > the > > > > whole proposal. > > > > > > > > Thanks, > > > > > > > > Jiangjie (Becket) Qin > > > > > > > > On Wed, Aug 8, 2018 at 12:44 PM, Lucas Wang <lucasatu...@gmail.com> > > > wrote: > > > > > > > > > Hi Becket, > > > > > > > > > > Thanks for the review. The current write up in the KIP won’t change > > the > > > > > ordering behavior. Are you ok with addressing that as a separate > > > > > independent issue (I’ll create a separate ticket for it)? > > > > > If so, can you please give me a +1 on the vote thread? > > > > > > > > > > Thanks, > > > > > Lucas > > > > > > > > > > On Tue, Aug 7, 2018 at 7:34 PM Becket Qin <becket....@gmail.com> > > > wrote: > > > > > > > > > > > Thanks for the updated KIP wiki, Lucas. Looks good to me overall. > > > > > > > > > > > > It might be an implementation detail, but do we still plan to use > > the > > > > > > correlation id to ensure the request processing order? > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Jiangjie (Becket) Qin > > > > > > > > > > > > On Tue, Jul 31, 2018 at 3:39 AM, Lucas Wang < > lucasatu...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > > > Thanks for your review, Dong. > > > > > > > Ack that these configs will have a bigger impact for users. > > > > > > > > > > > > > > On the other hand, I would argue that the request queue > becoming > > > full > > > > > > > may or may not be a rare scenario. > > > > > > > How often the request queue gets full depends on the request > > > incoming > > > > > > rate, > > > > > > > the request processing rate, and the size of the request queue. > > > > > > > When that happens, the dedicated endpoints design can better > > handle > > > > > > > it than any of the previously discussed options. > > > > > > > > > > > > > > Another reason I made the change was that I have the same taste > > > > > > > as Becket that it's a better separation of the control plane > from > > > the > > > > > > data > > > > > > > plane. > > > > > > > > > > > > > > Finally, I want to clarify that this change is NOT motivated by > > the > > > > > > > out-of-order > > > > > > > processing discussion. The latter problem is orthogonal to this > > > KIP, > > > > > and > > > > > > it > > > > > > > can happen in any of the design options we discussed for this > KIP > > > so > > > > > far. > > > > > > > So I'd like to address out-of-order processing separately in > > > another > > > > > > > thread, > > > > > > > and avoid mentioning it in this KIP. > > > > > > > > > > > > > > Thanks, > > > > > > > Lucas > > > > > > > > > > > > > > On Fri, Jul 27, 2018 at 7:51 PM, Dong Lin <lindon...@gmail.com > > > > > > wrote: > > > > > > > > > > > > > > > Hey Lucas, > > > > > > > > > > > > > > > > Thanks for the update. > > > > > > > > > > > > > > > > The current KIP propose new broker configs > > > > "listeners.for.controller" > > > > > > and > > > > > > > > "advertised.listeners.for.controller". This is going to be a > > big > > > > > change > > > > > > > > since listeners are among the most important configs that > every > > > > user > > > > > > > needs > > > > > > > > to change. According to the rejected alternative section, it > > > seems > > > > > that > > > > > > > the > > > > > > > > reason to add these two configs is to improve performance > when > > > the > > > > > data > > > > > > > > request queue is full rather than for correctness. It should > > be a > > > > > very > > > > > > > rare > > > > > > > > scenario and I am not sure we should add configs for all > users > > > just > > > > > to > > > > > > > > improve the performance in such rare scenario. > > > > > > > > > > > > > > > > Also, if the new design is based on the issues which are > > > discovered > > > > > in > > > > > > > the > > > > > > > > recent discussion, e.g. out of order processing if we don't > > use a > > > > > > > dedicated > > > > > > > > thread for controller request, it may be useful to explain > the > > > > > problem > > > > > > in > > > > > > > > the motivation section. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Dong > > > > > > > > > > > > > > > > On Fri, Jul 27, 2018 at 1:28 PM, Lucas Wang < > > > lucasatu...@gmail.com > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > A kind reminder for review of this KIP. > > > > > > > > > > > > > > > > > > Thank you very much! > > > > > > > > > Lucas > > > > > > > > > > > > > > > > > > On Wed, Jul 25, 2018 at 10:23 PM, Lucas Wang < > > > > > lucasatu...@gmail.com> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > I've updated the KIP by adding the dedicated endpoints > for > > > > > > controller > > > > > > > > > > connections, > > > > > > > > > > and pinning threads for controller requests. > > > > > > > > > > Also I've updated the title of this KIP. Please take a > look > > > and > > > > > let > > > > > > > me > > > > > > > > > > know your feedback. > > > > > > > > > > > > > > > > > > > > Thanks a lot for your time! > > > > > > > > > > Lucas > > > > > > > > > > > > > > > > > > > > On Tue, Jul 24, 2018 at 10:19 AM, Mayuresh Gharat < > > > > > > > > > > gharatmayures...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > >> Hi Lucas, > > > > > > > > > >> I agree, if we want to go forward with a separate > > controller > > > > > plane > > > > > > > and > > > > > > > > > >> data > > > > > > > > > >> plane and completely isolate them, having a separate > port > > > for > > > > > > > > controller > > > > > > > > > >> with a separate Acceptor and a Processor sounds ideal to > > me. > > > > > > > > > >> > > > > > > > > > >> Thanks, > > > > > > > > > >> > > > > > > > > > >> Mayuresh > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> On Mon, Jul 23, 2018 at 11:04 PM Becket Qin < > > > > > becket....@gmail.com > > > > > > > > > > > > > > > > wrote: > > > > > > > > > >> > > > > > > > > > >> > Hi Lucas, > > > > > > > > > >> > > > > > > > > > > >> > Yes, I agree that a dedicated end to end control flow > > > would > > > > be > > > > > > > > ideal. > > > > > > > > > >> > > > > > > > > > > >> > Thanks, > > > > > > > > > >> > > > > > > > > > > >> > Jiangjie (Becket) Qin > > > > > > > > > >> > > > > > > > > > > >> > On Tue, Jul 24, 2018 at 1:05 PM, Lucas Wang < > > > > > > > lucasatu...@gmail.com> > > > > > > > > > >> wrote: > > > > > > > > > >> > > > > > > > > > > >> > > Thanks for the comment, Becket. > > > > > > > > > >> > > So far, we've been trying to avoid making any > request > > > > > handler > > > > > > > > thread > > > > > > > > > >> > > special. > > > > > > > > > >> > > But if we were to follow that path in order to make > > the > > > > two > > > > > > > planes > > > > > > > > > >> more > > > > > > > > > >> > > isolated, > > > > > > > > > >> > > what do you think about also having a dedicated > > > processor > > > > > > > thread, > > > > > > > > > >> > > and dedicated port for the controller? > > > > > > > > > >> > > > > > > > > > > > >> > > Today one processor thread can handle multiple > > > > connections, > > > > > > > let's > > > > > > > > > say > > > > > > > > > >> 100 > > > > > > > > > >> > > connections > > > > > > > > > >> > > > > > > > > > > > >> > > represented by connection0, ... connection99, among > > > which > > > > > > > > > >> connection0-98 > > > > > > > > > >> > > are from clients, while connection99 is from > > > > > > > > > >> > > > > > > > > > > > >> > > the controller. Further let's say after one selector > > > > > polling, > > > > > > > > there > > > > > > > > > >> are > > > > > > > > > >> > > incoming requests on all connections. > > > > > > > > > >> > > > > > > > > > > > >> > > When the request queue is full, (either the data > > request > > > > > being > > > > > > > > full > > > > > > > > > in > > > > > > > > > >> > the > > > > > > > > > >> > > two queue design, or > > > > > > > > > >> > > > > > > > > > > > >> > > the one single queue being full in the deque > design), > > > the > > > > > > > > processor > > > > > > > > > >> > thread > > > > > > > > > >> > > will be blocked first > > > > > > > > > >> > > > > > > > > > > > >> > > when trying to enqueue the data request from > > > connection0, > > > > > then > > > > > > > > > >> possibly > > > > > > > > > >> > > blocked for the data request > > > > > > > > > >> > > > > > > > > > > > >> > > from connection1, ... etc even though the controller > > > > request > > > > > > is > > > > > > > > > ready > > > > > > > > > >> to > > > > > > > > > >> > be > > > > > > > > > >> > > enqueued. > > > > > > > > > >> > > > > > > > > > > > >> > > To solve this problem, it seems we would need to > have > > a > > > > > > separate > > > > > > > > > port > > > > > > > > > >> > > dedicated to > > > > > > > > > >> > > > > > > > > > > > >> > > the controller, a dedicated processor thread, a > > > dedicated > > > > > > > > controller > > > > > > > > > >> > > request queue, > > > > > > > > > >> > > > > > > > > > > > >> > > and pinning of one request handler thread for > > controller > > > > > > > requests. > > > > > > > > > >> > > > > > > > > > > > >> > > Thanks, > > > > > > > > > >> > > Lucas > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > On Mon, Jul 23, 2018 at 6:00 PM, Becket Qin < > > > > > > > becket....@gmail.com > > > > > > > > > > > > > > > > > > >> > wrote: > > > > > > > > > >> > > > > > > > > > > > >> > > > Personally I am not fond of the dequeue approach > > > simply > > > > > > > because > > > > > > > > it > > > > > > > > > >> is > > > > > > > > > >> > > > against the basic idea of isolating the controller > > > plane > > > > > and > > > > > > > > data > > > > > > > > > >> > plane. > > > > > > > > > >> > > > With a single dequeue, theoretically speaking the > > > > > controller > > > > > > > > > >> requests > > > > > > > > > >> > can > > > > > > > > > >> > > > starve the clients requests. I would prefer the > > > approach > > > > > > with > > > > > > > a > > > > > > > > > >> > separate > > > > > > > > > >> > > > controller request queue and a dedicated > controller > > > > > request > > > > > > > > > handler > > > > > > > > > >> > > thread. > > > > > > > > > >> > > > > > > > > > > > > >> > > > Thanks, > > > > > > > > > >> > > > > > > > > > > > > >> > > > Jiangjie (Becket) Qin > > > > > > > > > >> > > > > > > > > > > > > >> > > > On Tue, Jul 24, 2018 at 8:16 AM, Lucas Wang < > > > > > > > > > lucasatu...@gmail.com> > > > > > > > > > >> > > wrote: > > > > > > > > > >> > > > > > > > > > > > > >> > > > > Sure, I can summarize the usage of correlation > id. > > > But > > > > > > > before > > > > > > > > I > > > > > > > > > do > > > > > > > > > >> > > that, > > > > > > > > > >> > > > it > > > > > > > > > >> > > > > seems > > > > > > > > > >> > > > > the same out-of-order processing can also happen > > to > > > > > > Produce > > > > > > > > > >> requests > > > > > > > > > >> > > sent > > > > > > > > > >> > > > > by producers, > > > > > > > > > >> > > > > following the same example you described > earlier. > > > > > > > > > >> > > > > If that's the case, I think this probably > > deserves a > > > > > > > separate > > > > > > > > > doc > > > > > > > > > >> and > > > > > > > > > >> > > > > design independent of this KIP. > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > Lucas > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > On Mon, Jul 23, 2018 at 12:39 PM, Dong Lin < > > > > > > > > lindon...@gmail.com > > > > > > > > > > > > > > > > > > > >> > > wrote: > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > Hey Lucas, > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > Could you update the KIP if you are confident > > with > > > > the > > > > > > > > > approach > > > > > > > > > >> > which > > > > > > > > > >> > > > > uses > > > > > > > > > >> > > > > > correlation id? The idea around correlation id > > is > > > > kind > > > > > > of > > > > > > > > > >> scattered > > > > > > > > > >> > > > > across > > > > > > > > > >> > > > > > multiple emails. It will be useful if other > > > reviews > > > > > can > > > > > > > read > > > > > > > > > the > > > > > > > > > >> > KIP > > > > > > > > > >> > > to > > > > > > > > > >> > > > > > understand the latest proposal. > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > Thanks, > > > > > > > > > >> > > > > > Dong > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > On Mon, Jul 23, 2018 at 12:32 PM, Mayuresh > > Gharat > > > < > > > > > > > > > >> > > > > > gharatmayures...@gmail.com> wrote: > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > I like the idea of the dequeue > implementation > > by > > > > > > Lucas. > > > > > > > > This > > > > > > > > > >> will > > > > > > > > > >> > > > help > > > > > > > > > >> > > > > us > > > > > > > > > >> > > > > > > avoid additional queue for controller and > > > > additional > > > > > > > > configs > > > > > > > > > >> in > > > > > > > > > >> > > > Kafka. > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > Thanks, > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > Mayuresh > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > On Sun, Jul 22, 2018 at 2:58 AM Becket Qin < > > > > > > > > > >> becket....@gmail.com > > > > > > > > > >> > > > > > > > > > > > >> > > > > wrote: > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > Hi Jun, > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > The usage of correlation ID might still be > > > > useful > > > > > to > > > > > > > > > address > > > > > > > > > >> > the > > > > > > > > > >> > > > > cases > > > > > > > > > >> > > > > > > > that the controller epoch and leader epoch > > > check > > > > > are > > > > > > > not > > > > > > > > > >> > > sufficient > > > > > > > > > >> > > > > to > > > > > > > > > >> > > > > > > > guarantee correct behavior. For example, > if > > > the > > > > > > > > controller > > > > > > > > > >> > sends > > > > > > > > > >> > > a > > > > > > > > > >> > > > > > > > LeaderAndIsrRequest followed by a > > > > > > StopReplicaRequest, > > > > > > > > and > > > > > > > > > >> the > > > > > > > > > >> > > > broker > > > > > > > > > >> > > > > > > > processes it in the reverse order, the > > replica > > > > may > > > > > > > still > > > > > > > > > be > > > > > > > > > >> > > wrongly > > > > > > > > > >> > > > > > > > recreated, right? > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > Thanks, > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > Jiangjie (Becket) Qin > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > On Jul 22, 2018, at 11:47 AM, Jun Rao < > > > > > > > > j...@confluent.io > > > > > > > > > > > > > > > > > > > >> > > wrote: > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > > > > > > > > Hmm, since we already use controller > epoch > > > and > > > > > > > leader > > > > > > > > > >> epoch > > > > > > > > > >> > for > > > > > > > > > >> > > > > > > properly > > > > > > > > > >> > > > > > > > > caching the latest partition state, do > we > > > > really > > > > > > > need > > > > > > > > > >> > > correlation > > > > > > > > > >> > > > > id > > > > > > > > > >> > > > > > > for > > > > > > > > > >> > > > > > > > > ordering the controller requests? > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > > > > > > > > Thanks, > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > > > > > > > > Jun > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > > > > > > > > On Fri, Jul 20, 2018 at 2:18 PM, Becket > > Qin > > > < > > > > > > > > > >> > > > becket....@gmail.com> > > > > > > > > > >> > > > > > > > wrote: > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > > > > > > > >> Lucas and Mayuresh, > > > > > > > > > >> > > > > > > > >> > > > > > > > > > >> > > > > > > > >> Good idea. The correlation id should > > work. > > > > > > > > > >> > > > > > > > >> > > > > > > > > > >> > > > > > > > >> In the ControllerChannelManager, a > > request > > > > will > > > > > > be > > > > > > > > > resent > > > > > > > > > >> > > until > > > > > > > > > >> > > > a > > > > > > > > > >> > > > > > > > response > > > > > > > > > >> > > > > > > > >> is received. So if the controller to > > broker > > > > > > > > connection > > > > > > > > > >> > > > disconnects > > > > > > > > > >> > > > > > > after > > > > > > > > > >> > > > > > > > >> controller sends R1_a, but before the > > > > response > > > > > of > > > > > > > > R1_a > > > > > > > > > is > > > > > > > > > >> > > > > received, > > > > > > > > > >> > > > > > a > > > > > > > > > >> > > > > > > > >> disconnection may cause the controller > to > > > > > resend > > > > > > > > R1_b. > > > > > > > > > >> i.e. > > > > > > > > > >> > > > until > > > > > > > > > >> > > > > R1 > > > > > > > > > >> > > > > > > is > > > > > > > > > >> > > > > > > > >> acked, R2 won't be sent by the > > controller. > > > > > > > > > >> > > > > > > > >> This gives two guarantees: > > > > > > > > > >> > > > > > > > >> 1. Correlation id wise: R1_a < R1_b < > R2. > > > > > > > > > >> > > > > > > > >> 2. On the broker side, when R2 is seen, > > R1 > > > > must > > > > > > > have > > > > > > > > > been > > > > > > > > > >> > > > > processed > > > > > > > > > >> > > > > > at > > > > > > > > > >> > > > > > > > >> least once. > > > > > > > > > >> > > > > > > > >> > > > > > > > > > >> > > > > > > > >> So on the broker side, with a single > > thread > > > > > > > > controller > > > > > > > > > >> > request > > > > > > > > > >> > > > > > > handler, > > > > > > > > > >> > > > > > > > the > > > > > > > > > >> > > > > > > > >> logic should be: > > > > > > > > > >> > > > > > > > >> 1. Process what ever request seen in > the > > > > > > controller > > > > > > > > > >> request > > > > > > > > > >> > > > queue > > > > > > > > > >> > > > > > > > >> 2. For the given epoch, drop request if > > its > > > > > > > > correlation > > > > > > > > > >> id > > > > > > > > > >> > is > > > > > > > > > >> > > > > > smaller > > > > > > > > > >> > > > > > > > than > > > > > > > > > >> > > > > > > > >> that of the last processed request. > > > > > > > > > >> > > > > > > > >> > > > > > > > > > >> > > > > > > > >> Thanks, > > > > > > > > > >> > > > > > > > >> > > > > > > > > > >> > > > > > > > >> Jiangjie (Becket) Qin > > > > > > > > > >> > > > > > > > >> > > > > > > > > > >> > > > > > > > >> On Fri, Jul 20, 2018 at 8:07 AM, Jun > Rao > > < > > > > > > > > > >> j...@confluent.io> > > > > > > > > > >> > > > > wrote: > > > > > > > > > >> > > > > > > > >> > > > > > > > > > >> > > > > > > > >>> I agree that there is no strong > ordering > > > > when > > > > > > > there > > > > > > > > > are > > > > > > > > > >> > more > > > > > > > > > >> > > > than > > > > > > > > > >> > > > > > one > > > > > > > > > >> > > > > > > > >>> socket connections. Currently, we rely > > on > > > > > > > > > >> controllerEpoch > > > > > > > > > >> > and > > > > > > > > > >> > > > > > > > leaderEpoch > > > > > > > > > >> > > > > > > > >>> to ensure that the receiving broker > > picks > > > up > > > > > the > > > > > > > > > latest > > > > > > > > > >> > state > > > > > > > > > >> > > > for > > > > > > > > > >> > > > > > > each > > > > > > > > > >> > > > > > > > >>> partition. > > > > > > > > > >> > > > > > > > >>> > > > > > > > > > >> > > > > > > > >>> One potential issue with the dequeue > > > > approach > > > > > is > > > > > > > > that > > > > > > > > > if > > > > > > > > > >> > the > > > > > > > > > >> > > > > queue > > > > > > > > > >> > > > > > is > > > > > > > > > >> > > > > > > > >> full, > > > > > > > > > >> > > > > > > > >>> there is no guarantee that the > > controller > > > > > > requests > > > > > > > > > will > > > > > > > > > >> be > > > > > > > > > >> > > > > enqueued > > > > > > > > > >> > > > > > > > >>> quickly. > > > > > > > > > >> > > > > > > > >>> > > > > > > > > > >> > > > > > > > >>> Thanks, > > > > > > > > > >> > > > > > > > >>> > > > > > > > > > >> > > > > > > > >>> Jun > > > > > > > > > >> > > > > > > > >>> > > > > > > > > > >> > > > > > > > >>> On Fri, Jul 20, 2018 at 5:25 AM, > > Mayuresh > > > > > > Gharat < > > > > > > > > > >> > > > > > > > >>> gharatmayures...@gmail.com > > > > > > > > > >> > > > > > > > >>>> wrote: > > > > > > > > > >> > > > > > > > >>> > > > > > > > > > >> > > > > > > > >>>> Yea, the correlationId is only set > to 0 > > > in > > > > > the > > > > > > > > > >> > NetworkClient > > > > > > > > > >> > > > > > > > >> constructor. > > > > > > > > > >> > > > > > > > >>>> Since we reuse the same NetworkClient > > > > between > > > > > > > > > >> Controller > > > > > > > > > >> > and > > > > > > > > > >> > > > the > > > > > > > > > >> > > > > > > > >> broker, > > > > > > > > > >> > > > > > > > >>> a > > > > > > > > > >> > > > > > > > >>>> disconnection should not cause it to > > > reset > > > > to > > > > > > 0, > > > > > > > in > > > > > > > > > >> which > > > > > > > > > >> > > case > > > > > > > > > >> > > > > it > > > > > > > > > >> > > > > > > can > > > > > > > > > >> > > > > > > > >> be > > > > > > > > > >> > > > > > > > >>>> used to reject obsolete requests. > > > > > > > > > >> > > > > > > > >>>> > > > > > > > > > >> > > > > > > > >>>> Thanks, > > > > > > > > > >> > > > > > > > >>>> > > > > > > > > > >> > > > > > > > >>>> Mayuresh > > > > > > > > > >> > > > > > > > >>>> > > > > > > > > > >> > > > > > > > >>>> On Thu, Jul 19, 2018 at 1:52 PM Lucas > > > Wang > > > > < > > > > > > > > > >> > > > > lucasatu...@gmail.com > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > >>> wrote: > > > > > > > > > >> > > > > > > > >>>> > > > > > > > > > >> > > > > > > > >>>>> @Dong, > > > > > > > > > >> > > > > > > > >>>>> Great example and explanation, > thanks! > > > > > > > > > >> > > > > > > > >>>>> > > > > > > > > > >> > > > > > > > >>>>> @All > > > > > > > > > >> > > > > > > > >>>>> Regarding the example given by Dong, > > it > > > > > seems > > > > > > > even > > > > > > > > > if > > > > > > > > > >> we > > > > > > > > > >> > > use > > > > > > > > > >> > > > a > > > > > > > > > >> > > > > > > queue, > > > > > > > > > >> > > > > > > > >>>> and a > > > > > > > > > >> > > > > > > > >>>>> dedicated controller request > handling > > > > > thread, > > > > > > > > > >> > > > > > > > >>>>> the same result can still happen > > because > > > > > R1_a > > > > > > > will > > > > > > > > > be > > > > > > > > > >> > sent > > > > > > > > > >> > > on > > > > > > > > > >> > > > > one > > > > > > > > > >> > > > > > > > >>>>> connection, and R1_b & R2 will be > sent > > > on > > > > a > > > > > > > > > different > > > > > > > > > >> > > > > connection, > > > > > > > > > >> > > > > > > > >>>>> and there is no ordering between > > > different > > > > > > > > > >> connections on > > > > > > > > > >> > > the > > > > > > > > > >> > > > > > > broker > > > > > > > > > >> > > > > > > > >>>> side. > > > > > > > > > >> > > > > > > > >>>>> I was discussing with Mayuresh > > offline, > > > > and > > > > > it > > > > > > > > seems > > > > > > > > > >> > > > > correlation > > > > > > > > > >> > > > > > id > > > > > > > > > >> > > > > > > > >>>> within > > > > > > > > > >> > > > > > > > >>>>> the same NetworkClient object is > > > > > monotonically > > > > > > > > > >> increasing > > > > > > > > > >> > > and > > > > > > > > > >> > > > > > never > > > > > > > > > >> > > > > > > > >>>> reset, > > > > > > > > > >> > > > > > > > >>>>> hence a broker can leverage that to > > > > properly > > > > > > > > reject > > > > > > > > > >> > > obsolete > > > > > > > > > >> > > > > > > > >> requests. > > > > > > > > > >> > > > > > > > >>>>> Thoughts? > > > > > > > > > >> > > > > > > > >>>>> > > > > > > > > > >> > > > > > > > >>>>> Thanks, > > > > > > > > > >> > > > > > > > >>>>> Lucas > > > > > > > > > >> > > > > > > > >>>>> > > > > > > > > > >> > > > > > > > >>>>> On Thu, Jul 19, 2018 at 12:11 PM, > > > Mayuresh > > > > > > > Gharat > > > > > > > > < > > > > > > > > > >> > > > > > > > >>>>> gharatmayures...@gmail.com> wrote: > > > > > > > > > >> > > > > > > > >>>>> > > > > > > > > > >> > > > > > > > >>>>>> Actually nvm, correlationId is > reset > > in > > > > > case > > > > > > of > > > > > > > > > >> > connection > > > > > > > > > >> > > > > > loss, I > > > > > > > > > >> > > > > > > > >>>> think. > > > > > > > > > >> > > > > > > > >>>>>> > > > > > > > > > >> > > > > > > > >>>>>> Thanks, > > > > > > > > > >> > > > > > > > >>>>>> > > > > > > > > > >> > > > > > > > >>>>>> Mayuresh > > > > > > > > > >> > > > > > > > >>>>>> > > > > > > > > > >> > > > > > > > >>>>>> On Thu, Jul 19, 2018 at 11:11 AM > > > Mayuresh > > > > > > > Gharat > > > > > > > > < > > > > > > > > > >> > > > > > > > >>>>>> gharatmayures...@gmail.com> > > > > > > > > > >> > > > > > > > >>>>>> wrote: > > > > > > > > > >> > > > > > > > >>>>>> > > > > > > > > > >> > > > > > > > >>>>>>> I agree with Dong that > out-of-order > > > > > > processing > > > > > > > > can > > > > > > > > > >> > happen > > > > > > > > > >> > > > > with > > > > > > > > > >> > > > > > > > >>>> having 2 > > > > > > > > > >> > > > > > > > >>>>>>> separate queues as well and it can > > > even > > > > > > happen > > > > > > > > > >> today. > > > > > > > > > >> > > > > > > > >>>>>>> Can we use the correlationId in > the > > > > > request > > > > > > > from > > > > > > > > > the > > > > > > > > > >> > > > > controller > > > > > > > > > >> > > > > > > > >> to > > > > > > > > > >> > > > > > > > >>>> the > > > > > > > > > >> > > > > > > > >>>>>>> broker to handle ordering ? > > > > > > > > > >> > > > > > > > >>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>> Thanks, > > > > > > > > > >> > > > > > > > >>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>> Mayuresh > > > > > > > > > >> > > > > > > > >>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>> On Thu, Jul 19, 2018 at 6:41 AM > > Becket > > > > > Qin < > > > > > > > > > >> > > > > > becket....@gmail.com > > > > > > > > > >> > > > > > > > >>> > > > > > > > > > >> > > > > > > > >>>>> wrote: > > > > > > > > > >> > > > > > > > >>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>> Good point, Joel. I agree that a > > > > > dedicated > > > > > > > > > >> controller > > > > > > > > > >> > > > > request > > > > > > > > > >> > > > > > > > >>>> handling > > > > > > > > > >> > > > > > > > >>>>>>>> thread would be a better > isolation. > > > It > > > > > also > > > > > > > > > solves > > > > > > > > > >> the > > > > > > > > > >> > > > > > > > >> reordering > > > > > > > > > >> > > > > > > > >>>>> issue. > > > > > > > > > >> > > > > > > > >>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>> On Thu, Jul 19, 2018 at 2:23 PM, > > Joel > > > > > > Koshy < > > > > > > > > > >> > > > > > > > >> jjkosh...@gmail.com> > > > > > > > > > >> > > > > > > > >>>>>> wrote: > > > > > > > > > >> > > > > > > > >>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>> Good example. I think this > > scenario > > > > can > > > > > > > occur > > > > > > > > in > > > > > > > > > >> the > > > > > > > > > >> > > > > current > > > > > > > > > >> > > > > > > > >>> code > > > > > > > > > >> > > > > > > > >>>> as > > > > > > > > > >> > > > > > > > >>>>>>>> well > > > > > > > > > >> > > > > > > > >>>>>>>>> but with even lower probability > > > given > > > > > that > > > > > > > > there > > > > > > > > > >> are > > > > > > > > > >> > > > other > > > > > > > > > >> > > > > > > > >>>>>>>> non-controller > > > > > > > > > >> > > > > > > > >>>>>>>>> requests interleaved. It is > still > > > > > sketchy > > > > > > > > though > > > > > > > > > >> and > > > > > > > > > >> > I > > > > > > > > > >> > > > > think > > > > > > > > > >> > > > > > a > > > > > > > > > >> > > > > > > > >>>> safer > > > > > > > > > >> > > > > > > > >>>>>>>>> approach would be separate > queues > > > and > > > > > > > pinning > > > > > > > > > >> > > controller > > > > > > > > > >> > > > > > > > >> request > > > > > > > > > >> > > > > > > > >>>>>>>> handling > > > > > > > > > >> > > > > > > > >>>>>>>>> to one handler thread. > > > > > > > > > >> > > > > > > > >>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>> On Wed, Jul 18, 2018 at 11:12 > PM, > > > Dong > > > > > > Lin < > > > > > > > > > >> > > > > > > > >> lindon...@gmail.com > > > > > > > > > >> > > > > > > > >>>> > > > > > > > > > >> > > > > > > > >>>>>> wrote: > > > > > > > > > >> > > > > > > > >>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>> Hey Becket, > > > > > > > > > >> > > > > > > > >>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>> I think you are right that > there > > > may > > > > be > > > > > > > > > >> out-of-order > > > > > > > > > >> > > > > > > > >>> processing. > > > > > > > > > >> > > > > > > > >>>>>>>> However, > > > > > > > > > >> > > > > > > > >>>>>>>>>> it seems that out-of-order > > > processing > > > > > may > > > > > > > > also > > > > > > > > > >> > happen > > > > > > > > > >> > > > even > > > > > > > > > >> > > > > > > > >> if > > > > > > > > > >> > > > > > > > >>> we > > > > > > > > > >> > > > > > > > >>>>>> use a > > > > > > > > > >> > > > > > > > >>>>>>>>>> separate queue. > > > > > > > > > >> > > > > > > > >>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>> Here is the example: > > > > > > > > > >> > > > > > > > >>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>> - Controller sends R1 and got > > > > > > disconnected > > > > > > > > > before > > > > > > > > > >> > > > > receiving > > > > > > > > > >> > > > > > > > >>>>>> response. > > > > > > > > > >> > > > > > > > >>>>>>>>> Then > > > > > > > > > >> > > > > > > > >>>>>>>>>> it reconnects and sends R2. > Both > > > > > requests > > > > > > > now > > > > > > > > > >> stay > > > > > > > > > >> > in > > > > > > > > > >> > > > the > > > > > > > > > >> > > > > > > > >>>>> controller > > > > > > > > > >> > > > > > > > >>>>>>>>>> request queue in the order they > > are > > > > > sent. > > > > > > > > > >> > > > > > > > >>>>>>>>>> - thread1 takes R1_a from the > > > request > > > > > > queue > > > > > > > > and > > > > > > > > > >> then > > > > > > > > > >> > > > > thread2 > > > > > > > > > >> > > > > > > > >>>> takes > > > > > > > > > >> > > > > > > > >>>>>> R2 > > > > > > > > > >> > > > > > > > >>>>>>>>> from > > > > > > > > > >> > > > > > > > >>>>>>>>>> the request queue almost at the > > > same > > > > > > time. > > > > > > > > > >> > > > > > > > >>>>>>>>>> - So R1_a and R2 are processed > in > > > > > > parallel. > > > > > > > > > >> There is > > > > > > > > > >> > > > > chance > > > > > > > > > >> > > > > > > > >>> that > > > > > > > > > >> > > > > > > > >>>>>> R2's > > > > > > > > > >> > > > > > > > >>>>>>>>>> processing is completed before > > R1. > > > > > > > > > >> > > > > > > > >>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>> If out-of-order processing can > > > happen > > > > > for > > > > > > > > both > > > > > > > > > >> > > > approaches > > > > > > > > > >> > > > > > > > >> with > > > > > > > > > >> > > > > > > > >>>>> very > > > > > > > > > >> > > > > > > > >>>>>>>> low > > > > > > > > > >> > > > > > > > >>>>>>>>>> probability, it may not be > > > worthwhile > > > > > to > > > > > > > add > > > > > > > > > the > > > > > > > > > >> > extra > > > > > > > > > >> > > > > > > > >> queue. > > > > > > > > > >> > > > > > > > >>>> What > > > > > > > > > >> > > > > > > > >>>>>> do > > > > > > > > > >> > > > > > > > >>>>>>>> you > > > > > > > > > >> > > > > > > > >>>>>>>>>> think? > > > > > > > > > >> > > > > > > > >>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>> Thanks, > > > > > > > > > >> > > > > > > > >>>>>>>>>> Dong > > > > > > > > > >> > > > > > > > >>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>> On Wed, Jul 18, 2018 at 6:17 > PM, > > > > Becket > > > > > > > Qin < > > > > > > > > > >> > > > > > > > >>>> becket....@gmail.com > > > > > > > > > >> > > > > > > > >>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>> wrote: > > > > > > > > > >> > > > > > > > >>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>> Hi Mayuresh/Joel, > > > > > > > > > >> > > > > > > > >>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>> Using the request channel as a > > > > dequeue > > > > > > was > > > > > > > > > >> bright > > > > > > > > > >> > up > > > > > > > > > >> > > > some > > > > > > > > > >> > > > > > > > >>> time > > > > > > > > > >> > > > > > > > >>>>> ago > > > > > > > > > >> > > > > > > > >>>>>>>> when > > > > > > > > > >> > > > > > > > >>>>>>>>>> we > > > > > > > > > >> > > > > > > > >>>>>>>>>>> initially thinking of > > prioritizing > > > > the > > > > > > > > > request. > > > > > > > > > >> The > > > > > > > > > >> > > > > > > > >> concern > > > > > > > > > >> > > > > > > > >>>> was > > > > > > > > > >> > > > > > > > >>>>>> that > > > > > > > > > >> > > > > > > > >>>>>>>>> the > > > > > > > > > >> > > > > > > > >>>>>>>>>>> controller requests are > supposed > > > to > > > > be > > > > > > > > > >> processed in > > > > > > > > > >> > > > > order. > > > > > > > > > >> > > > > > > > >>> If > > > > > > > > > >> > > > > > > > >>>> we > > > > > > > > > >> > > > > > > > >>>>>> can > > > > > > > > > >> > > > > > > > >>>>>>>>>> ensure > > > > > > > > > >> > > > > > > > >>>>>>>>>>> that there is one controller > > > request > > > > > in > > > > > > > the > > > > > > > > > >> request > > > > > > > > > >> > > > > > > > >> channel, > > > > > > > > > >> > > > > > > > >>>> the > > > > > > > > > >> > > > > > > > >>>>>>>> order > > > > > > > > > >> > > > > > > > >>>>>>>>> is > > > > > > > > > >> > > > > > > > >>>>>>>>>>> not a concern. But in cases > that > > > > there > > > > > > are > > > > > > > > > more > > > > > > > > > >> > than > > > > > > > > > >> > > > one > > > > > > > > > >> > > > > > > > >>>>>> controller > > > > > > > > > >> > > > > > > > >>>>>>>>>> request > > > > > > > > > >> > > > > > > > >>>>>>>>>>> inserted into the queue, the > > > > > controller > > > > > > > > > request > > > > > > > > > >> > order > > > > > > > > > >> > > > may > > > > > > > > > >> > > > > > > > >>>> change > > > > > > > > > >> > > > > > > > >>>>>> and > > > > > > > > > >> > > > > > > > >>>>>>>>>> cause > > > > > > > > > >> > > > > > > > >>>>>>>>>>> problem. For example, think > > about > > > > the > > > > > > > > > following > > > > > > > > > >> > > > sequence: > > > > > > > > > >> > > > > > > > >>>>>>>>>>> 1. Controller successfully > sent > > a > > > > > > request > > > > > > > R1 > > > > > > > > > to > > > > > > > > > >> > > broker > > > > > > > > > >> > > > > > > > >>>>>>>>>>> 2. Broker receives R1 and put > > the > > > > > > request > > > > > > > to > > > > > > > > > the > > > > > > > > > >> > head > > > > > > > > > >> > > > of > > > > > > > > > >> > > > > > > > >> the > > > > > > > > > >> > > > > > > > >>>>>> request > > > > > > > > > >> > > > > > > > >>>>>>>>>> queue. > > > > > > > > > >> > > > > > > > >>>>>>>>>>> 3. Controller to broker > > connection > > > > > > failed > > > > > > > > and > > > > > > > > > >> the > > > > > > > > > >> > > > > > > > >> controller > > > > > > > > > >> > > > > > > > >>>>>>>>> reconnected > > > > > > > > > >> > > > > > > > >>>>>>>>>> to > > > > > > > > > >> > > > > > > > >>>>>>>>>>> the broker. > > > > > > > > > >> > > > > > > > >>>>>>>>>>> 4. Controller sends a request > R2 > > > to > > > > > the > > > > > > > > broker > > > > > > > > > >> > > > > > > > >>>>>>>>>>> 5. Broker receives R2 and add > it > > > to > > > > > the > > > > > > > head > > > > > > > > > of > > > > > > > > > >> the > > > > > > > > > >> > > > > > > > >> request > > > > > > > > > >> > > > > > > > >>>>> queue. > > > > > > > > > >> > > > > > > > >>>>>>>>>>> Now on the broker side, R2 > will > > be > > > > > > > processed > > > > > > > > > >> before > > > > > > > > > >> > > R1 > > > > > > > > > >> > > > is > > > > > > > > > >> > > > > > > > >>>>>> processed, > > > > > > > > > >> > > > > > > > >>>>>>>>>> which > > > > > > > > > >> > > > > > > > >>>>>>>>>>> may cause problem. > > > > > > > > > >> > > > > > > > >>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>> Thanks, > > > > > > > > > >> > > > > > > > >>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>> Jiangjie (Becket) Qin > > > > > > > > > >> > > > > > > > >>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>> On Thu, Jul 19, 2018 at 3:23 > AM, > > > > Joel > > > > > > > Koshy > > > > > > > > < > > > > > > > > > >> > > > > > > > >>>>> jjkosh...@gmail.com> > > > > > > > > > >> > > > > > > > >>>>>>>>> wrote: > > > > > > > > > >> > > > > > > > >>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> @Mayuresh - I like your idea. > > It > > > > > > appears > > > > > > > to > > > > > > > > > be > > > > > > > > > >> a > > > > > > > > > >> > > > simpler > > > > > > > > > >> > > > > > > > >>>> less > > > > > > > > > >> > > > > > > > >>>>>>>>> invasive > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> alternative and it should > work. > > > > > > > > > >> Jun/Becket/others, > > > > > > > > > >> > > do > > > > > > > > > >> > > > > > > > >> you > > > > > > > > > >> > > > > > > > >>>> see > > > > > > > > > >> > > > > > > > >>>>>> any > > > > > > > > > >> > > > > > > > >>>>>>>>>>> pitfalls > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> with this approach? > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> On Wed, Jul 18, 2018 at 12:03 > > PM, > > > > > Lucas > > > > > > > > Wang > > > > > > > > > < > > > > > > > > > >> > > > > > > > >>>>>>>> lucasatu...@gmail.com> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> wrote: > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> @Mayuresh, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> That's a very interesting > idea > > > > that > > > > > I > > > > > > > > > haven't > > > > > > > > > >> > > thought > > > > > > > > > >> > > > > > > > >>>>> before. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> It seems to solve our > problem > > at > > > > > hand > > > > > > > > pretty > > > > > > > > > >> > well, > > > > > > > > > >> > > > and > > > > > > > > > >> > > > > > > > >>>> also > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> avoids the need to have a > new > > > size > > > > > > > metric > > > > > > > > > and > > > > > > > > > >> > > > capacity > > > > > > > > > >> > > > > > > > >>>>> config > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> for the controller request > > > queue. > > > > In > > > > > > > fact, > > > > > > > > > if > > > > > > > > > >> we > > > > > > > > > >> > > were > > > > > > > > > >> > > > > > > > >> to > > > > > > > > > >> > > > > > > > >>>>> adopt > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> this design, there is no > > public > > > > > > > interface > > > > > > > > > >> change, > > > > > > > > > >> > > and > > > > > > > > > >> > > > > > > > >> we > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> probably don't need a KIP. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> Also implementation wise, it > > > seems > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> the java class > > > LinkedBlockingQueue > > > > > can > > > > > > > > > readily > > > > > > > > > >> > > > satisfy > > > > > > > > > >> > > > > > > > >>> the > > > > > > > > > >> > > > > > > > >>>>>>>>>> requirement > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> by supporting a capacity, > and > > > also > > > > > > > > allowing > > > > > > > > > >> > > inserting > > > > > > > > > >> > > > > > > > >> at > > > > > > > > > >> > > > > > > > >>>>> both > > > > > > > > > >> > > > > > > > >>>>>>>> ends. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> My only concern is that this > > > > design > > > > > is > > > > > > > > tied > > > > > > > > > to > > > > > > > > > >> > the > > > > > > > > > >> > > > > > > > >>>>> coincidence > > > > > > > > > >> > > > > > > > >>>>>>>> that > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> we have two request > priorities > > > and > > > > > > there > > > > > > > > are > > > > > > > > > >> two > > > > > > > > > >> > > ends > > > > > > > > > >> > > > > > > > >>> to a > > > > > > > > > >> > > > > > > > >>>>>>>> deque. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> Hence by using the proposed > > > > design, > > > > > it > > > > > > > > seems > > > > > > > > > >> the > > > > > > > > > >> > > > > > > > >> network > > > > > > > > > >> > > > > > > > >>>>> layer > > > > > > > > > >> > > > > > > > >>>>>>>> is > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> more tightly coupled with > > upper > > > > > layer > > > > > > > > logic, > > > > > > > > > >> e.g. > > > > > > > > > >> > > if > > > > > > > > > >> > > > > > > > >> we > > > > > > > > > >> > > > > > > > >>>> were > > > > > > > > > >> > > > > > > > >>>>>> to > > > > > > > > > >> > > > > > > > >>>>>>>> add > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> an extra priority level in > the > > > > > future > > > > > > > for > > > > > > > > > some > > > > > > > > > >> > > > reason, > > > > > > > > > >> > > > > > > > >>> we > > > > > > > > > >> > > > > > > > >>>>>> would > > > > > > > > > >> > > > > > > > >>>>>>>>>>> probably > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> need to go back to the > design > > of > > > > > > > separate > > > > > > > > > >> queues, > > > > > > > > > >> > > one > > > > > > > > > >> > > > > > > > >>> for > > > > > > > > > >> > > > > > > > >>>>> each > > > > > > > > > >> > > > > > > > >>>>>>>>>> priority > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> level. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> In summary, I'm ok with both > > > > designs > > > > > > and > > > > > > > > > lean > > > > > > > > > >> > > toward > > > > > > > > > >> > > > > > > > >>> your > > > > > > > > > >> > > > > > > > >>>>>>>> suggested > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> approach. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> Let's hear what others > think. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> @Becket, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> In light of Mayuresh's > > suggested > > > > new > > > > > > > > design, > > > > > > > > > >> I'm > > > > > > > > > >> > > > > > > > >>> answering > > > > > > > > > >> > > > > > > > >>>>>> your > > > > > > > > > >> > > > > > > > >>>>>>>>>>> question > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> only in the context > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> of the current KIP design: I > > > think > > > > > > your > > > > > > > > > >> > suggestion > > > > > > > > > >> > > > > > > > >> makes > > > > > > > > > >> > > > > > > > >>>>>> sense, > > > > > > > > > >> > > > > > > > >>>>>>>> and > > > > > > > > > >> > > > > > > > >>>>>>>>>> I'm > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> ok > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> with removing the capacity > > > config > > > > > and > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> just relying on the default > > > value > > > > of > > > > > > 20 > > > > > > > > > being > > > > > > > > > >> > > > > > > > >> sufficient > > > > > > > > > >> > > > > > > > >>>>>> enough. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> Thanks, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> Lucas > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> On Wed, Jul 18, 2018 at 9:57 > > AM, > > > > > > > Mayuresh > > > > > > > > > >> Gharat > > > > > > > > > >> > < > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> gharatmayures...@gmail.com > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> wrote: > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> Hi Lucas, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> Seems like the main intent > > here > > > > is > > > > > to > > > > > > > > > >> prioritize > > > > > > > > > >> > > the > > > > > > > > > >> > > > > > > > >>>>>>>> controller > > > > > > > > > >> > > > > > > > >>>>>>>>>>> request > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> over any other requests. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> In that case, we can change > > the > > > > > > request > > > > > > > > > queue > > > > > > > > > >> > to a > > > > > > > > > >> > > > > > > > >>>>> dequeue, > > > > > > > > > >> > > > > > > > >>>>>>>> where > > > > > > > > > >> > > > > > > > >>>>>>>>>> you > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> always insert the normal > > > requests > > > > > > > > (produce, > > > > > > > > > >> > > > > > > > >>>> consume,..etc) > > > > > > > > > >> > > > > > > > >>>>>> to > > > > > > > > > >> > > > > > > > >>>>>>>> the > > > > > > > > > >> > > > > > > > >>>>>>>>>> end > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> of > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> the dequeue, but if its a > > > > > controller > > > > > > > > > request, > > > > > > > > > >> > you > > > > > > > > > >> > > > > > > > >>> insert > > > > > > > > > >> > > > > > > > >>>>> it > > > > > > > > > >> > > > > > > > >>>>>> to > > > > > > > > > >> > > > > > > > >>>>>>>>> the > > > > > > > > > >> > > > > > > > >>>>>>>>>>> head > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> of > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> the queue. This ensures > that > > > the > > > > > > > > controller > > > > > > > > > >> > > request > > > > > > > > > >> > > > > > > > >>> will > > > > > > > > > >> > > > > > > > >>>>> be > > > > > > > > > >> > > > > > > > >>>>>>>> given > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> higher > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> priority over other > requests. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> Also since we only read one > > > > request > > > > > > > from > > > > > > > > > the > > > > > > > > > >> > > socket > > > > > > > > > >> > > > > > > > >>> and > > > > > > > > > >> > > > > > > > >>>>> mute > > > > > > > > > >> > > > > > > > >>>>>>>> it > > > > > > > > > >> > > > > > > > >>>>>>>>> and > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> only > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> unmute it after handling > the > > > > > request, > > > > > > > > this > > > > > > > > > >> would > > > > > > > > > >> > > > > > > > >>> ensure > > > > > > > > > >> > > > > > > > >>>>> that > > > > > > > > > >> > > > > > > > >>>>>>>> we > > > > > > > > > >> > > > > > > > >>>>>>>>>> don't > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> handle controller requests > > out > > > of > > > > > > > order. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> With this approach we can > > avoid > > > > the > > > > > > > > second > > > > > > > > > >> queue > > > > > > > > > >> > > and > > > > > > > > > >> > > > > > > > >>> the > > > > > > > > > >> > > > > > > > >>>>>>>>> additional > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> config > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> for the size of the queue. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> What do you think ? > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> Thanks, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> Mayuresh > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> On Wed, Jul 18, 2018 at > 3:05 > > AM > > > > > > Becket > > > > > > > > Qin > > > > > > > > > < > > > > > > > > > >> > > > > > > > >>>>>>>> becket....@gmail.com > > > > > > > > > >> > > > > > > > >>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> wrote: > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> Hey Joel, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> Thank for the detail > > > > explanation. > > > > > I > > > > > > > > agree > > > > > > > > > >> the > > > > > > > > > >> > > > > > > > >>> current > > > > > > > > > >> > > > > > > > >>>>>> design > > > > > > > > > >> > > > > > > > >>>>>>>>>> makes > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> sense. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> My confusion is about > > whether > > > > the > > > > > > new > > > > > > > > > config > > > > > > > > > >> > for > > > > > > > > > >> > > > > > > > >> the > > > > > > > > > >> > > > > > > > >>>>>>>> controller > > > > > > > > > >> > > > > > > > >>>>>>>>>>> queue > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> capacity is necessary. I > > > cannot > > > > > > think > > > > > > > > of a > > > > > > > > > >> case > > > > > > > > > >> > > in > > > > > > > > > >> > > > > > > > >>>> which > > > > > > > > > >> > > > > > > > >>>>>>>> users > > > > > > > > > >> > > > > > > > >>>>>>>>>>> would > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> change > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> it. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> Thanks, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> Jiangjie (Becket) Qin > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> On Wed, Jul 18, 2018 at > 6:00 > > > PM, > > > > > > > Becket > > > > > > > > > Qin > > > > > > > > > >> < > > > > > > > > > >> > > > > > > > >>>>>>>>>> becket....@gmail.com> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> wrote: > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>> Hi Lucas, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>> I guess my question can > be > > > > > > rephrased > > > > > > > to > > > > > > > > > >> "do we > > > > > > > > > >> > > > > > > > >>>> expect > > > > > > > > > >> > > > > > > > >>>>>>>> user to > > > > > > > > > >> > > > > > > > >>>>>>>>>>> ever > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> change > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>> the controller request > > queue > > > > > > > capacity"? > > > > > > > > > If > > > > > > > > > >> we > > > > > > > > > >> > > > > > > > >>> agree > > > > > > > > > >> > > > > > > > >>>>> that > > > > > > > > > >> > > > > > > > >>>>>>>> 20 > > > > > > > > > >> > > > > > > > >>>>>>>>> is > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> already > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> a > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>> very generous default > > number > > > > and > > > > > we > > > > > > > do > > > > > > > > > not > > > > > > > > > >> > > > > > > > >> expect > > > > > > > > > >> > > > > > > > >>>> user > > > > > > > > > >> > > > > > > > >>>>>> to > > > > > > > > > >> > > > > > > > >>>>>>>>>> change > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> it, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> is > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> it > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>> still necessary to expose > > > this > > > > > as a > > > > > > > > > config? > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>> Thanks, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>> Jiangjie (Becket) Qin > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>> On Wed, Jul 18, 2018 at > > 2:29 > > > > AM, > > > > > > > Lucas > > > > > > > > > >> Wang < > > > > > > > > > >> > > > > > > > >>>>>>>>>>> lucasatu...@gmail.com > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> wrote: > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> @Becket > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> 1. Thanks for the > comment. > > > You > > > > > are > > > > > > > > right > > > > > > > > > >> that > > > > > > > > > >> > > > > > > > >>>>> normally > > > > > > > > > >> > > > > > > > >>>>>>>> there > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> should > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> be > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> just > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> one controller request > > > because > > > > > of > > > > > > > > > muting, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> and I had NOT intended > to > > > say > > > > > > there > > > > > > > > > would > > > > > > > > > >> be > > > > > > > > > >> > > > > > > > >> many > > > > > > > > > >> > > > > > > > >>>>>>>> enqueued > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> controller > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> requests. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> I went through the KIP > > > again, > > > > > and > > > > > > > I'm > > > > > > > > > not > > > > > > > > > >> > sure > > > > > > > > > >> > > > > > > > >>>> which > > > > > > > > > >> > > > > > > > >>>>>> part > > > > > > > > > >> > > > > > > > >>>>>>>>>>> conveys > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> that > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> info. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> I'd be happy to revise > if > > > you > > > > > > point > > > > > > > it > > > > > > > > > out > > > > > > > > > >> > the > > > > > > > > > >> > > > > > > > >>>>> section. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> 2. Though it should not > > > happen > > > > > in > > > > > > > > normal > > > > > > > > > >> > > > > > > > >>>> conditions, > > > > > > > > > >> > > > > > > > >>>>>> the > > > > > > > > > >> > > > > > > > >>>>>>>>>> current > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> design > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> does not preclude > multiple > > > > > > > controllers > > > > > > > > > >> > running > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> at the same time, hence > if > > > we > > > > > > don't > > > > > > > > have > > > > > > > > > >> the > > > > > > > > > >> > > > > > > > >>>>> controller > > > > > > > > > >> > > > > > > > >>>>>>>>> queue > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> capacity > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> config and simply make > its > > > > > > capacity > > > > > > > to > > > > > > > > > be > > > > > > > > > >> 1, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> network threads handling > > > > > requests > > > > > > > from > > > > > > > > > >> > > > > > > > >> different > > > > > > > > > >> > > > > > > > >>>>>>>> controllers > > > > > > > > > >> > > > > > > > >>>>>>>>>>> will > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> be > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> blocked during those > > > > troublesome > > > > > > > > times, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> which is probably not > what > > > we > > > > > > want. > > > > > > > On > > > > > > > > > the > > > > > > > > > >> > > > > > > > >> other > > > > > > > > > >> > > > > > > > >>>>> hand, > > > > > > > > > >> > > > > > > > >>>>>>>>> adding > > > > > > > > > >> > > > > > > > >>>>>>>>>>> the > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> extra > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> config with a default > > value, > > > > say > > > > > > 20, > > > > > > > > > >> guards > > > > > > > > > >> > us > > > > > > > > > >> > > > > > > > >>> from > > > > > > > > > >> > > > > > > > >>>>>>>> issues > > > > > > > > > >> > > > > > > > >>>>>>>>> in > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> those > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> troublesome times, and > IMO > > > > there > > > > > > > isn't > > > > > > > > > >> much > > > > > > > > > >> > > > > > > > >>>> downside > > > > > > > > > >> > > > > > > > >>>>> of > > > > > > > > > >> > > > > > > > >>>>>>>>> adding > > > > > > > > > >> > > > > > > > >>>>>>>>>>> the > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> extra > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> config. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> @Mayuresh > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> Good catch, this > sentence > > is > > > > an > > > > > > > > obsolete > > > > > > > > > >> > > > > > > > >>> statement > > > > > > > > > >> > > > > > > > >>>>>> based > > > > > > > > > >> > > > > > > > >>>>>>>> on > > > > > > > > > >> > > > > > > > >>>>>>>>> a > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> previous > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> design. I've revised the > > > > wording > > > > > > in > > > > > > > > the > > > > > > > > > >> KIP. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> Thanks, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> Lucas > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> On Tue, Jul 17, 2018 at > > > 10:33 > > > > > AM, > > > > > > > > > Mayuresh > > > > > > > > > >> > > > > > > > >>> Gharat < > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> > > gharatmayures...@gmail.com> > > > > > > wrote: > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> Hi Lucas, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> Thanks for the KIP. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> I am trying to > understand > > > why > > > > > you > > > > > > > > think > > > > > > > > > >> "The > > > > > > > > > >> > > > > > > > >>>> memory > > > > > > > > > >> > > > > > > > >>>>>>>>>>> consumption > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>> can > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> rise > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> given the total number > of > > > > > queued > > > > > > > > > requests > > > > > > > > > >> > can > > > > > > > > > >> > > > > > > > >>> go > > > > > > > > > >> > > > > > > > >>>> up > > > > > > > > > >> > > > > > > > >>>>>> to > > > > > > > > > >> > > > > > > > >>>>>>>> 2x" > > > > > > > > > >> > > > > > > > >>>>>>>>>> in > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> the > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> impact > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> section. Normally the > > > > requests > > > > > > from > > > > > > > > > >> > > > > > > > >> controller > > > > > > > > > >> > > > > > > > >>>> to a > > > > > > > > > >> > > > > > > > >>>>>>>> Broker > > > > > > > > > >> > > > > > > > >>>>>>>>>> are > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> not > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> high > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> volume, right ? > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> Thanks, > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> Mayuresh > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> On Tue, Jul 17, 2018 at > > > 5:06 > > > > AM > > > > > > > > Becket > > > > > > > > > >> Qin < > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> becket....@gmail.com> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> wrote: > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>>> Thanks for the KIP, > > Lucas. > > > > > > > > Separating > > > > > > > > > >> the > > > > > > > > > >> > > > > > > > >>>> control > > > > > > > > > >> > > > > > > > >>>>>>>> plane > > > > > > > > > >> > > > > > > > >>>>>>>>>> from > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> the > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> data > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> plane > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>>> makes a lot of sense. > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>>> > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>>> In the KIP you > mentioned > > > > that > > > > > > the > > > > > > > > > >> > > > > > > > >> controller > > > > > > > > > >> > > > > > > > >>>>>> request > > > > > > > > > >> > > > > > > > >>>>>>>>> queue > > > > > > > > > >> > > > > > > > >>>>>>>>>>> may > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> have > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> many > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>>> requests in it. Will > > this > > > > be a > > > > > > > > common > > > > > > > > > >> case? > > > > > > > > > >> > > > > > > > >>> The > > > > > > > > > >> > > > > > > > >>>>>>>>> controller > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>> requests > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> still > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>>> goes through the > > > > SocketServer. > > > > > > The > > > > > > > > > >> > > > > > > > >>> SocketServer > > > > > > > > > >> > > > > > > > >>>>>> will > > > > > > > > > >> > > > > > > > >>>>>>>>> mute > > > > > > > > > >> > > > > > > > >>>>>>>>>>> the > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> channel > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>> once > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>>> a request is read and > > put > > > > into > > > > > > the > > > > > > > > > >> request > > > > > > > > > >> > > > > > > > >>>>> channel. > > > > > > > > > >> > > > > > > > >>>>>>>> So > > > > > > > > > >> > > > > > > > >>>>>>>>>>>> assuming > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>> there > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>> is > > > > > > > > > >> > > > > > > > >>>>>>>>>>>>>>>>>>> only one connection > > > between > > > > > > > > controller > > > > > > > > > >> and > > > > > > > > > >> > > > > > > > >>> each > > > > > > > > > >> > > > > > > > >>>>>>>> broker, > > > > > > > > > >> > > > > > > > >>>>>>>>> on > > > > > > > > > >> > > > > > > > >>>>>>>>>>> the > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > >
