Hi, Mani, If a token expires, then every broker will potentially try to delete it around the same time, but only one will succeed. So, we will have to deal with failures in that case? Another way is to let just one broker (say, the controller) deletes expired tokens.
It would also be helpful for others to give feedback on this KIP. Rajini, Gwen, Ismael? Thanks, Jun On Sun, Feb 5, 2017 at 9:54 AM, Manikumar <manikumar.re...@gmail.com> wrote: > Hi Jun, > > Please see the replies inline. > > > > > > > > Only one broker does the deletion. Broker updates the expiration in its > > > local cache > > > and on zookeeper so other brokers also get notified and their cache > > > statuses are updated as well. > > > > > > > > Which broker does the deletion? > > > > Any broker can handle the create/expire/renew/describe delegationtoken > requests. > changes are propagated through zk notifications. Every broker is > responsible for > expiring the tokens. This check be can done during request handling time > and/or > during token authentication time. > > > > > > > > 110. The diagrams in the wiki still show MD5 digest. Could you change it > to > > SCRAM? > > > > > Updated the diagram. > > > > Thanks, > Manikumar > > > > > > > > > > > > > > Thanks. > > > Manikumar > > > > > > > > > > > > > > On Fri, Dec 23, 2016 at 9:26 AM, Manikumar < > manikumar.re...@gmail.com> > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > I would like to initiate the vote on KIP-48: > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+ > > > > > Delegation+token+support+for+Kafka > > > > > > > > > > > > > > > Thanks, > > > > > Manikumar > > > > > > > > > > > > > > >
