1. The controller -> broker communication doesn't have to be blocking. It just needs to call a callback on completion of a request. We can leave this out for now. It just means that we can't run the inter cluster communication through non-plaintext port until we port this code to the common network code. Similarly, currently, the replica fetcher code currently uses SimpleConsumer. We need to change that code too to support non-plaintext port across brokers. Haven't thought about this much. So, not sure whether it's better to replace the code with the new consumer client or with some special code over the common network client.
2. Yes, it does seem that Receive needs to expose some kind of api to get the ByteBuffer as we do in the Receiver in scala. Jay probably can comment on this better. Thanks, Jun On Mon, Apr 6, 2015 at 2:55 PM, Gwen Shapira <gshap...@cloudera.com> wrote: > Hi, > > I started work on converting core to use common network code and I ran into > two questions that hopefully someone can help me with: > > 1. BlockingChannel - Looks like the inter-broker communication is mostly > through blocking channel. There's no client equivalent (i.e client code is > all non-blocking). I was planning to leave this as is, but let me know if > the intention was to make all this communication non-blocking. > > 2. Receive & ByteBufferReceive - It looks like ByteBufferReceive is not > used anywhere. What was it planned for? > NetworkReceive implements payload() method that returns the backing buffer. > It is used all over the place (to create requests, responses, etc). Because > ByteBufferReceive doesn't implement payload() (and its not clear how it can > implement it), this means that payload() is not part of the Receive > interface, although I'm pretty sure it should be there. > Some explanation about the Receive interface and what is ByteBufferReceive > for will help. > > Gwen >
