We have the new warning in 0.8.2.
I updated KIP-1 with the new plan:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1+-+Remove+support+of+request.required.acks
I'm waiting a day for additional discussion and if there are no
replies, I'll send the [VOTE] email.
Gwen
On Mon, Jan 19, 2015 a
Sounds good to me.
I'll open a new JIRA for 0.8.2 with just an extra log warning, to
avoid making KAFKA-1697 any more confusing.
On Mon, Jan 19, 2015 at 9:46 AM, Joe Stein wrote:
> << For 2, how about we make a change to log a warning for ack > 1 in 0.8.2
> and then drop the ack > 1 support in tr
<< For 2, how about we make a change to log a warning for ack > 1 in 0.8.2
and then drop the ack > 1 support in trunk (w/o bumping up the protocol
version)?
+1
On Mon, Jan 19, 2015 at 12:35 PM, Jun Rao wrote:
> For 2, how about we make a change to log a warning for ack > 1 in 0.8.2
> and then d
For 2, how about we make a change to log a warning for ack > 1 in 0.8.2 and
then drop the ack > 1 support in trunk (w/o bumping up the protocol
version)? Thanks,
Jun
On Sun, Jan 18, 2015 at 8:24 PM, Gwen Shapira wrote:
> Overall, agree on point #1, less sure on point #2.
>
> 1. Some protocols n
Overall, agree on point #1, less sure on point #2.
1. Some protocols never ever add new errors, while others add errors
without bumping versions. HTTP is a good example of the second type.
HTTP-451 was added fairly recently, there are some errors specific to
NGINX, etc. No one cares. I think we sh
Overall, I agree with Jay on both points.
1. I think it's reasonable to add new error codes w/o bumping up the
protocol version. In most cases, by adding new error codes, we are just
refining the categorization of those unknown errors. So, a client shouldn't
behave worse than before as long as unk
Hey guys,
I really think we are discussing two things here:
1. How should we generally handle changes to the set of errors? Should
introducing new errors be considered a protocol change or should we reserve
the right to introduce new error codes?
2. Given that this particular change i
I updated the KIP: Using acks > 1 in version 0 will log a WARN message
in the broker about client using deprecated behavior (suggested by Joe
in the JIRA, and I think it makes sense).
Gwen
On Fri, Jan 16, 2015 at 10:40 AM, Gwen Shapira wrote:
> How about we continue the discussion on this thread
How about we continue the discussion on this thread, so we won't lose
the context of this discussion, and put it up for VOTE when this has
been finalized?
On Fri, Jan 16, 2015 at 10:22 AM, Neha Narkhede wrote:
> Gwen,
>
> KIP write-up looks good. According to the rest of the KIP process proposal,
Gwen,
KIP write-up looks good. According to the rest of the KIP process proposal,
would you like to start a DISCUSS/VOTE thread for it?
Thanks,
Neha
On Fri, Jan 16, 2015 at 9:37 AM, Ewen Cheslack-Postava
wrote:
> Gwen -- KIP write up looks good. Deprecation schedule probably needs to be
> more
Gwen -- KIP write up looks good. Deprecation schedule probably needs to be
more specific, but I think that discussion probably needs to happen after a
solution is agreed upon.
Jay -- I think "older clients will get a bad error message instead of a
good one" isn't what would be happening with this
This is a good case to discuss.
Let's figure the general case of how we want to handle errors and get that
documented in the protocol. The problem right now is that we give no
guidance on this. I actually thought Gwen's suggestion made sense on the
guidance we should have given which is that we wi
I created a KIP for this suggestion:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1+-+Remove+support+of+request.required.acks
Basically documenting what was already discussed here. Comments will
be awesome!
Gwen
On Thu, Jan 15, 2015 at 5:19 PM, Gwen Shapira wrote:
> The errors are pa
+1 on Joe's suggestions, glad to see it happening!
On Thu, Jan 15, 2015 at 5:19 PM, Gwen Shapira wrote:
> The errors are part of the KIP process now, so I think the clients are
> safe :)
>
>
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
>
> On Thu, Jan 15, 2015
The errors are part of the KIP process now, so I think the clients are safe :)
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
On Thu, Jan 15, 2015 at 5:12 PM, Steve Morin wrote:
> Agree errors should be part of the protocol
>
>> On Jan 15, 2015, at 17:59, Gwen Shap
Agree errors should be part of the protocol
> On Jan 15, 2015, at 17:59, Gwen Shapira wrote:
>
> Hi,
>
> I got convinced by Joe and Dana that errors are indeed part of the
> protocol and can't be randomly added.
>
> So, it looks like we need to bump version of ProduceRequest in the
> following
Hi,
I got convinced by Joe and Dana that errors are indeed part of the
protocol and can't be randomly added.
So, it looks like we need to bump version of ProduceRequest in the
following way:
Version 0 -> accept acks >1. I think we should keep the existing
behavior too (i.e. not replace it with -1
Gwen,
I think the only option that wouldn't require a protocol version change is
the one where acks > 1 is converted to acks = -1 since it's the only one
that doesn't potentially break older clients. The protocol guide says that
the expected upgrade path is servers first, then clients, so old clie
> clients don't break on unknown errors
maybe true for the official java clients, but I dont think the assumption
holds true for community-maintained clients and users of those clients.
kafka-python generally follows the fail-fast philosophy and raises an
exception on any unrecognized error code
] on behalf
of Magnus Edenhill [mag...@edenhill.se]
Sent: Thursday, January 15, 2015 10:40 AM
To: dev@kafka.apache.org
Cc: kafka-clie...@googlegroups.com
Subject: [kafka-clients] Re: Heads up: KAFKA-1697 - remove code related to
ack>1 on the broker
I very much agree on what Joe is saying, let
Is the protocol bump caused by the behavior change or the new error code?
1) IMO, error_codes are data, and clients can expect to receive errors
that they don't understand (i.e. unknown errors). AFAIK, clients don't
break on unknown errors, they are simple more challenging to debug. If
we document
I very much agree on what Joe is saying, let's use the version field as
intended
and be very strict with not removing nor altering existing behaviour
without bumping the version.
Old API versions could be deprecated (documentation only?) immediately and
removed completely in the next minor version
This would sting a whole lot less if there was a programmatic way to get what
server version is in use. Also, how will this work in mixed version clusters
(during an upgrade, for example)?
> On Jan 15, 2015, at 10:10, Joe Stein wrote:
>
> Looping in the mailing list that the client developers
Looping in the mailing list that the client developers live on because they
are all not on dev (though they should be if they want to be helping to
build the best client libraries they can).
I whole hardily believe that we need to not break existing functionality of
the client protocol, ever.
The
Right, so this looks like it could create an issue similar to what's
currently being discussed in
https://issues.apache.org/jira/browse/KAFKA-1649 where users now get errors
under conditions when they previously wouldn't. Old clients won't even know
about the error code, so besides failing they won
Hi Kafka Devs,
We are working on KAFKA-1697 - remove code related to ack>1 on the
broker. Per Neha's suggestion, I'd like to give everyone a heads up on
what these changes mean.
Once this patch is included, any produce requests that include
request.required.acks > 1 will result in an exception. T
26 matches
Mail list logo
