Thanks. I think I found a solution that doesn't take new locks or buffers: 1. Change the portProtocol map to ConcurrentHashMap (which makes it both thread-safe and mutable). Initialize as empty map. 2. Initialize both processors and acceptors with the hashmap, also tell each acceptor which protocol it is accepting 3. After the acceptors bind() but before run(), register them with the hashmap.
Anyone sees flaws here? On Sat, Apr 4, 2015 at 7:21 PM, Ashish Singh <asi...@cloudera.com> wrote: > Hi Gwen, > > Can we buffer the requests that arrive before acceptors are up. Once we > have the acceptors, the buffer can be cleared. However, this adds on to the > complexity. > > On Sunday, April 5, 2015, Gwen Shapira <gshap...@cloudera.com> wrote: > > > Hi, > > > > I'm trying to rebase KAFKA-1809 after KAFKA-1501 was committed, and I'm > > running into a chicken and egg problem. > > > > In my design, SocketServer creates a map of port->SecurityProtocol. > > This map is passed to Processor when it is initialized, and Processor > uses > > it to route requests to the correct channel. > > > > However, after KAFKA-1501, we may not know the ports until after > Acceptors > > are started, and we want to start Acceptors after Processors are already > > running... > > > > One solution is that if Processor finds that all keys in the map are "0", > > it will route all requests to PLAINTEXT channel. However, this will > prevent > > us from using the new port-binding test code when testing TLS and SASL, > > bringing the whole port randomization problem back. > > > > Another option is new flag that will allow us to bind Acceptors before > > starting Processors but not accept anything until this flag is set, after > > the Processors started? This seems a bit tricky though. > > > > Anyone has better ideas? > > > > Gwen > > > > > -- > > Regards, > Ashish >
