I agree too. Casting also makes it harder to rely on static analysis tools
to detect unsafe code usage.
Ismael
On Wed, Jul 13, 2016 at 7:37 PM, Damian Guy <damian....@gmail.com> wrote:
> I'm in agreement with Gouzhang. Further, from a "Developer Experience" PoV
> IMO we should avoid forcing developers to cast - it doesn't make for nice
> and easy to use API, introduces possible runtime errors due to invalid
> casts, developers need to know what they are casting to.
>
> On Wed, 13 Jul 2016 at 10:47 Guozhang Wang <wangg...@gmail.com> wrote:
>
> > Personally I think the additional complexity of the introduced "
> > QueryableStoreType" interface is still acceptable from a user's point of
> > view: this is the only interface we are exposing to users, and other
> > wrappers are all internal classes.
> >
> > Regarding "QueryableStoreTypes", maybe we can consider declaring its
> > "QueryableStoreTypeMatcher" as private instead of public, since
> > "QueryableStoreTypes" is just used as a convenient manner for using
> > library-provided types, like serialization/Serdes.java.
> >
> > With this the only additional interface the library is exposing is "
> > QueryableStoreType", and users optionally can just use
> > "QueryableStoreTypes"
> > to conveniently create library-provided store types.
> >
> >
> > Guozhang
> >
> >
> > On Wed, Jul 13, 2016 at 7:58 AM, Neha Narkhede <n...@confluent.io>
> wrote:
> >
> > > Damian -- appreciate the example code and you convinced me. Agree that
> > the
> > > class approach is better and renaming to KafkaStreamsMetadata along
> with
> > > renaming the API methods will address the issues I was referring to.
> > >
> > > One other thing I wanted to get people's thoughts on was the way we are
> > > proposing to handle different store types. I am sure you guys have
> > thought
> > > about the tradeoffs of using the store wrappers and matchers (
> > > QueryableStoreType) vs just making users cast the returned store to the
> > > type they would expect to use. That is simple but the obvious downside
> is
> > > that it is likely to result in exceptions for users that don't know
> what
> > > they are doing.
> > >
> > > In my experience of dealing with apps that would use queriable state,
> it
> > > appears to me that a majority would just use the key value store.
> Partly
> > > because that will suffice and partly because people might just follow
> the
> > > simpler examples we provide that use key-value store. For advanced
> users,
> > > they will be aware of the reason they want to use the windowed store
> and
> > > will know how to cast it. The advantage of the current approach is that
> > it
> > > is likely more robust and general but involves introduces more
> interfaces
> > > and wrapper code.
> > >
> > > I tend to prefer simplicity to optimize for the general case, but
> curious
> > > to get people's thoughts on this as well.
> > >
> > > On Wed, Jul 13, 2016 at 8:13 AM, Jim Jagielski <j...@jagunet.com>
> wrote:
> > >
> > > > IMO, that makes the most sense.
> > > >
> > > > > On Jul 12, 2016, at 5:11 PM, Ismael Juma <ism...@juma.me.uk>
> wrote:
> > > > >
> > > > > Hi Damian,
> > > > >
> > > > > How about StreamsMetadata instead? The general naming pattern seems
> > to
> > > > > avoid the `Kafka` prefix for everything outside of `KafkaStreams`
> > > itself.
> > > > >
> > > > > Ismael
> > > > >
> > > > > On Tue, Jul 12, 2016 at 7:14 PM, Damian Guy <damian....@gmail.com>
> > > > wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> I agree with point 1. application.server is a better name for the
> > > config
> > > > >> (we'll change this). However, on point 2 I think we should stick
> > > mostly
> > > > >> with what we already have. I've tried both ways of doing this when
> > > > working
> > > > >> on the JIRA and building examples and I find the current approach
> > more
> > > > >> intuitive and easier to use than the Map based approach.
> > > > >> However, there is probably a naming issue. We should rename
> > > > >> KafkaStreamsInstance to KafkaStreamsMetadata. This Class is very
> > > simple,
> > > > >> but provides all the information a developer needs to be able to
> > find
> > > > the
> > > > >> instance(s) of a Streams application that a particular store is
> > > running
> > > > on,
> > > > >> i.e.,
> > > > >>
> > > > >> public class KafkStreamsMetadata {
> > > > >> private final HostInfo hostInfo;
> > > > >> private final Set<String> stateStoreNames;
> > > > >> private final Set<TopicPartition> topicPartitions;
> > > > >>
> > > > >>
> > > > >> So using the API to route to a new host is fairly simple,
> > particularly
> > > > in
> > > > >> the case when you want to find the host for a particular key,
> i.e.,
> > > > >>
> > > > >> final KafkaStreams kafkaStreams = createKafkaStreams();
> > > > >> final KafkaStreamsMetadata streamsMetadata =
> > > > >> kafkaStreams.instanceWithKey("word-count", "hello",
> > > > >> Serdes.String().serializer());
> > > > >> http.get("http://"; + streamsMetadata.host() + ":" +
> > > > >> streamsMetadata.port() + "/get/word-count/hello");
> > > > >>
> > > > >>
> > > > >> And if you want to do a scatter gather approach:
> > > > >>
> > > > >> final KafkaStreams kafkaStreams = createKafkaStreams();
> > > > >> final Collection<KafkaStreamsMetadata> kafkaStreamsMetadatas =
> > > > >> kafkaStreams.allInstancesWithStore("word-count");
> > > > >> for (KafkaStreamsMetadata streamsMetadata :
> kafkaStreamsMetadatas) {
> > > > >> http.get("http://"; + streamsMetadata.host() + ":" +
> > > > >> streamsMetadata.port() + "/get/word-count/hello");
> > > > >> ...
> > > > >> }
> > > > >>
> > > > >>
> > > > >> And if you iterated over all instances:
> > > > >>
> > > > >> final KafkaStreams kafkaStreams = createKafkaStreams();
> > > > >> final Collection<KafkaStreamsMetadata> kafkaStreamsMetadatas =
> > > > >> kafkaStreams.allInstances();
> > > > >> for (KafkaStreamsMetadata streamsMetadata :
> kafkaStreamsMetadatas) {
> > > > >> if (streamsMetadata.stateStoreNames().contains("word-count")) {
> > > > >> http.get("http://"; + streamsMetadata.host() + ":" +
> > > > >> streamsMetadata.port() + "/get/word-count/hello");
> > > > >> ...
> > > > >> }
> > > > >> }
> > > > >>
> > > > >>
> > > > >> If we were to change this to use Map<HostInfo, Set<TaskMetadata>>
> > for
> > > > the
> > > > >> most part users would need to iterate over the entry or key set.
> > > > Examples:
> > > > >>
> > > > >> The finding an instance by key is a little odd:
> > > > >>
> > > > >> final KafkaStreams kafkaStreams = createKafkaStreams();
> > > > >> final Map<HostInfo, Set<TaskMetadata>> streamsMetadata =
> > > > >> kafkaStreams.instanceWithKey("word-count","hello",
> > > > >> Serdes.String().serializer());
> > > > >> // this is a bit odd as i only expect one:
> > > > >> for (HostInfo hostInfo : streamsMetadata.keySet()) {
> > > > >> http.get("http://"; + streamsMetadata.host() + ":" +
> > > > >> streamsMetadata.port() + "/get/word-count/hello");
> > > > >> }
> > > > >>
> > > > >>
> > > > >> The scatter/gather by store is fairly similar to the previous
> > example:
> > > > >>
> > > > >> final KafkaStreams kafkaStreams = createKafkaStreams();
> > > > >> final Map<HostInfo, Set<TaskMetadata>> streamsMetadata =
> > > > >> kafkaStreams.allInstancesWithStore("word-count");
> > > > >> for(HostInfo hostInfo : streamsMetadata.keySet()) {
> > > > >> http.get("http://"; + hostInfo.host() + ":" + hostInfo.port() +
> > > > >> "/get/word-count/hello");
> > > > >> ...
> > > > >> }
> > > > >>
> > > > >> And iterating over all instances:
> > > > >>
> > > > >> final Map<HostInfo, Set<TaskMetadata>> streamsMetadata =
> > > > >> kafkaStreams.allInstances();
> > > > >> for (Map.Entry<HostInfo, Set<TaskMetadata>> entry :
> > > > >> streamsMetadata.entrySet()) {
> > > > >> for (TaskMetadata taskMetadata : entry.getValue()) {
> > > > >> if (taskMetadata.stateStoreNames().contains("word-count"))
> {
> > > > >> http.get("http://"; + streamsMetadata.host() + ":" +
> > > > >> streamsMetadata.port() + "/get/word-count/hello");
> > > > >> ...
> > > > >> }
> > > > >> }
> > > > >> }
> > > > >>
> > > > >>
> > > > >> IMO - having a class we return is the better approach as it nicely
> > > wraps
> > > > >> the related things, i.e, host:port, store names, topic partitions
> > into
> > > > an
> > > > >> Object that is easy to use. Further we could add some behaviour to
> > > this
> > > > >> class if we felt it necessary, i.e, hasStore(storeName) etc.
> > > > >>
> > > > >> Anyway, i'm interested in your thoughts.
> > > > >>
> > > > >> Thanks,
> > > > >> Damian
> > > > >>
> > > > >> On Mon, 11 Jul 2016 at 13:47 Guozhang Wang <wangg...@gmail.com>
> > > wrote:
> > > > >>
> > > > >>> 1. Re StreamsConfig.USER_ENDPOINT_CONFIG:
> > > > >>>
> > > > >>> I agree with Neha that Kafka Streams can provide the bare minimum
> > > APIs
> > > > >> just
> > > > >>> for host/port, and user's implemented layer can provide URL /
> proxy
> > > > >> address
> > > > >>> they want to build on top of it.
> > > > >>>
> > > > >>>
> > > > >>> 2. Re Improving KafkaStreamsInstance interface:
> > > > >>>
> > > > >>> Users are indeed aware of "TaskId" class which is not part of
> > > internal
> > > > >>> packages and is exposed in PartitionGrouper interface that can be
> > > > >>> instantiated by the users, which is assigned with input topic
> > > > partitions.
> > > > >>> So we can probably change the APIs as:
> > > > >>>
> > > > >>> Map<HostState, Set<TaskMetadata>> KafkaStreams.getAllTasks()
> where
> > > > >>> TaskMetadata has fields such as taskId, list of assigned
> > partitions,
> > > > list
> > > > >>> of state store names; and HostState can include hostname / port.
> > The
> > > > port
> > > > >>> is the listening port of a user-defined listener that users
> provide
> > > to
> > > > >>> listen for queries (e.g., using REST APIs).
> > > > >>>
> > > > >>> Map<HostState, Set<TaskMetadata>>
> > > KafkaStreams.getTasksWithStore(String
> > > > >> /*
> > > > >>> storeName */) would return only the hosts and their assigned
> tasks
> > if
> > > > at
> > > > >>> least one of the tasks include the given store name.
> > > > >>>
> > > > >>> Map<HostState, Set<TaskMetadata>>
> > > > KafkaStreams.getTaskWithStoreAndKey(Key
> > > > >>> k, String /* storeName */, StreamPartitioner partitioner) would
> > > return
> > > > >> only
> > > > >>> the host and their assigned task if the store with the store name
> > > has a
> > > > >>> particular key, according to the partitioner behavior.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> Guozhang
> > > > >>>
> > > > >>>
> > > > >>> On Sun, Jul 10, 2016 at 11:21 AM, Neha Narkhede <
> n...@confluent.io
> > >
> > > > >> wrote:
> > > > >>>
> > > > >>>> Few thoughts that became apparent after observing example code
> of
> > > what
> > > > >> an
> > > > >>>> application architecture and code might look like with these
> > > changes.
> > > > >>>> Apologize for the late realization hence.
> > > > >>>>
> > > > >>>> 1. "user.endpoint" will be very differently defined for
> respective
> > > > >>>> applications. I don't think Kafka Streams should generalize to
> > > accept
> > > > >> any
> > > > >>>> connection URL as we expect to only expose metadata expressed as
> > > > >> HostInfo
> > > > >>>> (which is defined by host & port) and hence need to interpret
> the
> > > > >>>> "user.endpoint" as host & port. Applications will have their own
> > > > >> endpoint
> > > > >>>> configs that will take many forms and they will be responsible
> for
> > > > >>> parsing
> > > > >>>> out host and port and configuring Kafka Streams accordingly.
> > > > >>>>
> > > > >>>> If we are in fact limiting to host and port, I wonder if we
> should
> > > > >> change
> > > > >>>> the name of "user.endpoint" into something more specific. We
> have
> > > > >> clients
> > > > >>>> expose host/port pairs as "bootstrap.servers". Should this be
> > > > >>>> "application.server"?
> > > > >>>>
> > > > >>>> 2. I don't think we should expose another abstraction called
> > > > >>>> KafkaStreamsInstance to the user. This is related to the
> > discussion
> > > of
> > > > >>> the
> > > > >>>> right abstraction that we want to expose to an application. The
> > > > >>> abstraction
> > > > >>>> discussion itself should probably be part of the KIP itself, let
> > me
> > > > >> give
> > > > >>> a
> > > > >>>> quick summary of my thoughts here:
> > > > >>>> 1. The person implementing an application using Queryable State
> > has
> > > > >>> likely
> > > > >>>> already made some choices for the service layer–a REST
> framework,
> > > > >> Thrift,
> > > > >>>> or whatever. We don't really want to add another RPC framework
> to
> > > this
> > > > >>> mix,
> > > > >>>> nor do we want to try to make Kafka's RPC mechanism general
> > purpose.
> > > > >>>> 2. Likewise, it should be clear that the API you want to expose
> to
> > > the
> > > > >>>> front-end/client service is not necessarily the API you'd need
> > > > >> internally
> > > > >>>> as there may be additional filtering/processing in the router.
> > > > >>>>
> > > > >>>> Given these constraints, what we prefer to add is a fairly
> > low-level
> > > > >>>> "toolbox" that would let you do anything you want, but requires
> to
> > > > >> route
> > > > >>>> and perform any aggregation or processing yourself. This pattern
> > is
> > > > >>>> not recommended for all kinds of services/apps, but there are
> > > > >> definitely
> > > > >>> a
> > > > >>>> category of things where it is a big win and other advanced
> > > > >> applications
> > > > >>>> are out-of-scope.
> > > > >>>>
> > > > >>>> The APIs we expose should take the following things into
> > > > consideration:
> > > > >>>> 1. Make it clear to the user that they will do the routing,
> > > > >> aggregation,
> > > > >>>> processing themselves. So the bare minimum that we want to
> expose
> > is
> > > > >>> store
> > > > >>>> and partition metadata per application server identified by the
> > host
> > > > >> and
> > > > >>>> port.
> > > > >>>> 2. Ensure that the API exposes abstractions that are known to
> the
> > > user
> > > > >> or
> > > > >>>> are intuitive to the user.
> > > > >>>> 3. Avoid exposing internal objects or implementation details to
> > the
> > > > >> user.
> > > > >>>>
> > > > >>>> So tying all this into answering the question of what we should
> > > expose
> > > > >>>> through the APIs -
> > > > >>>>
> > > > >>>> In Kafka Streams, the user is aware of the concept of tasks and
> > > > >>> partitions
> > > > >>>> since the application scales with the number of partitions and
> > tasks
> > > > >> are
> > > > >>>> the construct for logical parallelism. The user is also aware of
> > the
> > > > >>>> concept of state stores though until now they were not user
> > > > accessible.
> > > > >>>> With Queryable State, the bare minimum abstractions that we need
> > to
> > > > >>> expose
> > > > >>>> are state stores and the location of state store partitions.
> > > > >>>>
> > > > >>>> For exposing the state stores, the getStore() APIs look good
> but I
> > > > >> think
> > > > >>>> for locating the state store partitions, we should go back to
> the
> > > > >>> original
> > > > >>>> proposal of simply exposing some sort of getPartitionMetadata()
> > that
> > > > >>>> returns a PartitionMetadata or TaskMetadata object keyed by
> > > HostInfo.
> > > > >>>>
> > > > >>>> The application will convert the HostInfo (host and port) into
> > some
> > > > >>>> connection URL to talk to the other app instances via its own
> RPC
> > > > >>> mechanism
> > > > >>>> depending on whether it needs to scatter-gather or just query.
> The
> > > > >>>> application will know how a key maps to a partition and through
> > > > >>>> PartitionMetadata it will know how to locate the server that
> hosts
> > > the
> > > > >>>> store that has the partition hosting that key.
> > > > >>>>
> > > > >>>> On Fri, Jul 8, 2016 at 9:40 AM, Michael Noll <
> > mich...@confluent.io>
> > > > >>> wrote:
> > > > >>>>
> > > > >>>>> Addendum in case my previous email wasn't clear:
> > > > >>>>>
> > > > >>>>>> So for any given instance of a streams application there will
> > > never
> > > > >>> be
> > > > >>>>> both a v1 and v2 alive at the same time
> > > > >>>>>
> > > > >>>>> That's right. But the current live instance will be able to
> tell
> > > > >> other
> > > > >>>>> instances, via its endpoint setting, whether it wants to be
> > > contacted
> > > > >>> at
> > > > >>>> v1
> > > > >>>>> or at v2. The other instances can't guess that. Think: if an
> > > older
> > > > >>>>> instance would manually compose the "rest" of an endpoint URI,
> > > having
> > > > >>>> only
> > > > >>>>> the host and port from the endpoint setting, it might not know
> > that
> > > > >> the
> > > > >>>> new
> > > > >>>>> instances have a different endpoint suffix, for example).
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> On Fri, Jul 8, 2016 at 6:37 PM, Michael Noll <
> > mich...@confluent.io
> > > >
> > > > >>>> wrote:
> > > > >>>>>
> > > > >>>>>> Damian,
> > > > >>>>>>
> > > > >>>>>> about the rolling upgrade comment: An instance A will contact
> > > > >>> another
> > > > >>>>>> instance B by the latter's endpoint, right? So if A has no
> > > further
> > > > >>>>>> information available than B's host and port, then how should
> > > > >>> instance
> > > > >>>> A
> > > > >>>>>> know whether it should call B at /v1/ or at /v2/? I agree
> that
> > my
> > > > >>>>>> suggestion isn't foolproof, but it is afaict better than the
> > > > >>> host:port
> > > > >>>>>> approach.
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> On Fri, Jul 8, 2016 at 5:15 PM, Damian Guy <
> > damian....@gmail.com>
> > > > >>>> wrote:
> > > > >>>>>>
> > > > >>>>>>> Michael - i'm ok with changing it to a string. Any one else
> > have
> > > a
> > > > >>>>> strong
> > > > >>>>>>> opinion on this?
> > > > >>>>>>>
> > > > >>>>>>> FWIW - i don't think it will work fine as is during the
> rolling
> > > > >>>> upgrade
> > > > >>>>>>> scenario as the service that is listening on the port needs
> to
> > be
> > > > >>>>> embedded
> > > > >>>>>>> within each instance. So for any given instance of a streams
> > > > >>>> application
> > > > >>>>>>> there will never be both a v1 and v2 alive at the same time
> > > > >> (unless
> > > > >>> of
> > > > >>>>>>> course the process didn't shutdown properly, but then you
> have
> > > > >>> another
> > > > >>>>>>> problem...).
> > > > >>>>>>>
> > > > >>>>>>> On Fri, 8 Jul 2016 at 15:26 Michael Noll <
> mich...@confluent.io
> > >
> > > > >>>> wrote:
> > > > >>>>>>>
> > > > >>>>>>>> I have one further comment about
> > > > >>>> `StreamsConfig.USER_ENDPOINT_CONFIG`.
> > > > >>>>>>>>
> > > > >>>>>>>> I think we should consider to not restricting the value of
> > this
> > > > >>>>> setting
> > > > >>>>>>> to
> > > > >>>>>>>> only `host:port` pairs. By design, this setting is
> capturing
> > > > >>>>>>> user-driven
> > > > >>>>>>>> metadata to define an endpoint, so why restrict the
> creativity
> > > > >> or
> > > > >>>>>>>> flexibility of our users? I can imagine, for example, that
> > > > >> users
> > > > >>>>> would
> > > > >>>>>>>> like to set values such as `https://host:port/api/rest/v1/`
> > in
> > > > >>> this
> > > > >>>>>>> field
> > > > >>>>>>>> (e.g. being able to distinguish between `.../v1/` and
> > `.../v2/`
> > > > >>> may
> > > > >>>>>>> help in
> > > > >>>>>>>> scenarios such as rolling upgrades, where, during the
> upgrade,
> > > > >>> older
> > > > >>>>>>>> instances may need to coexist with newer instances).
> > > > >>>>>>>>
> > > > >>>>>>>> That said, I don't have a strong opinion here.
> > > > >>>>>>>>
> > > > >>>>>>>> -Michael
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> On Fri, Jul 8, 2016 at 2:55 PM, Matthias J. Sax <
> > > > >>>>> matth...@confluent.io>
> > > > >>>>>>>> wrote:
> > > > >>>>>>>>
> > > > >>>>>>>>> +1
> > > > >>>>>>>>>
> > > > >>>>>>>>> On 07/08/2016 11:03 AM, Eno Thereska wrote:
> > > > >>>>>>>>>> +1 (non-binding)
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> On 7 Jul 2016, at 18:31, Sriram Subramanian <
> > > > >>> r...@confluent.io>
> > > > >>>>>>> wrote:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> +1
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> On Thu, Jul 7, 2016 at 9:53 AM, Henry Cai
> > > > >>>>>>> <h...@pinterest.com.invalid
> > > > >>>>>>>>>
> > > > >>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> +1
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> On Thu, Jul 7, 2016 at 6:48 AM, Michael Noll <
> > > > >>>>>>> mich...@confluent.io>
> > > > >>>>>>>>> wrote:
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>> +1 (non-binding)
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> On Thu, Jul 7, 2016 at 10:24 AM, Damian Guy <
> > > > >>>>>>> damian....@gmail.com>
> > > > >>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Thanks Henry - we've updated the KIP with an example
> and
> > > > >>> the
> > > > >>>>> new
> > > > >>>>>>>>> config
> > > > >>>>>>>>>>>>>> parameter required. FWIW the user doesn't register a
> > > > >>>> listener,
> > > > >>>>>>> they
> > > > >>>>>>>>>>>>> provide
> > > > >>>>>>>>>>>>>> a host:port in config. It is expected they will start
> a
> > > > >>>>> service
> > > > >>>>>>>>> running
> > > > >>>>>>>>>>>>> on
> > > > >>>>>>>>>>>>>> that host:port that they can use to connect to the
> > > > >> running
> > > > >>>>>>>>> KafkaStreams
> > > > >>>>>>>>>>>>>> Instance.
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Thanks,
> > > > >>>>>>>>>>>>>> Damian
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> On Thu, 7 Jul 2016 at 06:06 Henry Cai
> > > > >>>>>>> <h...@pinterest.com.invalid>
> > > > >>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> It wasn't quite clear to me how the user program
> > > > >>> interacts
> > > > >>>>> with
> > > > >>>>>>>> the
> > > > >>>>>>>>>>>>>>> discovery API, especially on the user supplied
> listener
> > > > >>>> part,
> > > > >>>>>>> how
> > > > >>>>>>>>>>>> does
> > > > >>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>> user program supply that listener to KafkaStreams and
> > > > >> how
> > > > >>>>> does
> > > > >>>>>>>>>>>>>> KafkaStreams
> > > > >>>>>>>>>>>>>>> know which port the user listener is running, maybe a
> > > > >>> more
> > > > >>>>>>>> complete
> > > > >>>>>>>>>>>>>>> end-to-end example including the steps on registering
> > > > >> the
> > > > >>>>> user
> > > > >>>>>>>>>>>> listener
> > > > >>>>>>>>>>>>>> and
> > > > >>>>>>>>>>>>>>> whether the user listener needs to be involved with
> > > > >> task
> > > > >>>>>>>>>>>> reassignment.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> On Wed, Jul 6, 2016 at 9:13 PM, Guozhang Wang <
> > > > >>>>>>> wangg...@gmail.com
> > > > >>>>>>>>>
> > > > >>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> ＋1
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> On Wed, Jul 6, 2016 at 12:44 PM, Damian Guy <
> > > > >>>>>>>> damian....@gmail.com>
> > > > >>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Hi all,
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> I'd like to initiate the voting process for KIP-67
> > > > >>>>>>>>>>>>>>>>> <
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-67%3A+Queryable+state+for+Kafka+Streams
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> KAFKA-3909 <
> > > > >>>>> https://issues.apache.org/jira/browse/KAFKA-3909
> > > > >>>>>>>>
> > > > >>>>>>>> is
> > > > >>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>> top
> > > > >>>>>>>>>>>>>>>>> level JIRA for this effort.
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Initial PRs for Step 1 of the process are:
> > > > >>>>>>>>>>>>>>>>> Expose State Store Names <
> > > > >>>>>>>>>>>>> https://github.com/apache/kafka/pull/1526>
> > > > >>>>>>>>>>>>>>> and
> > > > >>>>>>>>>>>>>>>>> Query Local State Stores <
> > > > >>>>>>>>>>>>> https://github.com/apache/kafka/pull/1565>
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Thanks,
> > > > >>>>>>>>>>>>>>>>> Damian
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>> -- Guozhang
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>> Best regards,
> > > > >>>>>>>>>>>>> Michael Noll
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> *Michael G. Noll | Product Manager | Confluent | +1
> > > > >>>>>>>>> 650.453.5860Download
> > > > >>>>>>>>>>>>> Apache Kafka and Confluent Platform:
> > > > >>>> www.confluent.io/download
> > > > >>>>>>>>>>>>> <http://www.confluent.io/download>*
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> --
> > > > >>>>>>>> Best regards,
> > > > >>>>>>>> Michael Noll
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> *Michael G. Noll | Product Manager | Confluent | +1
> > > > >>>>> 650.453.5860Download
> > > > >>>>>>>> Apache Kafka and Confluent Platform:
> > www.confluent.io/download
> > > > >>>>>>>> <http://www.confluent.io/download>*
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> --
> > > > >>>>>> Best regards,
> > > > >>>>>> Michael Noll
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> *Michael G. Noll | Product Manager | Confluent | +1
> 650.453.5860
> > > > >>>>>> <%2B1%20650.453.5860>Download Apache Kafka and Confluent
> > Platform:
> > > > >>>>>> www.confluent.io/download <http://www.confluent.io/download>*
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> --
> > > > >>>>> Best regards,
> > > > >>>>> Michael Noll
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> *Michael G. Noll | Product Manager | Confluent | +1
> > > > >>> 650.453.5860Download
> > > > >>>>> Apache Kafka and Confluent Platform: www.confluent.io/download
> > > > >>>>> <http://www.confluent.io/download>*
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> --
> > > > >>>> Thanks,
> > > > >>>> Neha
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> --
> > > > >>> -- Guozhang
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> > >
> > > --
> > > Thanks,
> > > Neha
> > >
> >
> >
> >
> > --
> > -- Guozhang
> >
>
