t; > The StreamsMetadata will tell you which instance, via HostInfo, has the
> > given key.
> >
> > HTH,
> > Damian
> >
> >
> >
> >
> > On Fri, 9 Sep 2016 at 16:56 Mikael Högqvist wrote:
> >
> > > Hi Damian,
> > >
&g
ease give it a go and thanks for your help in finding this issue.
>
> Thanks,
> Damian
>
> On Mon, 5 Sep 2016 at 22:07 Mikael Högqvist wrote:
>
> > Hi Damian,
> >
> > > > Failed to read key hello, org.mkhq.kafka.Topology$StoreUnavailable
> > >
Hi Damian,
> > Failed to read key hello, org.mkhq.kafka.Topology$StoreUnavailable
> > > Failed to read key hello, org.mkhq.kafka.Topology$KeyNotFound
> > > hello -> 10
> >
> >
> The case where you get KeyNotFound looks like a bug to me. This shouldn't
> happen. I can see why it might happen and we
t; 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 detail
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 re
