One more thing, there is an example of an end-to-end REST service that demonstrates one possible way to query at https://github.com/confluentinc/examples/tree/master/kafka-streams/src/main/java/io/confluent/examples/streams/queryablestate <https://github.com/confluentinc/examples/tree/master/kafka-streams/src/main/java/io/confluent/examples/streams/queryablestate>. The instructions on how to run are in QueryableStateExample.java.
Thanks Eno > On 26 Aug 2016, at 18:07, Eno Thereska <eno.there...@gmail.com> wrote: > > Hi Mikael, > > Very good question. You are correct about the desired semantics. > > The semantic of case (a) depends on the local store as you mention. For case > (b), the final check is always performed again on get(), and if the store has > disappeared between the lookup and get, the user will get an exception and > will have to retry. The state store in A does become invalid when the state > is re-assigned. There isn't any other way to detect the change, since we > wanted to hide the system details (e.g., rebalance) from the user. > > Does this make sense? > > Thanks > Eno > >> On 26 Aug 2016, at 16:26, Mikael Högqvist <hoegqv...@gmail.com> wrote: >> >> Hi, >> >> I've tried to understand the implementation and APIs from KIP-67 and would >> like to know the possible semantics for read requests from a client >> perspective. As a developer of a queryable state client, the access >> semantics I would like to have (I think...) is one where subsequent reads >> always return the value from the last read or a newer value (if the state >> store is available). This should be independent of the current system >> configuration, e.g. re-balancing, failures etc. . >> >> A client-side get(k) can be implemented by starting with a lookup for the >> instances that store k followed by a retrieve of the value associated with >> k from the instances returned by the lookup. In the worst case we can >> always do scatter+gather over all instances. >> >> We can start by considering a get(k) under two failure-free cases: a) >> single instance and b) a system going from one instance to two instances. In >> case a) the lookup will always return the same instance and the following >> get will read from a local store. The semantics in this case depends on the >> local store. >> >> For case b) the lookup returns instance A, but in between the lookup and >> the get, a new instance B is introduced to which k is transferred? Does the >> state store on A become invalid when the state is re-assigned? Is there >> another way for the client to detect the change? >> >> Best Regards, >> Mikael >
