Plus one. This is a good direction to move towards.
The frequency of releases would probably depend on how long it takes
to certify the release.
> On Aug 13, 2016, at 10:18 AM, Jay Kreps wrote:
>
> I'm +1.
>
> I've seen this both ways and I really do think that time-based releases
> tend to sca
sssues and improve time to
offset queries (seek by time.. mostly to deal with lag and such..)
Thanks
Kartik
On Sun, Oct 25, 2015 at 11:02 PM, Kartik Paramasivam <
kparamasi...@linkedin.com> wrote:
> This thread has gone rather long. So I might not be fully clear on
> everybody's po
> 1. May lead to not retaining data long enough for a consumer to get it,
> which the consumer would say is very bad
> 2. May lead to running out of disk space, which ops would say is very bad
>
> -Jay
>
>
>
>
> On Tue, Oct 20, 2015 at 12:02 AM, Kartik Paramasivam <
Joel or Becket will probably respond back in more detail.. but here are my
2c.
>From the standpoint of LinkedIN, the suggested proposal works.. in essence
max.appenddelay can be used to turn "creationTime" into "logAppendTime".
this does mean that at LinkedIn we won't be able to use "creationTi
Congratulations Sriharsha !!
Special thanks for all the awesome work on SSL. We are looking forward to
rolling out this feature at LinkedIn in the coming weeks.
cheers
Kartik
On Mon, Sep 21, 2015 at 9:10 PM, Jun Rao wrote:
> I am pleased to announce that the Apache Kafka PMC has voted to
> in
red, it should be easy to tell the reason
> for a rebalance, whether that is valid or not and how that should be tuned.
>
> As for the wrapper, KIP-28 is the wrapper in open source that will hide
> this complexity and I agree that LI is unblocked since you can do this in
> TrackerConsumer
+1
I like the idea of having CopyCat to be part of core Kafka, and having the
connectors to be in a separate sub-project.
This will allow CopyCat to be a new additional API for Kafka. Also it is
critical to keep the CopyCat API as solid and stable as the rest of Kafka.
The separate sub-projec
