On 12.07.2019 12:05, Stanislav Kozlovski wrote:
> We will
> not support fetching the progress of any particular reassignment call from
> the server-side. If the client is interested in a particular reassignment's
> progress, it should know what that reassignment consisted of and query
> those
Great KIP,
pure java cruise-control would be a nice thing to have <3
I just want to ask what the opinions are on a way to get the Futures of
the assignment back. Say accross JVms.
Best Jan
On 02.07.2019 19:47, Stanislav Kozlovski wrote:
> Hey there, I need to start a new thread on KIP-455. I
I think this encourages bad descissions.
Lets just have people define repeated fields in thrift,avro,json,
protobuf. Its gonna look nasty if you got your 11th layer of lists.
If you really want to add lists, please do Map aswell in 1 shot
Best Jan
On 06.05.2019 17:59, Daniyar Yeralin (JIRA)
On 10.07.2019 06:25, Adam Bellemare wrote:
> In my experience (obviously empirical) it seems that many people just want
> the ability to join on foreign keys for the sake of handling all the
> relational data in their event streams and extra tombstones don't matter at
> all. This has been my own
On 04.03.2019 19:14, Matthias J. Sax wrote:
> Thanks Adam,
>
> *> Q) Range scans work with caching enabled, too. Thus, there is no
> functional/correctness requirement to disable caching. I cannot
> remember why Jan's proposal added this? It might be an
> implementation detail though (maybe
On 24.01.2019 15:51, Thomas Becker wrote:
> Yes, I think this type of strategy interface would be valuable.
>
Thank you for leaving this here!
On 16.01.2019 14:05, Thomas Becker wrote:
> I'm going to bow out of this discussion since it's been made clear that
> the feature is not targeted at streams. But for the record, my desire is
> to have an alternative to the timestamp based message choosing strategy
> streams currently imposes,
ssors are full, we assign a Processor and block until the connection
> can be added. There is currently no timeout for this. The PR is here:
> https://github.com/apache/kafka/pull/6022
>
> Thanks,
>
> Rajini
>
> On Tue, Jan 15, 2019 at 12:02 PM Jan Filipiak
> wrote:
> The connection queue for Processors will be changed to ArrayBlockingQueue
> with a fixed size of 20. Acceptor will use round-robin allocation to allocate
> each new connection to the next available Processor to which the connection
> can be added without blocking. If a Processor's queue is
I made this for fun :) maybe you like it
https://imgflip.com/i/2r2y15
On 14.01.2019 02:48, n...@afshartous.com wrote:
>
> On reflection, it would be hard to describe the semantics of an API that
> tried to address starvation by temporarily disabling prioritization, and then
> oscillating back and forth.
> Thus I agree that it makes sense not to try and address
On 11.01.2019 21:29, John Roesler wrote:
> Hi Jan,
>
> Thanks for the reply.
>
> It sounds like your larger point is that if we provide a building block
> instead of the whole operation, then it's not too hard for users to
> implement the whole operation, and maybe the building block is
>
On 02.01.2019 23:44, John Roesler wrote:
> However, you seem to have a strong intuition that the scatter/gather
> approach is better.
> Is this informed by your actual applications at work? Perhaps you can
> provide an example
> data set and sequence of operations so we can all do the math and
ed on the offset of
the original message.
>
>
> That's all I have in mind now. Again, great appreciation to Adam to make
> such HUGE progress on this KIP!
>
>
> Guozhang
>
> On Wed, Dec 5, 2018 at 2:40 PM Jan Filipiak
> wrote:
>
>> If they don't
of-order during a final join
>>> instead...
>>>>>>
>>>>>> Let's say we're joining a left table (Integer K: Letter FK, (other
>>>>> data))
>>>>>> to a right table (Letter K: (some data)).
>>>>>>
key for the next page. Then in most cases, it would be a single
> key lookup, but for large fan-out updates, it would be one per (max value
> size)/(avg lhs key size).
>
> This seems more complex, though... Plus, I think there's some extra
> tracking we'd need to do to know when to emit a r
On 07.11.2018 22:24, Adam Bellemare wrote:
> Bumping this thread, as per convention - 1
>
> On Fri, Nov 2, 2018 at 8:22 AM Adam Bellemare
> wrote:
>
>> As expected :) But still, thanks none-the-less!
>>
>> On Fri, Nov 2, 2018 at 3:36 AM Jan Fi
/kafka/pull/5527
>
> See http://mail-archives.apache.org/mod_mbox/kafka-dev/201810.mbox/browser
> for previous discussion thread.
>
> I would also like to give a shout-out to Jan Filipiak who helped me out
> greatly in this project, and who led the initial work into this problem.
> With
org/mod_mbox/kafka-dev/201810.mbox/browser
> for previous discussion thread.
>
> I would also like to give a shout-out to Jan Filipiak who helped me out
> greatly in this project, and who led the initial work into this problem.
> Without Jan's help and insight I do not think this would have been possible
> to get to this point.
>
> Adam
>
t
> an actual problem with the use os pause/resume ? Not sure how to explain
> the situation in a better way..
>
> Zahari
>
>
> On Thu, Oct 18, 2018 at 9:46 AM Zahari Dichev
> wrote:
>
>> Thanks a lot Jan,
>>
>> I will read it.
>>
>> Zaha
On Wed, Oct 17, 2018 at 7:09 AM Jan Filipiak mailto:jan.filip...@trivago.com>> wrote:
This is not a performance optimisation. Its a fundamental design choice.
I never really took a look how streams does exactly once. (its a trap
anyways and you usually can deal with at leas
especially my suggestions ;)
On 18.10.2018 08:30, Jan Filipiak wrote:
Hi Zahari,
would you be willing to scan through the KIP-349 discussion a little?
I think it has suggestions that could be interesting for you
Best Jan
On 16.10.2018 09:29, Zahari Dichev wrote:
Hi there Kafka developers
Hi Zahari,
would you be willing to scan through the KIP-349 discussion a little?
I think it has suggestions that could be interesting for you
Best Jan
On 16.10.2018 09:29, Zahari Dichev wrote:
Hi there Kafka developers,
I am currently trying to find a solution to an issue that has been
pport on a subsequent KIP that
> addresses consumer coordination and rebalance issues. Stay tuned!
>
> Ryanne
>
> On Tue, Oct 16, 2018 at 6:58 AM Jan Filipiak <mailto:jan.filip...@trivago.com>> wrote:
>
> Hi,
>
> Currently MirrorMaker is usually run collocat
no worries,
glad i could clarify
On 16.10.2018 15:14, Andrew Otto wrote:
> O ok apologies. Interesting!
>
> On Tue, Oct 16, 2018 at 9:06 AM Jan Filipiak
> wrote:
>
>> Hi Andrew,
>>
>> thanks for your message, you missed my point.
>>
>> Mirrormake
will also cause (a series) of MirrorMaker consumer
rebalances.
On Tue, Oct 16, 2018 at 7:58 AM Jan Filipiak
wrote:
Hi,
Currently MirrorMaker is usually run collocated with the target cluster.
This is all nice and good. But one big obstacle in this was
always that group coordination
Hi,
Currently MirrorMaker is usually run collocated with the target cluster.
This is all nice and good. But one big obstacle in this was
always that group coordination happened on the source cluster. So when
then network was congested, you sometimes loose group membership and
have to
at a segment-level,
instead of at an individual record level.
On Tue, Sep 25, 2018 at 5:18 PM Jan Filipiak
wrote:
Will that work? I expected it to blow up with ClassCastException or
similar.
You either would have to specify the window you fetch/put or iterate
across all windows the key was found
tate store, not
the ProcessorSupplier.
Thanks,
Adam
On Mon, Sep 24, 2018 at 2:47 PM, Jan Filipiak
wrote:
On 24.09.2018 16:26, Adam Bellemare wrote:
@Guozhang
Thanks for the information. This is indeed something that will be
extremely
useful for this KIP.
@Jan
Thanks for your explanations. That bei
non-windowed KTable-KTable non-key joins for
now. In which case, KIP-258 should help.
Guozhang
On Wed, Sep 12, 2018 at 9:20 PM, Jan Filipiak
wrote:
On 11.09.2018 18:00, Adam Bellemare wrote:
Hi Guozhang
Current highwater mark implementation would grow endlessly based on
primary k
at 10:07 AM, Prajakta Dumbre
mailto:dumbreprajakta...@gmail.com>> wrote:
please remove me from this group
On Tue, Sep 11, 2018 at 1:29 PM Jan Filipiak
mailto:jan.filip...@trivago.com>>
wrote:
> Hi Adam,
>
> give me some time, will make such a
to guess.
Adam
On Sat, Sep 8, 2018 at 8:00 AM, Jan Filipiak
wrote:
Hi James,
nice to see you beeing interested. kafka streams at this point supports
all sorts of joins as long as both streams have the same key.
Adam is currently implementing a join where a KTable and a KTable can have
wo streams? Is there somewhere I can
see the original requirement or proposal?
On Sep 7, 2018, at 8:13 AM, Jan Filipiak wrote:
On 05.09.2018 22:17, Adam Bellemare wrote:
I'm currently testing using a Windowed Store to store the highwater mark.
By all indications this should work fine, with the ca
currentStateAsMap.remove(toModifyKey);
if(currentStateAsMap.isEmpty()){
return null;
}
}
retrun asAggregateType(currentStateAsMap)
}
Thanks,
Adam
On Wed, Sep 5, 2018 at 3:35 PM, Jan Filipiak
wrote:
Thanks Adam for bringing Matthias to speed!
abou
.
Overall, I get the impression that topic prioritization and
MessageChosser are orthogonal (or complementary) to each other.
-Matthias
On 9/6/18 5:24 AM, Jan Filipiak wrote:
On 05.09.2018 17:18, Colin McCabe wrote:
Hi all,
I agree that DISCUSS is more appropriate than VOTE at this point,
since I
-cases that need priorities eventually, but I'm
concerned that we're jumping the gun by trying to implement this before we know
what they are.
best,
Colin
On Wed, Sep 5, 2018, at 01:06, Jan Filipiak wrote:
On 05.09.2018 02:38, n...@afshartous.com wrote:
On Sep 4, 2018, at 4:20 PM, Jan
the input tables as key of the output table. This
makes the keys of the output table unique and we can store both in the
output table:
Result would be ,
Thoughts?
-Matthias
On 9/4/18 1:36 PM, Jan Filipiak wrote:
Just on remark here.
The high-watermark could be disregarded. The decision about the fo
On 05.09.2018 02:38, n...@afshartous.com wrote:
On Sep 4, 2018, at 4:20 PM, Jan Filipiak wrote:
what I meant is litterally this interface:
https://samza.apache.org/learn/documentation/0.7.0/api/javadocs/org/apache/samza/system/chooser/MessageChooser.html
<https://samza.apache.org/le
Just on remark here.
The high-watermark could be disregarded. The decision about the forward
depends on the size of the aggregated map.
Only 1 element long maps would be unpacked and forwarded. 0 element maps
would be published as delete. Any other count
of map entries is in "waiting for
lel across different nodes within the processor API, there
are no ordering guarantees and everything is simple first-come,
first-served(processed). If this is not the case then I am unaware of that
fact.
Thanks
Adam
On Mon, Sep 3, 2018 at 8:38 AM, Jan Filipiak
wrote:
Finished my deeper sc
Hi Nick,
sorry for not beeing so helpfull. I don't quite understand what _this_
would be in your email.
Is this the part in question?
/interface TopicPrioritizer {
List prioritize(List topicPriorities);
}
//
//public void registerTopicPrioritizer(TopicPrioritizer topicPrioritizer);//
/
sible to collide with user-defined headers.
That said, I'd also be fine with just reserving "__" as a header
prefix
and
not worrying about collisions.
Thanks for the KIP,
-John
On Tue, Aug 21, 2018 at 9:48 AM Jan Filipiak <
jan.filip...@trivago.com
wrote:
Still havent completl
On 30.08.2018 15:17, Matthias J. Sax wrote:
Nick,
Would be good to understand the difference between the current approach
and what Jan suggested. If we believe that the current proposal is too
limited in functionality and also hard to extend later on, it might make
sense to work on a more
this in streams.
-Tommy
On Mon, 2018-08-20 at 12:52 +0200, Jan Filipiak wrote:
On 20.08.2018 00:19, Matthias J. Sax wrote:
@Nick: A KIP is only accepted if it got 3 binding votes, ie, votes from
committers. If you close the vote before that, the KIP would not be
accepted. Note that committers need to pay
Still havent completly grabbed it.
sorry will read more
On 17.08.2018 21:23, Jan Filipiak wrote:
Cool stuff.
I made some random remarks. Did not touch the core of the algorithm yet.
Will do Monday 100%
I don't see Interactive Queries :) like that!
On 17.08.2018 20:28, Adam Bellemare
Congrats Dong!
On 20.08.2018 16:35, Attila Sasvári wrote:
Congratulations Dong! Well deserved.
Regards,
Attila
Paolo Patierno ezt írta (időpont: 2018. aug. 20., H
15:09):
Congratulations Dong!
Paolo Patierno
Principal Software Engineer (IoT) @ Red Hat
Microsoft MVP on Azure & IoT
On 20.08.2018 00:19, Matthias J. Sax wrote:
@Nick: A KIP is only accepted if it got 3 binding votes, ie, votes from
committers. If you close the vote before that, the KIP would not be
accepted. Note that committers need to pay attention to a lot of KIPs
and it can take a while until people can
I continue on this thread or do we begin a new one for discussion?
On Thu, Aug 16, 2018 at 1:40 AM, Jan Filipiak
wrote:
even before message headers, the option for me always existed to just wrap
the messages into my own custom envelop.
So I of course thought this through. One sentence in your
---
Back to your questions to KIP-213, I think Jan has summarized it
pretty-well. Note that back then we do not have headers support so we have
to do such "key-widening" approach to ensure ordering.
Guozhang
On Mon, Aug 13, 2018 at 11:39 PM, Jan Filipiak
wrote:
Hi Adam,
uld be helpful.
Thanks
Adam
On Mon, Aug 13, 2018 at 3:34 AM, Jan Filipiak
wrote:
Hi,
Happy to see that you want to make an effort here.
Regarding the ProcessSuppliers I couldn't find a way to not rewrite the
joiners + the merger.
The re-partitioners can be reused in theory. I don't know if r
Sorry for missing the discussion
-1 nonbinding
see
https://samza.apache.org/learn/documentation/0.7.0/api/javadocs/org/apache/samza/system/chooser/MessageChooser.html
Best Jan
On 14.08.2018 03:19, n...@afshartous.com wrote:
Hi All,
Calling for a vote on KIP-349
Hi,
Happy to see that you want to make an effort here.
Regarding the ProcessSuppliers I couldn't find a way to not rewrite the
joiners + the merger.
The re-partitioners can be reused in theory. I don't know if repartition
is optimized in 2.0 now.
I made this
, Apr 4, 2018 at 1:25 AM, Jan Filipiak <jan.filip...@trivago.com>
wrote:
Want to quickly step in here again because it is going places again.
The last part of the discussion is just a pain to read and completely
diverged from what I suggested without making the reasons clear to me.
I don't kn
mer number, the existing consumer can backfill the
existing
data
in
the change log topic to the same change log topic with the
new
partition
number, before the new set of consumers bootstrap state from
the
new
partitions of the change log topic. If this solution works,
then
could
you
consumer can backfill the existing
data
in
the change log topic to the same change log topic with the new
partition
number, before the new set of consumers bootstrap state from the
new
partitions of the change log topic. If this solution works, then
could
you
summarize the advantage of cop
w partition
number, before the new set of consumers bootstrap state from the new
partitions of the change log topic. If this solution works, then could
you
summarize the advantage of copying the data of input topic as compared to
copying the change log topic? For example, does it enable more
estore RPC is a bad idea
and it was only invented to allow for optimisations that are better not
done.Not to say they are premature ;)
I hope it makes it clear
best jan
Thanks,
Jun
On Wed, Mar 21, 2018 at 6:57 AM, Jan Filipiak <jan.filip...@trivago.com>
wrote:
Hi Jun,
I was really seein
to be reshuffled more than once
in different consumer groups during the transition phase.
What do you think?
Thanks,
Jun
On Thu, Mar 15, 2018 at 1:04 AM, Jan Filipiak <jan.filip...@trivago.com>
wrote:
Hi Jun,
thank you for following me on these thoughts. It was important to me to
feel tha
ems more desirable.
I understand your concern about adding complexity in KStreams. But, perhaps
we could iterate on that a bit more to see if it can be simplified.
Jun
On Mon, Mar 12, 2018 at 11:21 PM, Jan Filipiak <jan.filip...@trivago.com>
wrote:
Hi Jun,
I will focus on point 61 as I
w application on? I think this is an overall flaw of the
discussed idea here. Not playing attention to the overall architecture."
Could you explain a bit more when one can't start a new application?
Jun
On Sat, Mar 10, 2018 at 1:40 AM, Jan Filipiak <jan.filip...@trivago.com>
wrote:
o find out how many partitions there were in each
epoch, but
maybe that's not too unreasonable.
Thanks,
Jason
On Mon, Mar 5, 2018 at 4:51 AM, Jan Filipiak <
jan.filip...@trivago.com
wrote:
Hi Dong
thank you very much for your questions.
regarding the time spend copying data across:
d way here. I have nothing
against broker support.
I tried to say that for what I would preffer - copying the data over, at
least for log compacted topics -
I would require more broker support than the KIP currently offers.
Jun
On Tue, Mar 6, 2018 at 10:33 PM, Jan Filipiak <jan.filip...@tri
se then is just a particular implementation which never has
any epoch dependencies. To implement this, we would need some way for the
consumer to find out how many partitions there were in each epoch, but
maybe that's not too unreasonable.
Thanks,
Jason
On Mon, Mar 5, 2018 at 4:51 AM, Jan Fili
and, it will be much more valuable. Do you have ideas on how this can
be done?
Not sure why the current KIP not help people who depend on log compaction.
Could you elaborate more on this point?
Thanks,
Dong
On Wed, Feb 28, 2018 at 10:55 PM, Jan Filipiak<jan.filip...@trivago.com>
wrote:
r/consumer to
subscribe to? It will be helpful for discussion if you can provide more
detail on the interface change for this solution.
Thanks,
Dong
On Mon, Feb 26, 2018 at 12:48 AM, Jan Filipiak <jan.filip...@trivago.com>
wrote:
Hi,
just want to throw my though in. In general the functionality is v
Jan Filipiak created KAFKA-6599:
---
Summary: KTable KTable join semantics violated when caching enabled
Key: KAFKA-6599
URL: https://issues.apache.org/jira/browse/KAFKA-6599
Project: Kafka
Issue
Hi,
just want to throw my though in. In general the functionality is very
usefull, we should though not try to find the architecture to hard while
implementing.
The manual steps would be to
create a new topic
the mirrormake from the new old topic to the new topic
wait for mirror making to
on all the
points
Best Jan
On 27.10.2017 06:38, Jan Filipiak wrote:
Hello everyone,
this is the new discussion thread after the ID-clash.
Best
Jan
__
Hello Kafka-users,
I want to continue with the development of KAFKA-3705, which allows
the Streams DSL to perform KTableKTable-Joins
Sorry for coming back at this so late.
On 11.12.2017 07:12, Colin McCabe wrote:
On Sun, Dec 10, 2017, at 22:10, Colin McCabe wrote:
On Fri, Dec 8, 2017, at 01:16, Jan Filipiak wrote:
Hi,
sorry for the late reply, busy times :-/
I would ask you one thing maybe. Since the timeout
argument
page itself, about the "back and forth
mapper" section: the parameter names "customCombinedKey" and "combinedKey"
seems a bit hard to understand to normal users; should we consider renaming
them to something more understandable? For example, "outputKeyCombiner&quo
Hi, I updated the KIP
I would be open for this:
We mark the "less intrusive" and the "back and forth mapper" approach as
rejected alternatives.
and implement the two remaining methods.
any thoughts?
Best jan
On 07.12.2017 12:58, Jan Filipiak wrote:
On 05.12.2017 00
On 08.12.2017 10:43, Ismael Juma wrote:
One correction below.
On Fri, Dec 8, 2017 at 11:16 AM, Jan Filipiak <jan.filip...@trivago.com>
wrote:
We only check max.message.bytes to late to guard against consumer stalling.
we dont have a notion of max.networkpacket.size before we al
pect the client to be away for this long,
and come back and continue"?
also clarified some stuff inline
Best Jan
On 05.12.2017 23:14, Colin McCabe wrote:
On Tue, Dec 5, 2017, at 13:13, Jan Filipiak wrote:
Hi Colin
Addressing the topic of how to manage slots from the other thread.
With
but I don't see too much
value in doing this compared to the storage overhead this implies).
WDYT?
-Matthias
On 11/29/17 4:14 AM, Jan Filipiak wrote:
Hi,
thank you for the summary and thanks for acknowledging that I do have a
point here.
I don't like the second Idea at all. Hence I started
think in line 5 (input A, with key A2 arrives, the columns "state B
materialized" and "state B other task" should not be empty but the same
as in line 4?
Will double check tonight. totally plausible i messed this up!
best Jan
-Matthias
On 11/25/17 8:56 PM, Jan Filipiak wrot
, 2017, at 02:27, Jan Filipiak wrote:
On 03.12.2017 21:55, Colin McCabe wrote:
On Sat, Dec 2, 2017, at 23:21, Becket Qin wrote:
Thanks for the explanation, Colin. A few more questions.
The session epoch is not complex. It's just a number which increments
on each incremental fetch. The session
t 12:13 PM, Colin McCabe<cmcc...@apache.org>
wrote:
I updated the KIP with the ideas we've been discussing.
best,
Colin
On Tue, Nov 28, 2017, at 08:38, Colin McCabe wrote:
On Mon, Nov 27, 2017, at 22:30, Jan Filipiak wrote:
Hi Colin, thank you for this KIP, it can become a really
usef
On 02.12.2017 23:34, Colin McCabe wrote:
On Thu, Nov 30, 2017, at 23:29, Jan Filipiak wrote:
Hi,
this discussion is going a little bit far from what I intended this
thread for.
I can see all of this beeing related.
To let you guys know what I am currently thinking is the following:
I do
BTW:
the shuffle problem would exist in all our solutions. An empty fetch
request had the same issue about
what order to serve the topic and partitions. So my suggestion is not
introducing this problem.
Best Jan
On 01.12.2017 08:29, Jan Filipiak wrote:
Hi,
this discussion is going
to the server. Not sure if this
will introduce some complexity to the broker. Intuitively it seems fine.
The logic would basically be similar to the draining logic in the
RecordAccumulator of the producer.
Thanks,
Jiangjie (Becket) Qin
On Thu, Nov 30, 2017 at 11:29 PM, Jan Filipiak <jan.fi
,
Colin
On Tue, Nov 28, 2017, at 08:38, Colin McCabe wrote:
On Mon, Nov 27, 2017, at 22:30, Jan Filipiak wrote:
Hi Colin, thank you for this KIP, it can become a really useful
thing.
I just scanned through the discussion so far and wanted to start a
thread to make as decision about keeping the
c
to get this themselves (embed such information
in the value payload, for example).
If people do not like the second idea, I'd suggest we hold on pursuing the
first direction since to me its beneficial scope is too limited compared to
its cost.
Guozhang
On Fri, Nov 24, 2017 at 1:39 AM, Jan Filipiak &l
Hi Colin, thank you for this KIP, it can become a really useful thing.
I just scanned through the discussion so far and wanted to start a
thread to make as decision about keeping the
cache with the Connection / Session or having some sort of UUID indexed
global Map.
Sorry if that has been
l topic used for compaction, and what would
be used as the partition-key.
Guozhang
On Sat, Nov 18, 2017 at 2:30 PM, Jan Filipiak <jan.filip...@trivago.com>
wrote:
-> it think the relationships between the different used types, K0,K1,KO
should be explains explicitly (all information is
e table. But how is this
related to KIP-159?
Btw: with KIP-182, I am wondering if this would not be possible, by
putting a custom dummy store into the table and materialize the filter
result afterwards? It's not a nice way to do, but seems to be possible.
-Matthias
On 11/23/17 4:56 AM, Ja
ord context() is for
change.newValue". Are you referring to `KTableFilter#process()`? If yes
could you point to me which LOC are you concerning about?
Guozhang
On Mon, Nov 20, 2017 at 9:29 PM, Jan Filipiak <jan.filip...@trivago.com>
wrote:
a remark of mine that got m
a remark of mine that got missed during migration:
There is this problem that even though we have source.table.filter.join
the state-fullness happens at the table step not a the join step. In a
filter
we still going to present change.oldValue to the filter even though the
record context() is
idely escalates the context
of the KIP
Just wanted to lay the ground for discussions so we are all on the same
page before chatting more.
Guozhang
On Sat, Nov 18, 2017 at 3:10 AM, Jan Filipiak <jan.filip...@trivago.com>
wrote:
Hi,
not an issue at all. IMO
the approach that is on
figure it out)
Last but not least:
But noone is really interested.
Don't understand this statement...
-Matthias
On 11/16/17 9:05 AM, Jan Filipiak wrote:
We are running this perfectly fine. for us the smaller table changes
rather infrequent say. only a few times per day. The performance of the
fl
nk the relationships between the different used types, K0,K1,KO
should be explains explicitly (all information is there implicitly, but
one need to think hard to figure it out)
Last but not least:
But noone is really interested.
Don't understand this statement...
-Matthias
On 11/16/17 9:05 AM, Jan Fil
out)
will add this
Last but not least:
But noone is really interested.
This was the first time some took the effort to address the most
pressuring issue moving this forward.
I counted this as not beeing interested before.
Don't understand this statement...
-Matthias
On 11/16/17 9:05 A
completely.
Cheers,
Jeyhun
On Sat 18. Nov 2017 at 07:49, Jan Filipiak <jan.filip...@trivago.com> wrote:
Yes, the mail said only join so I wanted to clarify.
On 17.11.2017 19:05, Matthias J. Sax wrote:
Yes. But I think an aggregation is an many-to-one operation, too.
For the stripping of
in the resulted records and claim "we cannot infer its traced
context anymore"?
Guozhang
On Thu, Nov 16, 2017 at 1:03 PM, Matthias J. Sax <matth...@confluent.io>
wrote:
Any thoughts about my latest proposal?
-Matthias
On 11/10/17 10:02 PM, Jan Filipiak wrote:
Hi,
i think th
v 16, 2017 at 1:03 PM, Matthias J. Sax <matth...@confluent.io>
wrote:
Any thoughts about my latest proposal?
-Matthias
On 11/10/17 10:02 PM, Jan Filipiak wrote:
Hi,
i think this is the better way. Naming is always tricky Source is kinda
taken
I had TopicBackedK[Source|Table] in mind
but
.
On 16.11.2017 18:02, Trevor Huey wrote:
Ah, I think I see the problem now. Thanks for the explanation. That is
tricky. As you said, it seems the easiest solution would just be to
flush the cache. I wonder how big of a performance hit that'd be...
On Thu, Nov 16, 2017 at 9:07 AM Jan Filipiak
free to continue the discussion w/o the table. I want
to finish the table during next week.
Best Jan thank you for your interest!
_ Jira Quote __
Jan Filipiak
<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jfilipiak>
Please bear with me while I try to get caught u
that we should enlarge the score
of through() (add more overloads) instead of introducing a separate set
of
overloads to other methods.
I will update the KIP soon based on the discussion and inform.
Cheers,
Jeyhun
On Mon, Nov 6, 2017 at 9:18 PM Jan Filipiak <jan.filip...@trivago.com>
On 11/9/17 9:13 PM, Jan Filipiak wrote:
Okay,
looks like it would _at least work_ for Cached KTableSources .
But we make it harder to the user to make mistakes by putting
features into places where they don't make sense and don't
help anyone.
I once again think that my suggestion is easier
to double check on such stages to make sure we are not introducing any
regressions.
Guozhang
On Mon, Nov 6, 2017 at 8:54 PM, Jan Filipiak <jan.filip...@trivago.com>
wrote:
I Aggree completely.
Exposing this information in a place where it has no _natural_ belonging
might really be
On 07.11.2017 12:59, Jan Filipiak wrote:
On 07.11.2017 11:20, Matthias J. Sax wrote:
About implementation if we do the KIP as proposed: I agree with Guozhang
that we would need to use the currently processed record's metadata in
the context. This does leak some implementation details, but I
1 - 100 of 137 matches
Mail list logo
