are
>> interested to drive this further. So we will just "reassign" it to them.
>>
>> Thanks for letting us know.
>>
>>
>> -Matthias
>>
>> On 6/20/18 2:51 PM, Jeyhun Karimov wrote:
>> > Hi Matthias, all,
>> >
>> >
hrough()` and `to()`, can you add
> >> the different behavior using different overloads? It's not clear from
> >> the KIP what the semantics are.
> >>
> >>
> >> -Matthias
> >>
> >> On 11/17/17 3:27 PM, Jeyhun Karimov wrote:
> >>>
: I never ran a topology with
> caching
> >>>>>>>> but I
> >>>>>>>> am not even 100% sure what the record Context means behind
> >>>>>>>> a materialized KTable with Caching? Topic and Partition are
> pr
ponsible for managing them, including the topic name. For this KIP's
> >> purpose, though, users would not care about the topic name. I.e. as a
> >> user
> >> I still want to make it be an internal topic so that I do not need to
> >> worry
> >> a
ep it that way until #6. In addition, the
> >>>> RecordContext
> >>>> fields (topic, offset, etc) are really orthogonal to the key-value
> >>>> payloads
> >>>> themselves, so I think separating them into this object is a
> >>>>
yhun, thanks, looks good.
> >> Do we need to remove the line that says:
> >>
> >>- on-demand commit() feature
> >>
> >> Cheers,
> >> Damian
> >>
> >> On Tue, 31 Oct 2017 at 23:07 Jeyhun Karimov
> wrote:
> >>
&g
't want to manage topic manually, thus, it's still an
> >> internal topic and Streams create the topic name automatically as for
> >> all other internal topics. However, users gets some more control about
> >> topic parameters like number of partitions (w
wrote:
> >> -1 non binding
> >>
> >> I don't get the motivation.
> >> In 80% of my DSL processors there is no such thing as a reasonable
> >> RecordContext.
> >> After a join the record I am processing belongs to at least 2 topics.
> &g
the back ground
> > and picky back all to `Produced`.
> >
> >
> > -Matthias
> >
> > On 11/4/17 4:16 PM, Ted Yu wrote:
> > > API is given without much javadoc on the role / meaning of method
> > > parameters.
> > >
> > > Can y
Dear community,
I would like to initiate discussion on KIP-221 [1] based on issue [2].
Please feel free to comment.
[1]
https://cwiki.apache.org/confluence/display/KAFKA/KIP-221%3A+Repartition+Topic+Hints+in+Streams
[2] https://issues.apache.org/jira/browse/KAFKA-6037
Cheers,
Jeyhun
Dear community,
It seems the discussion for KIP-159 [1] converged finally. I would like to
initiate voting for the particular KIP.
[1]
https://cwiki.apache.org/confluence/display/KAFKA/KIP-159%3A+Introducing+Rich+functions+to+Streams
Cheers,
Jeyhun
't agree that
>
> > but also we need a commit() method
>
> I would just not provide `commit()` at DSL level and close the
> corresponding Jira as "not a problem" or similar.
>
>
> -Matthias
>
> On 10/27/17 3:42 PM, Jeyhun Karimov wrote:
> > Hi Matth
>
> To me, this does not seem to be a sound API design if we follow this path.
>
>
> -Matthias
>
>
>
> On 10/26/17 10:41 PM, Jeyhun Karimov wrote:
> > Hi,
> >
> > Thanks for your suggestions.
> >
> > I have some comments, to make sure that th
17 at 1:40 PM, Matthias J. Sax
> wrote:
>
> > Fair point. This is a long discussion and I totally forgot that we
> > discussed this.
> >
> > Seems I changed my opinion about including KAFKA-3907...
> >
> > Happy to hear what others think.
> >
> >
hould fix KAFKA-3907 at all.
> Manual commits are something DSL users should not worry about -- and if
> one really needs this, an advanced user can still insert a dummy
> `transform` to request a commit from there.
>
> -Matthias
>
>
> On 10/18/17 5:39 AM, Jeyhun Karimov wrote
u call that function, it means we would commit the state
> of the whole task up to this processed record, not only that single record
> itself.
>
>
> Guozhang
>
> On Mon, Oct 16, 2017 at 9:19 AM, Jeyhun Karimov
> wrote:
>
> > Hi,
> >
> > Thanks for the
want to move `commit()` from ProcessorContext to
> RecordContext? Conceptually I think it would better staying in the
> ProcessorContext. Do you find this not doable in the internal
> implementations?
>
>
> Guozhang
>
>
>
> On Fri, Sep 22, 2017 at 1:09 PM, Ted Yu
tion("commit() is not supported in
> this context");
>
> Is the exception going to be replaced with real code in the PR ?
>
> Cheers
>
>
> On Fri, Sep 22, 2017 at 9:28 AM, Jeyhun Karimov
> wrote:
>
> > Dear community,
> >
> > I updated the rela
Dear community,
I updated the related KIP [1]. Please feel free to comment.
Cheers,
Jeyhun
[1]
https://cwiki.apache.org/confluence/display/KAFKA/KIP-159%3A+Introducing+Rich+functions+to+Streams
On Fri, Sep 22, 2017 at 12:20 AM Jeyhun Karimov
wrote:
> Hi Damian,
>
> Thanks for t
21 Sep 2017 at 15:23 Jeyhun Karimov wrote:
>
> > Hi all,
> >
> > Thanks a lot for your comments. For the single interface (RichXXX and
> > XXXWithKey) solution, I have already submitted a PR but probably it is
> > outdated (when the KIP first proposed), I need to
gt; > On Thu, Sep 14, 2017 at 10:37 PM, Ted Yu wrote:
> >
> > > +1
> > >
> > > One interface is cleaner.
> > >
> > > On Thu, Sep 14, 2017 at 7:26 AM, Bill Bejeck
> wrote:
> > >
> > > > +1 for me on collapsing the Rich and
Rich and ValueWithKey etc
> interfaces into 1 interface that has all of the arguments. I think we then
> only need to add one additional overload for each operator?
>
> Thanks,
> Damian
>
> On Wed, 13 Sep 2017 at 10:59 Jeyhun Karimov wrote:
>
> > Dear all,
> >
> &g
lease feel free to comment on this.
[1]
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=73637757
Cheers,
Jeyhun
On Fri, Jul 21, 2017 at 2:00 AM Jeyhun Karimov wrote:
> Hi Matthias, Damian, all,
>
> Thanks for your comments and sorry for super-late update.
>
> Sur
(non-binding) Thanks.
> > > >
> > > > Eno
> > > > > On 6 Jul 2017, at 21:49, Gwen Shapira wrote:
> > > > >
> > > > > +1
> > > > >
> > > > > On Wed, Jul 5, 2017 at 9:25 AM Matthias J. Sax <
> > matth...@confl
wrote:
> I would not block this KIP with regard to DSL refactoring. IMHO, we can
> just finish this one and the DSL refactoring will help later on to
> reduce the number of overloads.
>
> -Matthias
>
> On 7/7/17 5:28 AM, Jeyhun Karimov wrote:
> > I am following the related
rnalProcessorContext to ProcessorContext.
> > >
> > > In the KIP you have an example showing:
> > > richMapper.init((RecordContext) processorContext);
> > > But the interface is:
> > > public interface RichValueMapper {
> > > VR apply(final V value, fi
g:
> richMapper.init((RecordContext) processorContext);
> But the interface is:
> public interface RichValueMapper {
> VR apply(final V value, final RecordContext recordContext);
> }
> i.e., there is no init(...), besides as above this wouldn't make sense.
>
> Thanks,
Context. This will
> > break compatibility.
> >
> > I think, we should just have two independent interfaces. Our own
> > ProcessorContextImpl class would implement both. This allows us to cast
> > it to `RecordContext` and thus limit the visible scope.
> >
> >
&
rade guidance.
> >>
> >> Regarding the scope I'm still trying to solicit opinions regarding
> >> ReducerWithKey and InitializerWithKey; to me they are not necessarily
> to be
> >> included.
> >>
> >>
> >> Guozhang
> >>
> >>
> &
) or similar? So that users don't have to read the docs
> to know it isn't the creation timestamp for instance.
> Cheers,
> Michał
>
>
> On 04/06/17 01:24, Jeyhun Karimov wrote:
>
> Hi Matthias,
>
> Thanks for comments.
>
> - why do you only cons
Dear all,
I would like to start the vote on KIP-149 [1].
Cheers,
Jeyhun
[1]
https://cwiki.apache.org/confluence/display/KAFKA/KIP-149%3A+Enabling+key+access+in+ValueTransformer%2C+ValueMapper%2C+and+ValueJoiner
--
-Cheers
Jeyhun
address this issue as well or
continue as it is?
Cheers,
Jeyhun
On Wed, Jun 14, 2017 at 11:29 PM Guozhang Wang wrote:
> LGTM. Thanks!
>
>
> Guozhang
>
> On Tue, Jun 13, 2017 at 2:20 PM, Jeyhun Karimov
> wrote:
>
> > Thanks for the comment Matthias. After all
Hi,
With kafka you can increase overall throughput by increasing the number of
nodes in a cluster.
I had a similar issue, where we needed to ingest vast amounts of data to
streaming system.
In our case, kafka was a bottleneck, because of disk I/O. To solve it, we
implemented (simple) distributed
[
https://issues.apache.org/jira/browse/KAFKA-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049834#comment-16049834
]
Jeyhun Karimov commented on KAFKA-4829:
---
[~guozhang] I would suggest similar m
[
https://issues.apache.org/jira/browse/KAFKA-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeyhun Karimov reassigned KAFKA-3907:
-
Assignee: Jeyhun Karimov
> Better support for user-specific committing in the Stre
think changing the interface to extend from a new interface is not
> binary
> > compatible though source compatible, i.e. users still need to recompile
> > their code though no need to make code changes. We may need to mention
> that
> > in the upgrade path if we want to keep i
, Guozhang Wang wrote:
> > Thanks for the comprehensive summary!
> >
> > Personally I'd prefer the option of passing RecordContext as an
> additional
> > parameter into he overloaded function. But I'm also open to other
> arguments
> > if there are sth. that I have
[
https://issues.apache.org/jira/browse/KAFKA-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16046497#comment-16046497
]
Jeyhun Karimov edited comment on KAFKA-3826 at 6/12/17 12:3
[
https://issues.apache.org/jira/browse/KAFKA-3826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16046497#comment-16046497
]
Jeyhun Karimov commented on KAFKA-3826:
---
[~guozhang] I think KAFKA-4829 also ca
[
https://issues.apache.org/jira/browse/KAFKA-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeyhun Karimov reassigned KAFKA-4653:
-
Assignee: Jeyhun Karimov
> Improve test coverage of RocksDBSt
[
https://issues.apache.org/jira/browse/KAFKA-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeyhun Karimov reassigned KAFKA-4658:
-
Assignee: Jeyhun Karimov
> Improve test coverage InMemoryKeyValueLoggedSt
[
https://issues.apache.org/jira/browse/KAFKA-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeyhun Karimov reassigned KAFKA-4656:
-
Assignee: Jeyhun Karimov
> Improve test coverage of CompositeReadOnlyKeyValueSt
[
https://issues.apache.org/jira/browse/KAFKA-4659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeyhun Karimov reassigned KAFKA-4659:
-
Assignee: Jeyhun Karimov
> Improve test coverage of CachingKeyValueSt
[
https://issues.apache.org/jira/browse/KAFKA-4655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeyhun Karimov reassigned KAFKA-4655:
-
Assignee: Jeyhun Karimov
> Improve test coverage of CompositeReadOnlySessionSt
[
https://issues.apache.org/jira/browse/KAFKA-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeyhun Karimov reassigned KAFKA-4661:
-
Assignee: Jeyhun Karimov
> Improve test coverage UsePreviousTimeOnInvalidTimest
I agree with Matthias's comment. Constructing RecordContext with more
metadata seems more feasible for me.
Cheers,
Jeyun
On Mon, Jun 5, 2017 at 7:47 AM Matthias J. Sax
wrote:
> Not with the scope of the current discussion.
>
> So far, we discuss to add `RecordContext`, but the context object we
but for joins and aggregations.
> >>
> >>
> >> On the other hand, as I mentioned in an older email, I am personally
> >> fine to break the pure functional interface, and add
> >>
> >> - interface WithRecordContext with method `open(RecordContext)`
;> they do, we can support them easily as the above implementations;
> >>>
> >>> Similarly for "ReducerWithKey", it can be implemented as `Aggregator >> V,
> >>> V>`, and people who needs key access can just use `aggregate` directly.
> >&g
ntext not be sufficient?
> - for backward compatibility, we will also need a new interface and
> cannot just extend the existing one
>
>
>
> -Matthias
>
> On 5/29/17 4:55 PM, Jeyhun Karimov wrote:
> > Dear community,
> >
> > I want to share KIP-165 [1] based
[
https://issues.apache.org/jira/browse/KAFKA-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035688#comment-16035688
]
Jeyhun Karimov commented on KAFKA-4325:
---
[~mjsax], would this jira requre
.
Cheers,
Jeyhun
On Fri, Jun 2, 2017 at 2:27 AM Guozhang Wang wrote:
> Does this KIP subsume this ticket as well?
> https://issues.apache.org/jira/browse/KAFKA-4125
>
> On Sat, May 20, 2017 at 9:05 AM, Jeyhun Karimov
> wrote:
>
> > Dear community,
> >
> > As we disc
Dear community,
I want to share KIP-165 [1] based on issue KAFKA-4304 [2].
I would like to get your comments.
[1]
https://cwiki.apache.org/confluence/display/KAFKA/KIP-165%3A+Extend+Interactive+Queries+for+return+latest+update+timestamp+per+key
[2] https://issues.apache.org/jira/browse/KAFKA-4304
[
https://issues.apache.org/jira/browse/KAFKA-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027964#comment-16027964
]
Jeyhun Karimov edited comment on KAFKA-4304 at 5/28/17 10:3
[
https://issues.apache.org/jira/browse/KAFKA-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeyhun Karimov reassigned KAFKA-4304:
-
Assignee: Jeyhun Karimov
> Extend Interactive Queries for return latest update timest
[
https://issues.apache.org/jira/browse/KAFKA-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027964#comment-16027964
]
Jeyhun Karimov edited comment on KAFKA-4304 at 5/28/17 10:2
[
https://issues.apache.org/jira/browse/KAFKA-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027964#comment-16027964
]
Jeyhun Karimov commented on KAFKA-4304:
---
>From the user perspective, on
[
https://issues.apache.org/jira/browse/KAFKA-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027958#comment-16027958
]
Jeyhun Karimov commented on KAFKA-4304:
---
[~mjsax] I completely forgot this i
if we duplicate
> functionality.
>
> For this reason, it seems to be better to got with the
> `#valueMapper(ValueMapper mapper, RecordContext context)` approach.
>
> WDYT?
>
>
>
> -Matthias
>
> On 5/27/17 11:00 AM, Jeyhun Karimov wrote:
> > Hi,
> >
> > Thank
this for ValueTransformer (and similar).
>
> Btw: This reminds me about KIP-159: with regard to the RichFunction we
> might need a supplier pattern, too. (I'll comment on the other thread,
> too.)
>
>
> -Matthias
>
> On 5/28/17 5:45 AM, Jeyhun Karimov wrote:
lso allows to register
> punctuations. Both those features will not be available via withKey()
> interfaces.
>
> -Matthias
>
>
> On 5/27/17 1:25 PM, Jeyhun Karimov wrote:
> > Hi Matthias,
> >
> > Thanks for your comments.
> >
> > I tested the deep copy approa
thoughts?
>
>
> -Matthias
>
>
> On 5/24/17 3:47 PM, Matthias J. Sax wrote:
> > Jeyhun,
> >
> > I was just wondering if you did look into the key-deep-copy idea we
> > discussed. I am curious to see what the impact might be.
> >
> >
> >
t;init()". This might even
> allow to use Lambdas and we could keep the name RichFunction as we
> preserve the nature of being a function.
>
>
> -Matthias
>
> On 5/24/17 12:13 PM, Jeyhun Karimov wrote:
> > Hi Michal,
> >
> > Thanks for your comments. I s
ing that requires
>> initialisation and closing (which implies holding state) as being a
>> function. Sounds more like the Processor/Transformer kind of thing
>> semantically, rather than a function.
>>
>> The KIP says there are multiple use-cases for this but doesn'
gt; but maybe I'm just lacking in imagination, so I'm asking all this to better
> understand the rationale for init() and close().
>
> Thanks,
> Michał
>
> On 20/05/17 17:05, Jeyhun Karimov wrote:
>
> Dear community,
>
> As we discussed in KIP-149 [DISCUSS] thre
Dear community,
As we discussed in KIP-149 [DISCUSS] thread [1], I would like to initiate
KIP for rich functions (interfaces) [2].
I would like to get your comments.
[1]
http://search-hadoop.com/m/Kafka/uyzND1PMjdk2CslH12?subj=Re+DISCUSS+KIP+149+Enabling+key+access+in+ValueTransformer+ValueMappe
gt; > Thanks for your work and for driving this, Jeyhun! :-)
> >
> > -Michael
> >
> >
> > On Tue, Apr 25, 2017 at 11:11 PM, Jeyhun Karimov
> > wrote:
> >
> > > Dear all,
> > >
> > > I am closing this vote now. The KIP got acce
llel) -- we
> don't want to slow you down :) But it make the discussion and code
> review easier, if we separate both IMHO.
>
>
> -Matthias
>
>
> On 5/19/17 2:25 AM, Jeyhun Karimov wrote:
> > Hi Damian,
> >
> > Thanks for your comments. I think providing t
[
https://issues.apache.org/jira/browse/KAFKA-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16017575#comment-16017575
]
Jeyhun Karimov commented on KAFKA-4785:
---
[~mjsax] Thanks for reminding. I am o
7;t like the abstract classes: RichValueMapper, RichValueJoiner,
> RichInitializer etc. Why can't they not just be interfaces? Generally we
> should provide users with Intefaces to code against, not classes.
>
> Thanks,
> Damian
>
> On Fri, 19 May 2017 at 00:50 Jeyhun Karim
() -- if you don't want those, you would implement a
> >> different interface (ie, ValueMapperWithKey)
> >>
> >> As an alternative, we could argue, that it is sufficient to support
> >> Lambdas for the "plain" API only, but not for any "extended API". For
&
erloaded
> methods to get Lambdas for `withKey` interfaces too much because we have
> already so many overlaods. On the other hand, I do see value in
> supporting Lambdas for `withKey`.
>
> Depending on what we want to support, it might make sense to
> include/exclude RichFunctions from
#x27;t have overlaods added for
> > >> them. Why? (Even if I still hope that we don't need to add any new
> > >> overloads)
> > >>
> > >> - Why do we need `AbstractRichFunction`?
> > >>
> > >> - What about interfaces In
> And yes, we need to do one check -- but this happens when building the
> topology. At runtime (I mean after KafkaStream#start() we don't need any
> check as we will always use `ValueMapperWithKey`)
>
>
> -Matthias
>
>
> On 5/9/17 2:55 AM, Jeyhun Karimov wrote:
> &g
One correction:
and in runtime (inside processor) we still have to check it is ValueMapper
> or ValueMapperWithKey before wrapping it into the rich function.
this will be in compile time in API level.
Cheers,
Jeyhun
On Tue, May 9, 2017 at 11:55 AM Jeyhun Karimov wrote:
> Hi,
>
> > This approach should not effect lambdas (or do I miss something?) and
> > might be cleaner, as we could have one more top level interface
> > `RichFunction` with methods `init()` and `close()` and also interfaces
> > for `RichValueMapper` etc. (thus, no abstract classes requir
ike that would require subclassing RichFunction? That's a
> bit of an inconvenience IMO.
>
> Cheers,
>
> Michal
>
> On 07/05/17 01:29, Jeyhun Karimov wrote:
>
> Hi,
>
> Thanks for comments. I extended PR and KIP to include rich functions. I
> will still have to
. Maybe it's worth for you to apply
> > the deep copy strategy and run the test. It's very basic performance
> > test only, but might give some insight. If you want to do this, look
> > into folder "tests" for general test setup, and into
> > "tests/k
would allow users to access record metadata (like timestamp, offset,
> > partition etc) within DSL. This would be a similar concept. Thus, I am
> > wondering, if it would make sense to enlarge the scope of this KIP by
> > that? WDYT?
> >
> >
> >
> > -Matthi
utable object (eg. byte[]),
> it can still be mutated. (eg. key[0] = 0). But I'm not really sure there's
> much that can be done about that.
>
> Mathieu
>
>
> On Mon, May 1, 2017 at 5:39 PM, Jeyhun Karimov
> wrote:
>
> > Thanks for comments.
> >
> &
nt to add my voice that, I too, have wished for access to the
> > record key during a mapValues or similar operation.
> >
> > On the other hand, the number of compile failures that would need to be
> > fixed from this change is unfortunate. :-) But at least it would all be
>
Dear community,
I want to share KIP-149 [1] based on issues KAFKA-4218 [2], KAFKA-4726 [3],
KAFKA-3745 [4]. The related PR can be found at [5].
I would like to get your comments.
[1]
https://cwiki.apache.org/confluence/display/KAFKA/KIP-149%3A+Enabling+key+access+in+ValueTransformer%2C+ValueMappe
[
https://issues.apache.org/jira/browse/KAFKA-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989838#comment-15989838
]
Jeyhun Karimov edited comment on KAFKA-4785 at 4/29/17 6:0
[
https://issues.apache.org/jira/browse/KAFKA-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989988#comment-15989988
]
Jeyhun Karimov commented on KAFKA-3745:
---
[~sree2k] is there an update on i
[
https://issues.apache.org/jira/browse/KAFKA-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989838#comment-15989838
]
Jeyhun Karimov commented on KAFKA-4785:
---
[~mjsax], as it is discussed in KAFKA-
[
https://issues.apache.org/jira/browse/KAFKA-4218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989837#comment-15989837
]
Jeyhun Karimov commented on KAFKA-4218:
---
[~mjsax], thanks for your comment
[
https://issues.apache.org/jira/browse/KAFKA-4218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeyhun Karimov reassigned KAFKA-4218:
-
Assignee: Jeyhun Karimov
> Enable access to key in ValueTransfor
[
https://issues.apache.org/jira/browse/KAFKA-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989557#comment-15989557
]
Jeyhun Karimov commented on KAFKA-4785:
---
[~mjsax] Do you think KAFKA-414
[
https://issues.apache.org/jira/browse/KAFKA-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeyhun Karimov reassigned KAFKA-4785:
-
Assignee: Jeyhun Karimov
> Records from internal repartitioning topics should always
17 at 5:42 PM Eno Thereska wrote:
> Hi Jeyhun,
>
> You make a good observation and I think a discussion/contribution around
> this would be very much appreciated by the community. Are you thinking of a
> KIP perhaps?
>
> Eno
>
> > On 28 Apr 2017, at 16:13, Jey
Hi community,
I have a question regarding with streams library.
Currently, in kafka-streams we run the whole topology in one instance and
there can be several topologies or tasks in a single node. However, there
can be use-cases with very complex topologies with costly operators. So,
when we wan
-28 at 08:59 +0000, Jeyhun Karimov wrote:
> > Dear community,
> >
> > I'd like to start the vote for KIP-123:
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=6871
> > 4788
> >
> >
> > Cheers,
> > Jeyhun
> --
>
>
[
https://issues.apache.org/jira/browse/KAFKA-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15983515#comment-15983515
]
Jeyhun Karimov commented on KAFKA-4144:
---
[~mjsax] I am sorry, I didn't
[
https://issues.apache.org/jira/browse/KAFKA-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeyhun Karimov updated KAFKA-4144:
--
Status: Reopened (was: Closed)
> Allow per stream/table timestamp extrac
[
https://issues.apache.org/jira/browse/KAFKA-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeyhun Karimov closed KAFKA-4144.
-
> Allow per stream/table timestamp extrac
[
https://issues.apache.org/jira/browse/KAFKA-4144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeyhun Karimov resolved KAFKA-4144.
---
Resolution: Fixed
Reviewer: Matthias J. Sax
> Allow per stream/table timest
; Can you also update the KIP accordingly. It must contain all changes to
> > public API. Thus, list all parameters that get deprecated and newly
> > added. And add a sentence about backward compatibility.
> >
> >
> > -Matthias
> >
> > On 3/23/17 3:16 AM, J
omments mentioned above.
>
>
> Guozhang
>
>
> On Mon, Mar 6, 2017 at 3:14 PM, Jeyhun Karimov
> wrote:
>
> > Sorry I was late. I will update javadocs in related methods to emphasize
> > that TimestampExtractor is stateless.
> >
> > Cheers,
> > Je
ll
> > wrote:
> > >
> > >> +1 (non-binding)
> > >>
> > >> Thanks for the KIP!
> > >>
> > >> On Wed, Mar 1, 2017 at 1:49 PM, Bill Bejeck
> wrote:
> > >>
> > >>> +1
> > >>>
> > >
how do you prevent that join from
> happening? Do you throw an exception?
>
> Thanks
> Eno
>
>
> > On 28 Feb 2017, at 10:04, Jeyhun Karimov wrote:
> >
> > Hi Eno,
> >
> > Thanks for feedback. I think you mean [1]. In this KIP we do not consider
> >
r
> processing inadvertently. Before this KIP, all the relevant topics have one
> time stamp extractor so that issue does not come up.
>
> What will be the behavior if times mismatch, e.g., for joins?
>
> Thanks
> Eno
>
> > On 22 Feb 2017, at 09:21, Jeyhun Karimov
1 - 100 of 135 matches
Mail list logo
