Re: Possible implementation for KAFKA-560

[Carlos Manuel Duclos-Vergara]

Hi,
Thanks for the answer. Looking at high water mark, then the logic would be
to flag the partitions that have

high_watermark == log_start_offset

In addition, I'm thinking that having the leader fulfill that criteria is
enough to flag a partition, maybe check the replicas only if requested by
the user.


fre. 21. jun. 2019, 23:35 skrev Colin McCabe :

> I don't think this requires a change in the protocol.  It seems like you
> should be able to use the high water mark to figure something out here?
>
> best,
> Colin
>
>
> On Fri, Jun 21, 2019, at 04:56, Carlos Manuel Duclos-Vergara wrote:
> > Hi,
> >
> > This is an ancient task, but I feel it is still current today (specially
> > since as somebody that deals with a Kafka cluster I know that this
> happens
> > more often than not).
> >
> > The task is about garbage collection of topics in a sort of automated
> way.
> > After some consideration I started a prototype implementation based on a
> > manual process:
> >
> > 1. Using the cli, I can use the --describe-topic to get a list of topics
> > that have size 0
> > 2. Massage that list into something that can be then fed into the cli and
> > remove the topics that have size 0.
> >
> > The guiding principle here is the assumption that abandoned topics will
> > eventually have size 0, because all records will expire. This is not true
> > for all topics, but it covers a large portion of them and having
> something
> > like this would help admins to find "suspicious" topics at least.
> >
> > I started implementing this change and I realized that it would require a
> > change in the protocol, because the sizes are never sent over the wire.
> > Funny enough we collect the sizes of the log files, but we do not send
> them.
> >
> > I think this kind of changes will require a KIP, but I wanted to ask what
> > others think about this.
> >
> > The in-progress implementation of this can be found here:
> >
> https://github.com/carlosduclos/kafka/commit/0dffe5e131c3bd32b77f56b9be8eded89a96df54
> >
> > Comments?
> >
> > --
> > Carlos Manuel Duclos Vergara
> > Backend Software Developer
> >
>

Re: [VOTE] 2.3.0 RC3

[Gwen Shapira]

+1 (binding)
Verified signatures, verified good build on jenkins, built from
sources anyway and ran quickstart on the 2.11 binary.

Looks good!

On Sun, Jun 23, 2019 at 3:06 PM Jakub Scholz  wrote:
>
> +1 (non-binding). I used the binaries and run some of my tests against them.
>
> On Thu, Jun 20, 2019 at 12:03 AM Colin McCabe  wrote:
>
> > Hi all,
> >
> > We discovered some problems with the second release candidate (RC2) of
> > 2.3.0.  Specifically, KAFKA-8564.  I've created a new RC which includes the
> > fix for this issue.
> >
> > Check out the release notes for the 2.3.0 release here:
> > https://home.apache.org/~cmccabe/kafka-2.3.0-rc3/RELEASE_NOTES.html
> >
> > The vote will go until Saturday, June 22nd, or until we create another RC.
> >
> > * Kafka's KEYS file containing PGP keys we use to sign the release can be
> > found here:
> > https://kafka.apache.org/KEYS
> >
> > * The release artifacts to be voted upon (source and binary) are here:
> > https://home.apache.org/~cmccabe/kafka-2.3.0-rc3/
> >
> > * Maven artifacts to be voted upon:
> > https://repository.apache.org/content/groups/staging/org/apache/kafka/
> >
> > * Javadoc:
> > https://home.apache.org/~cmccabe/kafka-2.3.0-rc3/javadoc/
> >
> > * The tag to be voted upon (off the 2.3 branch) is the 2.3.0 tag:
> > https://github.com/apache/kafka/releases/tag/2.3.0-rc3
> >
> > best,
> > Colin
> >
> > C.
> >



-- 
Gwen Shapira
Product Manager | Confluent
650.450.2760 | @gwenshap
Follow us: Twitter | blog

Re: [VOTE] KIP-476: Add Java AdminClient interface

[Colin McCabe]

Just to give a little context here, the main reason for having the 
AdminClient#create method is so that end-users didn't have to import 
KafkaAdminClient.  In general, users should be interacting with the AdminClient 
API, not with the implementation class(es).

Also, I have to grudgingly agree that marking the old AdminClient as deprecated 
will be a huge pain.  Especially in Scala, where we (currently, at least) have 
no way to suppress deprecation warnings.  So maybe we should not do that, just 
yet.

best,
Colin


On Fri, Jun 21, 2019, at 15:41, Matthias J. Sax wrote:
> I still think, that an interface does not need to know anything about
> its implementation. But I am also fine if we add a factory method to the
> new interface if that is preferred by most people.
> 
> 
> -Matthias
> 
> On 6/21/19 7:10 AM, Ismael Juma wrote:
> > This is even more reason not to deprecate immediately, there is very little
> > maintenance cost for us. We should be mindful that many of our users (eg
> > Spark, Flink, etc.) typically allow users to specify the kafka clients
> > version and hence avoid using new classes/interfaces for some time. They
> > would get a bunch of warnings they cannot do anything about apart from
> > suppressing.
> > 
> > Ismael
> > 
> > On Fri, Jun 21, 2019 at 4:00 AM Andy Coates  wrote:
> > 
> >> Hi Ismael,
> >>
> >> I’m happy enough to not deprecate the existing `AdminClient` class as part
> >> of this change.
> >>
> >> However, note that, the class will likely be empty, i.e. all methods and
> >> implementations will be inherited from the interface:
> >>
> >> public abstract class AdminClient implements Admin {
> >> }
> >>
> >> Not marking it as deprecated has the benefit that users won’t see any
> >> deprecation warnings on the next release. Conversely, deprecating it will
> >> mean we can choose to remove this, now pointless class, in the future if we
> >> choose.
> >>
> >> That’s my thinking for deprecation, but as I’ve said I’m happy either way.
> >>
> >> Andy
> >>
> >>> On 18 Jun 2019, at 16:09, Ismael Juma  wrote:
> >>>
> >>> I agree with Ryanne, I think we should avoid deprecating AdminClient and
> >>> causing so much churn for users who don't actually care about this niche
> >>> use case.
> >>>
> >>> Ismael
> >>>
> >>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates  wrote:
> >>>
>  Hi Ryanne,
> 
>  If we don't change the client code, then everywhere will still expect
>  subclasses of `AdminClient`, so the interface will be of no use, i.e. I
>  can't write a class that implements the new interface and pass it to the
>  client code.
> 
>  Thanks,
> 
>  Andy
> 
>  On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan 
> >> wrote:
> 
> > Andy, while I agree that the new interface is useful, I'm not convinced
> > adding an interface requires deprecating AdminClient and changing so
> >> much
> > client code. Why not just add the Admin interface, have AdminClient
> > implement it, and have done?
> >
> > Ryanne
> >
> > On Mon, Jun 17, 2019 at 12:09 PM Andy Coates 
> >> wrote:
> >
> >> Hi all,
> >>
> >> I think I've addressed all concerns. Let me know if I've not.  Can I
>  call
> >> another round of votes please?
> >>
> >> Thanks,
> >>
> >> Andy
> >>
> >> On Fri, 14 Jun 2019 at 04:55, Satish Duggana <
> >> satish.dugg...@gmail.com
> >
> >> wrote:
> >>
> >>> Hi Andy,
> >>> Thanks for the KIP. This is a good change and it gives the user a
> > better
> >>> handle on Admin client usage. I agree with the proposal except the
>  new
> >>> `Admin` interface having all the methods from `AdminClient` abstract
> >> class.
> >>> It should be kept clean having only the admin operations as methods
> > from
> >>> KafkaClient abstract class but not the factory methods as mentioned
>  in
> >> the
> >>> earlier mail.
> >>>
> >>> I know about dynamic proxies(which were widely used in RMI/EJB
>  world).
> > I
> >> am
> >>> curious about the usecase using dynamic proxies with Admin client
> >>> interface. Dynamic proxy can have performance penalty if it is used
>  in
> >>> critical path. Is that the primary motivation for creating the KIP?
> >>>
> >>> Thanks,
> >>> Satish.
> >>>
> >>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates 
>  wrote:
> >>>
>  I'm not married to that part.  That was only done to keep it more
>  or
> >> less
>  inline with what's already there, (an abstract class that has a
> > factory
>  method that returns a subclass sounds like the same
>  anti-pattern
> >> ;))
> 
>  An alternative would to have an `AdminClients` utility class to
> > create
> >>> the
>  admin client.
> 
>  On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax <
>  matth...@confluent.io
> 

Re: [DISCUSS] KIP-447: Producer scalability for exactly once semantics

[Guozhang Wang]

Hello Boyang,

Thanks for the KIP, I have some comments below:

1. "Once transactions are complete, the call will return." This seems
different from the existing behavior, in which we would return a retriable
CONCURRENT_TRANSACTIONS and let the client to retry, is this intentional?

2. "an overload to onPartitionsAssigned in the consumer's rebalance
listener interface": as part of KIP-341 we've already add this information
to the onAssignment callback. Would this be sufficient? Or more generally
speaking, which information have to be passed around in rebalance callback
while others can be passed around in PartitionAssignor callback? In Streams
for example both callbacks are used but most critical information is passed
via onAssignment.

3. "We propose to use a separate record type in order to store the group
assignment.": hmm, I thought with the third typed FindCoordinator, the same
broker that act as the  consumer coordinator would always be selected as
the txn coordinator, in which case it can access its local cache metadata /
offset topic to get this information already? We just need to think about
how to make these two modules directly exchange information without messing
up the code hierarchy.

4. The config of "CONSUMER_GROUP_AWARE_TRANSACTION": it seems the goal of
this config is just to avoid old-versioned broker to not be able to
recognize newer versioned client. I think if we can do something else to
avoid this config though, for example we can use the embedded AdminClient
to send the APIVersion request upon starting up, and based on the returned
value decides whether to go to the old code path or the new behavior.
Admittedly asking a random broker about APIVersion does not guarantee the
whole cluster's versions, but what we can do is to first 1) find the
coordinator (and if the random broker does not even recognize the new
discover type, fall back to old path directly), and then 2) ask the
discovered coordinator about its supported APIVersion.

5. This is a meta question: have you considered how this can be applied to
Kafka Connect as well? For example, for source connectors, the assignment
is not by "partitions", but by some other sort of "resources" based on the
source systems, how KIP-447 would affect Kafka Connectors that implemented
EOS as well?


Guozhang


On Sat, Jun 22, 2019 at 8:40 PM Ismael Juma  wrote:

> Hi Boyang,
>
> Thanks for the KIP. It's good that we listed a number of rejected
> alternatives. It would be helpful to have an explanation of why they were
> rejected.
>
> Ismael
>
> On Sat, Jun 22, 2019 at 8:31 PM Boyang Chen  wrote:
>
> > Hey all,
> >
> > I would like to start a discussion for KIP-447:
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-447%3A+Producer+scalability+for+exactly+once+semantics
> >
> > this is a work originated by Jason Gustafson and we would like to proceed
> > into discussion stage.
> >
> > Let me know your thoughts, thanks!
> >
> > Boyang
> >
>


-- 
-- Guozhang

Re: [DISCUSS] KIP-479: Add Materialized to Join

[Guozhang Wang]

Hi Bill,

I think by giving a Materialized param into stream-stream join, it's okay
(though still ideal) to say "we still would not expose the store for
queries", but it would sound a bit awkward to say "we would also ignore
whatever the passed in store supplier but just use our default ones" --
again the concern is that, if in the future we'd want to change the default
implementation of join algorithm which no longer rely on a window store
with deduping enabled, then we need to change this API again by changing
the store supplier type.

If we do want to fill this hole for stream-stream join, I feel just adding
a String typed store-name would even be less future-intrusive if we expect
this parameter to be modified later.

Does that makes sense?


Guozhang

On Sat, Jun 22, 2019 at 12:51 PM Bill Bejeck  wrote:

> Thanks for the comments John and Guozhang, I'll address each one of your
> comments in turn.
>
> John,
>
> > I'm wondering about a missing quadrant from the truth table involving
> > whether a Materialized is stored or not and querying is
> > enabled/disabled... What should be the behavior if there is no store
> > configured (e.g., if Materialized with only serdes) and querying is
> enabled?
>
> > It seems we have two choices:
> > 1. we can force creation of a state store in this case, so the store
> > can be used to serve the queries
> > 2. we can provide just a queriable view, basically letting IQ query
> > into the "KTableValueGetter", which would transparently construct the
> > query response by applying the operator logic to the upstream state if
> > the operator state isn't already stored.
>
>
> I agree with your assertion about a missing quadrant from the truth table.
> Additionally, I too like the concept of a queriable view.  But I think that
> goes a bit beyond the scope of this KIP and would like to pursue that
> feature as follow-on work.  Also thinking about this KIP some more, I'm
> thinking of the changes to Materialized might be a reach as well.
> Separating the naming from a store and its queryable state seems like a
> complex issue in and of itself and should be treated accordingly.
>
> So here's what I'm thinking now.  We add Materialzied to Join, but for now,
> we internally disable querying.  I know this breaks our current semantic
> approach, but I think it's crucial that we do two things in this KIP
>
>1. Break the naming of the state stores from Joined to Materialized, so
>the naming of state stores follows our current pattern and enables
> upgrades
>from 2.3 to 2.4
>2. Offer the ability to configure the state stores of the join, even
>providing a different implementation (i.e. in-memory) if desired.
>
> With that in mind I'm considering changing the KIP to remove the changes to
> Materialized, and we document very clearly that by providing a Materialized
> object with a name is only for naming the state store, hence the changelog
> topics and any possible configurations of the store, but this store *will
> not be available for IQ.*
>
> WDYT?
>
> Guozhang,
>
> > 1. About not breaking compatibility of stream-stream join materialized
> > stores: I think this is a valid issue to tackle, but after thinking about
> > it once more I'm not sure if exposing Materialized would be a good
> solution
> > here. My rationles:
> >
> > 1.a For stream-stream join, our current usage of window-store is not
> ideal,
> > and we want to modify it in the near future to be more efficient. Not
> > allowing users to override such state store backend gives us such freedom
> > (which was also considered in the original DSL design), whereas getting a
> > Materialized basically kicks out that freedom out of the
> > window.
> > 1.b For strema-stream join, in our original design we intend to "never"
> > want users to query the state, since it is just for buffering the
> upcoming
> > records from the stream. Now I know that some users may indeed want to
> > query it from the debugging perspective, but still I concerned about
> > whether leveraging IQ for debugging purposes would be the right solution
> > here. And adding Materialized object opens the door to let users query
> > about it (unless we did something intentionally to still forbids it),
> which
> > also restricts us in the future.
> >
> > 2. About the coupling between Materialized.name() and queryable: again I
> > think this is a valid issue. But I'm not sure if the current
> > "withQuerryingDisabled / Enabled" at Materialized is the best approach.
> > Here I think I agree with John, that generally speaking it's better be a
> > control function on the `KTable` itself, rather than on `Materialized`,
> so
> > fixing it via adding functions through `Materialized` seems not a natural
> approach either.
>
> I understand your thoughts here, and up to a point, I agree with you.
> But concerning not providing Materialized as it may restrict us in the
> future for delivering different implementations, I'm wondering if we are
> doing 

Re: [DISCUSS] KIP-478 Strongly Typed Processor API

[Guozhang Wang]

Hello John,

Thanks for your detailed explanation, I've done some quick checks on some
existing examples that heavily used Processor and the results also makes me
worried about my previous statements that "the breakage would not be big".
I agree we should maintain compatibility.

About the naming itself, I'm actually a bit inclined into sub-packages than
renamed new classes, and my motivations are that our current packaging is
already quite coarsen grained and sometimes ill-placed, and hence maybe we
can take this change along with some clean up on packages (but again, we
should follow the deprecate - removal path). What I'm thinking is:

---

processor/: StateRestoreCallback/AbstractNotifyingRestoreCallback, (deprecated
later, same meaning for other cross-throughs), ProcessContest,
RecordContext, Punctuator, PunctuationType, To, Cancellable (are the only
things left)

(new) processor/api/: Processor, ProcessorSupplier (and of course, these
two classes can be strong typed)

state/: StateStore, BatchingStateRestoreCallback,
AbstractNotifyingBatchingRestoreCallback (moved from processor/),
PartitionGrouper, WindowStoreIterator, StateSerdes (this one can be moved
into state/internals), TimestampedByteStore (we can move this to internals
since store types would use vat by default, see below), ValueAndTimestamp

(new) state/factory/: Stores, StoreBuilder, StoreSupplier; *BUT* the new
Stores would not have timestampedXXBuilder APIs since the default
StoreSupplier / StoreBuilder value types are ValueAndTimestamp already.

(new) state/queryable/: QueryableStoreType, QueryableStoreTypes, HostInfo

(new) state/keyValue/: KeyValueXXX classes, and also the same for
state/sessionWindow and state/timeWindow; *BUT* here we use
ValueAndTimestamp as value types of those APIs directly, and also
TimestampedKeyValue/WindowStore would be deprecated.

(new) kstream/api/: KStream, KTable, GroupedKStream (renamed from
KGroupedStream), GroupedKTable (renamed from KGroupedTable),
TimeWindowedKStream, SessionWindowedKStream, GlobalKTable

(new) kstream/operator/: Aggregator, ForeachFunction,  ... , Merger and
Grouped, Joined, Materialized, ... , Printed and Transformer,
TransformerSupplier.

(new) kstream/window/: Window, Windows, Windowed, TimeWindows,
SessionWindows, UnlimitedWindows, JoinWindows, WindowedSerdes,
Time/SessionWindowedSerialized/Deserializer.

(new) configure/: RocksDBConfigSetter, TopicNameExtractor,
TimestampExtractor, UsePreviousTimeOnInvalidTimestamp,
WallclockTimestampExtractor, ExtractRecordMetadataTimestamp,
FailOnInvalidTimestamp, LogAndSkipOnInvalidTimestamp, StateRestoreListener,

(new) metadata/: StreamsMetadata, ThreadMetadata, TaskMetadata, TaskId

Still, any xxx/internals packages are declared as inner classes, but other
xxx/yyy packages are declared as public APIs.

---

This is a very wild thought and I can totally understand if people feel
this is too much since it definitely enlarges the scope of this KIP a lot
:) just trying to play a devil's advocate here to do major refactoring and
avoid renaming Processor classes.


Guozhang


On Fri, Jun 21, 2019 at 9:51 PM Matthias J. Sax 
wrote:
>
> I think `RecordProcessor` is a good name.
>
>
> -Matthias
>
> On 6/21/19 5:09 PM, John Roesler wrote:
> > After kicking the naming around a bit more, it seems like any package
> > name change is a bit "weird" because it fragments the package and
> > directory structure. If we can come up with a reasonable name for the
> > interface after all, it seems like the better choice.
> >
> > The real challenge is that the existing name "Processor" seems just
> > about perfect. In picking a new name, we need to consider the ultimate
> > state, after the deprecation period, when we entirely remove
> > Processor. In this context, TypedProcessor seems a little odd to me,
> > because it seems to imply that there should also be an "untyped
> > processor".
> >
> > After kicking around a few other ideas, what does everyone think about
> > "RecordProcessor"? I _think_ maybe it stands on its own just fine,
> > because it's a thing that processes... records?
> >
> > If others agree with this, I can change the proposal to RecordProcessor.
> >
> > Thanks,
> > -John
> >
> > On Fri, Jun 21, 2019 at 6:42 PM John Roesler  wrote:
> >>
> >> Hi all,
> >>
> >> I've updated the KIP with the feedback so far.
> >>
> >> The naming question is still the biggest (only?) outstanding issue. It
> >> would be good to hear some more thoughts on it.
> >>
> >> As we stand now, there's one vote for changing the package name to
> >> something like 'typedprocessor', one for changing the interface to
> >> TypedProcessor (as in the PoC), and one for just changing the
> >> Processor interface in-place, breaking source compatibility.
> >>
> >> How can we resolve this decision?
> >>
> >> Thanks,
> >> -John
> >>
> >> On Thu, Jun 20, 2019 at 5:44 PM John Roesler  wrote:
> >>>
> >>> Thanks for the feedback, Guozhang and Matthias,
> 

[jira] [Created] (KAFKA-8590) Replace TxnOffsetCommitRequest request/response with automated protocol

[Boyang Chen (JIRA)]

Boyang Chen created KAFKA-8590:
--

 Summary: Replace TxnOffsetCommitRequest request/response with 
automated protocol
 Key: KAFKA-8590
 URL: https://issues.apache.org/jira/browse/KAFKA-8590
 Project: Kafka
  Issue Type: Sub-task
Reporter: Boyang Chen
Assignee: Boyang Chen






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Permissions for creating KIP

[Guozhang Wang]

Hello Levani,

You should be able to create new wiki page now.

Thanks,
Guozhang

On Sun, Jun 23, 2019 at 3:18 PM Levani Kokhreidze 
wrote:

> Hi,
>
> Please give me permission for creating KIP <
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals>.
> You can find link to my profile on confluence here <
> https://cwiki.apache.org/confluence/display/~lkokhreidze>.
>
> Kind regards,
> Levani



-- 
-- Guozhang

Permissions for creating KIP

[Levani Kokhreidze]

Hi,

Please give me permission for creating KIP 
.
 You can find link to my profile on confluence here 
.

Kind regards,
Levani

Re: Preliminary blog post for the Apache Kafka 2.3.0 release

[Stephane Maarek]

The video is ready :) waiting for the release of Kafka 2.3 to make it
public. @colin if you want to link it in the blog at some point that'd be
great!

On Wed., 19 Jun. 2019, 4:03 pm Ron Dagostino,  wrote:

> Looks great, Colin.
>
> I have also enjoyed Stephane Maarek's "What's New in Kafka..." series of
> videos (e.g. https://www.youtube.com/watch?v=kaWbp1Cnfo4=10s).  Having
> summaries like this in both formats -- blog and video -- for every release
> would be helpful as different people have different preferences.
>
> Ron
>
> On Tue, Jun 18, 2019 at 8:20 PM Colin McCabe  wrote:
>
> > Thanks, Konstantine.  I reworked the wording a bit -- take a look.
> >
> > best,
> > C.
> >
> > On Tue, Jun 18, 2019, at 14:31, Konstantine Karantasis wrote:
> > > Thanks Colin.
> > > Great initiative!
> > >
> > > Here's a small correction (between **) for KIP-415 with a small
> > suggestion
> > > as well (between _ _):
> > >
> > > In Kafka Connect, worker tasks are distributed among the available
> worker
> > > nodes. When a connector is reconfigured or a new connector is deployed
> > _as
> > > well as when a worker is added or removed_, the *tasks* must be
> > rebalanced
> > > across the Connect cluster to help ensure that all of the worker nodes
> > are
> > > doing a fair share of the Connect work. In 2.2 and earlier, a Connect
> > > rebalance caused all worker threads to pause while the rebalance
> > proceeded.
> > > As of KIP-415, rebalancing is no longer a stop-the-world affair, making
> > > configuration changes a more pleasant thing.
> > >
> > > Cheers,
> > > Konstantine
> > >
> > > On Tue, Jun 18, 2019 at 1:50 PM Swen Moczarski <
> swen.moczar...@gmail.com
> > >
> > > wrote:
> > >
> > > > Nice overview!
> > > >
> > > > I found some typos:
> > > > rbmainder
> > > > bmits
> > > > implbmentation
> > > >
> > > > Am Di., 18. Juni 2019 um 22:43 Uhr schrieb Boyang Chen <
> > > > bche...@outlook.com
> > > > >:
> > > >
> > > > > One typo:
> > > > > KIP-428: Add in-mbmory window store
> > > > > should be
> > > > > KIP-428: Add in-memory window store
> > > > >
> > > > >
> > > > > 
> > > > > From: Colin McCabe 
> > > > > Sent: Wednesday, June 19, 2019 4:22 AM
> > > > > To: dev@kafka.apache.org
> > > > > Subject: Re: Preliminary blog post for the Apache Kafka 2.3.0
> release
> > > > >
> > > > > Sorry, I copied the wrong URL at first.  Try this URL instead:
> > > > >
> > > >
> >
> https://blogs.apache.org/preview/kafka/?previewEntry=what-s-new-in-apache
> > > > >
> > > > > best,
> > > > > Colin
> > > > >
> > > > > On Tue, Jun 18, 2019, at 13:17, Colin McCabe wrote:
> > > > > > Hmm.  I'm looking to see if there's any way to open up the
> > > > > permissions... :|
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Jun 18, 2019, at 13:12, M. Manna wrote:
> > > > > > > It’s asking for credentials...?
> > > > > > >
> > > > > > > On Tue, 18 Jun 2019 at 15:10, Colin McCabe  >
> > > > wrote:
> > > > > > >
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > I've written up a preliminary blog post about the upcoming
> > Apache
> > > > > Kafka
> > > > > > > > 2.3.0 release.  Take a look and let me know what you think.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > >
> > > >
> >
> https://blogs.apache.org/roller-ui/authoring/preview/kafka/?previewEntry=what-s-new-in-apache
> > > > > > > >
> > > > > > > > cheers,
> > > > > > > > Colin
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] 2.3.0 RC3

[Jakub Scholz]

+1 (non-binding). I used the binaries and run some of my tests against them.

On Thu, Jun 20, 2019 at 12:03 AM Colin McCabe  wrote:

> Hi all,
>
> We discovered some problems with the second release candidate (RC2) of
> 2.3.0.  Specifically, KAFKA-8564.  I've created a new RC which includes the
> fix for this issue.
>
> Check out the release notes for the 2.3.0 release here:
> https://home.apache.org/~cmccabe/kafka-2.3.0-rc3/RELEASE_NOTES.html
>
> The vote will go until Saturday, June 22nd, or until we create another RC.
>
> * Kafka's KEYS file containing PGP keys we use to sign the release can be
> found here:
> https://kafka.apache.org/KEYS
>
> * The release artifacts to be voted upon (source and binary) are here:
> https://home.apache.org/~cmccabe/kafka-2.3.0-rc3/
>
> * Maven artifacts to be voted upon:
> https://repository.apache.org/content/groups/staging/org/apache/kafka/
>
> * Javadoc:
> https://home.apache.org/~cmccabe/kafka-2.3.0-rc3/javadoc/
>
> * The tag to be voted upon (off the 2.3 branch) is the 2.3.0 tag:
> https://github.com/apache/kafka/releases/tag/2.3.0-rc3
>
> best,
> Colin
>
> C.
>

[jira] [Created] (KAFKA-8589) Flakey test ResetConsumerGroupOffsetTest#testResetOffsetsExistingTopic

[Boyang Chen (JIRA)]

Boyang Chen created KAFKA-8589:
--

 Summary: Flakey test 
ResetConsumerGroupOffsetTest#testResetOffsetsExistingTopic
 Key: KAFKA-8589
 URL: https://issues.apache.org/jira/browse/KAFKA-8589
 Project: Kafka
  Issue Type: Bug
Reporter: Boyang Chen


[https://builds.apache.org/job/kafka-pr-jdk11-scala2.12/5724/consoleFull]
*20:25:15* 
kafka.admin.ResetConsumerGroupOffsetTest.testResetOffsetsExistingTopic failed, 
log available in 
/home/jenkins/jenkins-slave/workspace/kafka-pr-jdk11-scala2.12/core/build/reports/testOutput/kafka.admin.ResetConsumerGroupOffsetTest.testResetOffsetsExistingTopic.test.stdout*20:25:15*
 *20:25:15* kafka.admin.ResetConsumerGroupOffsetTest > 
testResetOffsetsExistingTopic FAILED*20:25:15* 
java.util.concurrent.ExecutionException: 
org.apache.kafka.common.errors.CoordinatorNotAvailableException: The 
coordinator is not available.*20:25:15* at 
org.apache.kafka.common.internals.KafkaFutureImpl.wrapAndThrow(KafkaFutureImpl.java:45)*20:25:15*
 at 
org.apache.kafka.common.internals.KafkaFutureImpl.access$000(KafkaFutureImpl.java:32)*20:25:15*
 at 
org.apache.kafka.common.internals.KafkaFutureImpl$SingleWaiter.await(KafkaFutureImpl.java:89)*20:25:15*
 at 
org.apache.kafka.common.internals.KafkaFutureImpl.get(KafkaFutureImpl.java:260)*20:25:15*
 at 
kafka.admin.ConsumerGroupCommand$ConsumerGroupService.$anonfun$resetOffsets$1(ConsumerGroupCommand.scala:379)*20:25:15*
 at 
scala.collection.TraversableOnce.$anonfun$foldLeft$1(TraversableOnce.scala:160)*20:25:15*
 at 
scala.collection.TraversableOnce.$anonfun$foldLeft$1$adapted(TraversableOnce.scala:160)*20:25:15*
 at scala.collection.Iterator.foreach(Iterator.scala:941)*20:25:15* 
at scala.collection.Iterator.foreach$(Iterator.scala:941)*20:25:15* 
at scala.collection.AbstractIterator.foreach(Iterator.scala:1429)*20:25:15* 
at scala.collection.IterableLike.foreach(IterableLike.scala:74)*20:25:15*   
  at 
scala.collection.IterableLike.foreach$(IterableLike.scala:73)*20:25:15* 
at scala.collection.AbstractIterable.foreach(Iterable.scala:56)*20:25:15*   
  at 
scala.collection.TraversableOnce.foldLeft(TraversableOnce.scala:160)*20:25:15*  
   at 
scala.collection.TraversableOnce.foldLeft$(TraversableOnce.scala:158)*20:25:15* 
at 
scala.collection.AbstractTraversable.foldLeft(Traversable.scala:108)*20:25:15*  
   at 
kafka.admin.ConsumerGroupCommand$ConsumerGroupService.resetOffsets(ConsumerGroupCommand.scala:377)*20:25:15*
 at 
kafka.admin.ResetConsumerGroupOffsetTest.resetOffsets(ResetConsumerGroupOffsetTest.scala:507)*20:25:15*
 at 
kafka.admin.ResetConsumerGroupOffsetTest.resetAndAssertOffsets(ResetConsumerGroupOffsetTest.scala:477)*20:25:15*
 at 
kafka.admin.ResetConsumerGroupOffsetTest.testResetOffsetsExistingTopic(ResetConsumerGroupOffsetTest.scala:123)*20:25:15*
 *20:25:15* Caused by:*20:25:15* 
org.apache.kafka.common.errors.CoordinatorNotAvailableException: The 
coordinator is not available.*20*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] KIP-475: New Metric to Measure Number of Tasks on a Connector

[Andrew Schofield]

+1 (non-binding). Nice KIP.

On 23/06/2019, 17:27, "Gwen Shapira"  wrote:

+1 from me too

On Tue, Jun 18, 2019, 10:30 AM Guozhang Wang  wrote:

> Cyrus, thanks for the updates, +1.
>
> On Mon, Jun 17, 2019 at 10:58 PM Cyrus Vafadari 
> wrote:
>
> > Many thanks for the feedback. Per Gwen's suggestion, I've updated the 
KIP
> > to specify that the task count will be per-worker (no additional MBean
> tag,
> > since each process is a worker) and per-connector (MBean tag).
> >
> > On Mon, Jun 17, 2019 at 8:24 PM Cyrus Vafadari 
> wrote:
> >
> > > I meant to write:
> > > I've also updated the KIP to clarify that every task must have exactly
> > one
> > > non-null *status* at all times.
> > >
> > > On Mon, Jun 17, 2019 at 6:55 PM Cyrus Vafadari 
> > wrote:
> > >
> > >> Guozhang,
> > >>
> > >> Both of Kafka's implementations of "StatusBackingStore" immediately
> > >> delete the task from the backign store when you try to set it to
> > DESTROYED,
> > >> so we'd actually expect it to always be zero. A nonzero number of
> > destroyed
> > >> tasks would either indicate a new implementation of
> StatusBackingStore,
> > or
> > >> a malfunctioning StatusBackingStore (e.g. caches out of sync with
> > compacted
> > >> topic). This metric will usually be uninteresting, and was only
> included
> > >> for completeness. It could possibly catch a bug.
> > >>
> > >> Gwen,
> > >> I had not considered this option. I agree there is an advantage to
> > having
> > >> more granular data about both connector and worker. The main
> > disadvantage
> > >> would be that it increases the number of metrics by a factor of
> > >> num_workers, but I'd say this is an acceptable tradeoff. Another
> > advantage
> > >> of your suggestion is that the public interfaces for WorkerConnector
> > would
> > >> be unchanged, and the new metrics can be added within the Worker
> class.
> > >>
> > >> I've also updated the KIP to clarify that every task must have 
exactly
> > >> one non-null task at all times.
> > >>
> > >> On Mon, Jun 17, 2019 at 1:41 PM Guozhang Wang 
> > wrote:
> > >>
> > >>> Hello Cyrus,
> > >>>
> > >>> Thanks for the KIP. I just have one nit question about Connect
> > destroyed
> > >>> tasks: is it an ever-increasing number? If yes, the corresponding
> > metric
> > >>> value would be increasing indefinitely as well. Is that intentional?
> > >>>
> > >>> Otherwise, lgtm.
> > >>>
> > >>>
> > >>> Guozhang
> > >>>
> > >>> On Mon, Jun 17, 2019 at 1:14 PM Gwen Shapira 
> > wrote:
> > >>>
> > >>> > Sorry to join so late, but did we consider a single set of
> task-count
> > >>> > metrics and using tags to scope each data point to a specific
> > >>> > connector and worker (and in the future perhaps also user)?
> > >>> >
> > >>> > It will make analysis of the data easier - someone may want to
> > >>> > breakdown tasks by both worker and connector to detect imbalanced
> > >>> > assignments.
> > >>> >
> > >>> > Are there downsides to this approach?
> > >>> >
> > >>> > And a small nit: it will be good to capture in the KIP what are 
the
> > >>> > expectations regarding overlap and disjointness of the proposed
> > >>> > metrics. For example, is running+paused+failed = total? Can a task
> be
> > >>> > failed and destroyed and therefore count in 2 of those metrics?
> > >>> >
> > >>> > On Thu, Jun 6, 2019 at 12:29 PM Cyrus Vafadari  >
> > >>> wrote:
> > >>> > >
> > >>> > > Konstantine,
> > >>> > >
> > >>> > > This is a good suggestion. Since the suggestion to add 2
> additional
> > >>> > > statuses analogous to the 3 proposed, it is a very minor change
> of
> > no
> > >>> > > structural consequence to the KIP.
> > >>> > >
> > >>> > > I've updated the KIP to incorporate your suggestion, and any
> voters
> > >>> who
> > >>> > > disagree should definitely respond in the thread.
> > >>> > >
> > >>> > > Cyrus
> > >>> > >
> > >>> > > On Thu, Jun 6, 2019 at 11:16 AM Konstantine Karantasis <
> > >>> > > konstant...@confluent.io> wrote:
> > >>> > >
> > >>> > > > Thanks Cyrus,
> > >>> > > >
> > >>> > > > this is a nice and straightforward addition.
> > >>> > > >
> > >>> > > > I'm +1 too, but I'd like to return with a question here as 
well
> > >>> > regarding
> > >>> > > > whether the unassigned tasks will be taken into account.
> > >>> > > > Especially after KIP-415 we might start seeing this status for
> > >>> specific
> > >>> > > > periods of time. Therefore, I think it's a meaningful 
addition.
> > >>> > > > Then there's the `destroyed` status which might be a lot 

Re: [VOTE] KIP-475: New Metric to Measure Number of Tasks on a Connector

[Gwen Shapira]

+1 from me too

On Tue, Jun 18, 2019, 10:30 AM Guozhang Wang  wrote:

> Cyrus, thanks for the updates, +1.
>
> On Mon, Jun 17, 2019 at 10:58 PM Cyrus Vafadari 
> wrote:
>
> > Many thanks for the feedback. Per Gwen's suggestion, I've updated the KIP
> > to specify that the task count will be per-worker (no additional MBean
> tag,
> > since each process is a worker) and per-connector (MBean tag).
> >
> > On Mon, Jun 17, 2019 at 8:24 PM Cyrus Vafadari 
> wrote:
> >
> > > I meant to write:
> > > I've also updated the KIP to clarify that every task must have exactly
> > one
> > > non-null *status* at all times.
> > >
> > > On Mon, Jun 17, 2019 at 6:55 PM Cyrus Vafadari 
> > wrote:
> > >
> > >> Guozhang,
> > >>
> > >> Both of Kafka's implementations of "StatusBackingStore" immediately
> > >> delete the task from the backign store when you try to set it to
> > DESTROYED,
> > >> so we'd actually expect it to always be zero. A nonzero number of
> > destroyed
> > >> tasks would either indicate a new implementation of
> StatusBackingStore,
> > or
> > >> a malfunctioning StatusBackingStore (e.g. caches out of sync with
> > compacted
> > >> topic). This metric will usually be uninteresting, and was only
> included
> > >> for completeness. It could possibly catch a bug.
> > >>
> > >> Gwen,
> > >> I had not considered this option. I agree there is an advantage to
> > having
> > >> more granular data about both connector and worker. The main
> > disadvantage
> > >> would be that it increases the number of metrics by a factor of
> > >> num_workers, but I'd say this is an acceptable tradeoff. Another
> > advantage
> > >> of your suggestion is that the public interfaces for WorkerConnector
> > would
> > >> be unchanged, and the new metrics can be added within the Worker
> class.
> > >>
> > >> I've also updated the KIP to clarify that every task must have exactly
> > >> one non-null task at all times.
> > >>
> > >> On Mon, Jun 17, 2019 at 1:41 PM Guozhang Wang 
> > wrote:
> > >>
> > >>> Hello Cyrus,
> > >>>
> > >>> Thanks for the KIP. I just have one nit question about Connect
> > destroyed
> > >>> tasks: is it an ever-increasing number? If yes, the corresponding
> > metric
> > >>> value would be increasing indefinitely as well. Is that intentional?
> > >>>
> > >>> Otherwise, lgtm.
> > >>>
> > >>>
> > >>> Guozhang
> > >>>
> > >>> On Mon, Jun 17, 2019 at 1:14 PM Gwen Shapira 
> > wrote:
> > >>>
> > >>> > Sorry to join so late, but did we consider a single set of
> task-count
> > >>> > metrics and using tags to scope each data point to a specific
> > >>> > connector and worker (and in the future perhaps also user)?
> > >>> >
> > >>> > It will make analysis of the data easier - someone may want to
> > >>> > breakdown tasks by both worker and connector to detect imbalanced
> > >>> > assignments.
> > >>> >
> > >>> > Are there downsides to this approach?
> > >>> >
> > >>> > And a small nit: it will be good to capture in the KIP what are the
> > >>> > expectations regarding overlap and disjointness of the proposed
> > >>> > metrics. For example, is running+paused+failed = total? Can a task
> be
> > >>> > failed and destroyed and therefore count in 2 of those metrics?
> > >>> >
> > >>> > On Thu, Jun 6, 2019 at 12:29 PM Cyrus Vafadari  >
> > >>> wrote:
> > >>> > >
> > >>> > > Konstantine,
> > >>> > >
> > >>> > > This is a good suggestion. Since the suggestion to add 2
> additional
> > >>> > > statuses analogous to the 3 proposed, it is a very minor change
> of
> > no
> > >>> > > structural consequence to the KIP.
> > >>> > >
> > >>> > > I've updated the KIP to incorporate your suggestion, and any
> voters
> > >>> who
> > >>> > > disagree should definitely respond in the thread.
> > >>> > >
> > >>> > > Cyrus
> > >>> > >
> > >>> > > On Thu, Jun 6, 2019 at 11:16 AM Konstantine Karantasis <
> > >>> > > konstant...@confluent.io> wrote:
> > >>> > >
> > >>> > > > Thanks Cyrus,
> > >>> > > >
> > >>> > > > this is a nice and straightforward addition.
> > >>> > > >
> > >>> > > > I'm +1 too, but I'd like to return with a question here as well
> > >>> > regarding
> > >>> > > > whether the unassigned tasks will be taken into account.
> > >>> > > > Especially after KIP-415 we might start seeing this status for
> > >>> specific
> > >>> > > > periods of time. Therefore, I think it's a meaningful addition.
> > >>> > > > Then there's the `destroyed` status which might be a lot more
> > >>> > transient but
> > >>> > > > we could also include for the sake of completion.
> > >>> > > > Check org.apache.kafka.connect.runtime.AbstractStatus for the
> > list
> > >>> of
> > >>> > all
> > >>> > > > possible statuses.
> > >>> > > >
> > >>> > > > Konstantine
> > >>> > > >
> > >>> > > > On Wed, Jun 5, 2019 at 4:32 PM Randall Hauch  >
> > >>> wrote:
> > >>> > > >
> > >>> > > > > Thanks, Cyrus.
> > >>> > > > >
> > >>> > > > > +1 (binding)
> > >>> > > > >
> > >>> > > > > Randall Hauch
> > >>> > > > >
> > >>> > > > > On Wed, Jun 5, 2019 at 10:36 AM Andrew Schofield <

Jenkins build is back to normal : kafka-trunk-jdk8 #3747

[Apache Jenkins Server]

See 

Re: PR review

[M. Manna]

I have updated it with my comments - @mjsax could you kindly comment
I stopped watching the issue since it sends all updates to all issues to my
inbox :)

Thanks,

On Sat, 22 Jun 2019 at 10:48, M. Manna  wrote:

> Thanks Matthias. Moved to dev DL now.
>
> I saw your comment on the PR regarding imports. I’ll fix those and
> resubmit.
>
> Thanks,
>
> On Sat, 22 Jun 2019 at 01:22, Matthias J. Sax 
> wrote:
>
>> I would recommend to move this discussion to the dev list.
>>
>> -Matthias
>>
>> On 6/20/19 7:42 PM, M. Manna wrote:
>> > It's done. Sorry for the confusion.
>> >
>> > The KIP table however, showed that it's been accepted. But yes it's
>> better
>> > to keep all places consistent.
>> >
>> > Thanks,
>> >
>> > On Fri, 21 Jun 2019 at 03:27, Jeff Widman  wrote:
>> >
>> >> The KIP linked to from the JIRA shows the KIP as still under
>> discussion...
>> >> if it's been voted/approved, then can you please update the wiki page?
>> >>
>> >> On Thu, Jun 20, 2019 at 6:45 PM M. Manna  wrote:
>> >>
>> >>> Hello,
>> >>>
>> >>> We’ve been waiting for this PR for a while.
>> >>>
>> >>> https://github.com/apache/kafka/pull/6771
>> >>>
>> >>> Could this Be reviewed for new release ? This is important for our
>> >> project.
>> >>>
>> >>> Thanks,
>> >>>
>> >>
>> >>
>> >> --
>> >>
>> >> *Jeff Widman*
>> >> jeffwidman.com  | 740-WIDMAN-J (943-6265)
>> >> <><
>> >>
>> >
>>
>>

[jira] [Created] (KAFKA-8588) Leader should stop accepting requests when disconnected from ZK

[jacky (JIRA)]

jacky created KAFKA-8588:


 Summary: Leader should stop accepting requests when disconnected 
from ZK
 Key: KAFKA-8588
 URL: https://issues.apache.org/jira/browse/KAFKA-8588
 Project: Kafka
  Issue Type: Bug
  Components: log
Affects Versions: 2.1.1
Reporter: jacky


When partition leader disconnected from zk, I think it should stop accepting 
requests, because another leader may be elected by kafkaController, if it 
continues to process the request, maybe lead to two leaders in the 
cluster(brain split), the result will depend on the acks and 
min.insync.replicas config, but I think the server should do something base on 
the partition replicas config.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Build failed in Jenkins: kafka-trunk-jdk8 #3746

[Apache Jenkins Server]

See 


Changes:

[github] KAFKA-8545: Remove legacy ZkUtils (#6948)

--
[...truncated 2.51 MB...]
> Task :streams:streams-scala:test

org.apache.kafka.streams.scala.StreamToTableJoinScalaIntegrationTestImplicitSerdes
 > testShouldCountClicksPerRegionWithNamedRepartitionTopic STARTED

org.apache.kafka.streams.scala.StreamToTableJoinScalaIntegrationTestImplicitSerdes
 > testShouldCountClicksPerRegionWithNamedRepartitionTopic PASSED

org.apache.kafka.streams.scala.StreamToTableJoinScalaIntegrationTestImplicitSerdes
 > testShouldCountClicksPerRegionJava STARTED

org.apache.kafka.streams.scala.StreamToTableJoinScalaIntegrationTestImplicitSerdes
 > testShouldCountClicksPerRegionJava PASSED

org.apache.kafka.streams.scala.StreamToTableJoinScalaIntegrationTestImplicitSerdes
 > testShouldCountClicksPerRegion STARTED

org.apache.kafka.streams.scala.StreamToTableJoinScalaIntegrationTestImplicitSerdes
 > testShouldCountClicksPerRegion PASSED

org.apache.kafka.streams.scala.TopologyTest > 
shouldBuildIdenticalTopologyInJavaNScalaJoin STARTED

org.apache.kafka.streams.scala.TopologyTest > 
shouldBuildIdenticalTopologyInJavaNScalaJoin PASSED

org.apache.kafka.streams.scala.TopologyTest > 
shouldBuildIdenticalTopologyInJavaNScalaSimple STARTED

org.apache.kafka.streams.scala.TopologyTest > 
shouldBuildIdenticalTopologyInJavaNScalaSimple PASSED

org.apache.kafka.streams.scala.TopologyTest > 
shouldBuildIdenticalTopologyInJavaNScalaAggregate STARTED

org.apache.kafka.streams.scala.TopologyTest > 
shouldBuildIdenticalTopologyInJavaNScalaAggregate PASSED

org.apache.kafka.streams.scala.TopologyTest > 
shouldBuildIdenticalTopologyInJavaNScalaProperties STARTED

org.apache.kafka.streams.scala.TopologyTest > 
shouldBuildIdenticalTopologyInJavaNScalaProperties PASSED

org.apache.kafka.streams.scala.TopologyTest > 
shouldBuildIdenticalTopologyInJavaNScalaTransform STARTED

org.apache.kafka.streams.scala.TopologyTest > 
shouldBuildIdenticalTopologyInJavaNScalaTransform PASSED

org.apache.kafka.streams.scala.WordCountTest > testShouldCountWordsMaterialized 
STARTED

org.apache.kafka.streams.scala.WordCountTest > testShouldCountWordsMaterialized 
PASSED

org.apache.kafka.streams.scala.WordCountTest > testShouldCountWordsJava STARTED

org.apache.kafka.streams.scala.WordCountTest > testShouldCountWordsJava PASSED

org.apache.kafka.streams.scala.WordCountTest > testShouldCountWords STARTED

org.apache.kafka.streams.scala.WordCountTest > testShouldCountWords PASSED

org.apache.kafka.streams.scala.kstream.MaterializedTest > Create a Materialized 
should create a Materialized with Serdes STARTED

org.apache.kafka.streams.scala.kstream.MaterializedTest > Create a Materialized 
should create a Materialized with Serdes PASSED

org.apache.kafka.streams.scala.kstream.MaterializedTest > Create a Materialize 
with a store name should create a Materialized with Serdes and a store name 
STARTED

org.apache.kafka.streams.scala.kstream.MaterializedTest > Create a Materialize 
with a store name should create a Materialized with Serdes and a store name 
PASSED

org.apache.kafka.streams.scala.kstream.MaterializedTest > Create a Materialize 
with a window store supplier should create a Materialized with Serdes and a 
store supplier STARTED

org.apache.kafka.streams.scala.kstream.MaterializedTest > Create a Materialize 
with a window store supplier should create a Materialized with Serdes and a 
store supplier PASSED

org.apache.kafka.streams.scala.kstream.MaterializedTest > Create a Materialize 
with a key value store supplier should create a Materialized with Serdes and a 
store supplier STARTED

org.apache.kafka.streams.scala.kstream.MaterializedTest > Create a Materialize 
with a key value store supplier should create a Materialized with Serdes and a 
store supplier PASSED

org.apache.kafka.streams.scala.kstream.MaterializedTest > Create a Materialize 
with a session store supplier should create a Materialized with Serdes and a 
store supplier STARTED

org.apache.kafka.streams.scala.kstream.MaterializedTest > Create a Materialize 
with a session store supplier should create a Materialized with Serdes and a 
store supplier PASSED

org.apache.kafka.streams.scala.kstream.KTableTest > filter a KTable should 
filter records satisfying the predicate STARTED

org.apache.kafka.streams.scala.kstream.KTableTest > filter a KTable should 
filter records satisfying the predicate PASSED

org.apache.kafka.streams.scala.kstream.KTableTest > filterNot a KTable should 
filter records not satisfying the predicate STARTED

org.apache.kafka.streams.scala.kstream.KTableTest > filterNot a KTable should 
filter records not satisfying the predicate PASSED

org.apache.kafka.streams.scala.kstream.KTableTest > join 2 KTables should join 
correctly records STARTED

org.apache.kafka.streams.scala.kstream.KTableTest > join 2 KTables should join 
correctly