Hi Jaikiran,
Thanks for your feedback. Comments inline.
On Wed, Aug 31, 2016 at 5:40 AM, Jaikiran Pai
wrote:
> Personally, I would be OK if the beta label is removed from it if the dev
> team is sure the API isn't going to change. I don't know if that's true or
> not post 0.10.0.1.
The API ha
Hey Harsha,
I'm trying to understand your specific concern. Is it the fact that the
client cannot tell the difference between non-existing topic and hence
needlessly retries (instead of perhaps raising an error). Or is it
specifically that in some cases, the consumer will block because of this?
In
I would like to see we address
https://issues.apache.org/jira/browse/KAFKA-1894 . This is problematic in
secure cluster when the users try to access the topics that they don't have
ACLs turned on.
-Harsha
On Tue, Aug 30, 2016 at 9:40 PM Jaikiran Pai
wrote:
> We have been using the (new) Java co
We have been using the (new) Java consumer API in 0.9.0.1 for a while
now. We have some well known issues with it - like heart beats being
part of the same thread causing the consumer to sometimes be considered
dead. I understand that this has been fixed in 0.10.0.1 but we haven't
yet had a cha
Thanks for the feedback everyone. Since Harsha said that he is OK either
way and everyone else is in favour, I think we should go ahead with this.
Since we committed to API stability for the new Java consumer in 0.10.0.0
via KIP-45, this is simply a documentation change and I don't think we need
an
+1 I talk to a lot of kafka users, and I would say > 75% of people doing
new things are on the new consumer despite our warnings :-)
-Jay
On Thu, Aug 25, 2016 at 2:05 PM, Jason Gustafson wrote:
> I'm +1 also. I feel a lot more confident about this with all of the system
> testing we now have in
New consumer API haven't taken a wide adoption yet from my experience with
users. We at Storm recently shipped the new consumer API spout and its
probably good idea wait a one more minor release before removing the beta
label. I am ok with either way.
Thanks,
Harsha
On Thu, Aug 25, 2016 at 2:05 P
I'm +1 also. I feel a lot more confident about this with all of the system
testing we now have in place (including the tests covering Streams and
Connect).
-Jason
On Thu, Aug 25, 2016 at 9:57 AM, Gwen Shapira wrote:
> Makes sense :)
>
> On Thu, Aug 25, 2016 at 9:40 AM, Neha Narkhede wrote:
> >
Makes sense :)
On Thu, Aug 25, 2016 at 9:40 AM, Neha Narkhede wrote:
> Yeah, I'm supportive of this.
>
> On Thu, Aug 25, 2016 at 9:26 AM Ismael Juma wrote:
>
>> Hi Gwen,
>>
>> We have a few recent stories of people using Connect and Streams in
>> production. That means the new Java Consumer too.
Yeah, I'm supportive of this.
On Thu, Aug 25, 2016 at 9:26 AM Ismael Juma wrote:
> Hi Gwen,
>
> We have a few recent stories of people using Connect and Streams in
> production. That means the new Java Consumer too. :)
>
> Ismael
>
> On Thu, Aug 25, 2016 at 5:09 PM, Gwen Shapira wrote:
>
> > Or
Hi Gwen,
We have a few recent stories of people using Connect and Streams in
production. That means the new Java Consumer too. :)
Ismael
On Thu, Aug 25, 2016 at 5:09 PM, Gwen Shapira wrote:
> Originally, we suggested keeping the beta label until we know someone
> successfully uses the new cons
Originally, we suggested keeping the beta label until we know someone
successfully uses the new consumer in production.
We can consider the recent KIPs enough, but IMO it will be better if
someone with production deployment hanging out on our mailing list
will confirm good experience with the new
Hi all,
We currently say the following in our documentation:
"As of the 0.9.0 release we have added a new Java consumer to replace our
existing high-level ZooKeeper-based consumer and low-level consumer APIs.
This client is considered beta quality."[1]
Since then, Jason and the community have do
13 matches
Mail list logo
