KIP?
> TOPIC_AUTHORIZATION_FAILED (29) If the user didn't have Alter access to the
> topic.
Also... this command simply starts the leader election, but does not
wait for it to complete, right? What is the preferred method for an
admin to check the final result or identify when the fin
names for the same
configuration. In general I think Jason and Ismael's point is valid: do
we have evidence that "log cleaner" is causing confusion? If not, it
may not be worth it to rename this at the moment.
regards,
Colin
On Mon, Aug 21, 2017, at 05:19, Pranav Maniar wrot
he thread for
> KIP-113, I will be changing some more since I think we can
> DescribeDirsRequest
> instead of ReplicaStatusResponse to implement the --progress option.
That makes sense. Whatever response is used, it would be nice to have
an error message in addition to an error code.
b
return toString().equals(o.toString());
>}
Another question related to subclassing KafkaPrincipal: should we move
KafkaPrincipal#fromString into an internal, non-public class? It seems
like people might expect
KafkaPrincipal.fromString(myCustomPrincipal.toString()) to work, but it
wi
Thanks, Jason. +1 (non-binding)
Colin
On Tue, Aug 29, 2017, at 09:12, Jason Gustafson wrote:
> Hi Colin,
>
> Thanks for the comments. Seems reasonable to provide a safer `equals` for
> extensions. I don't think this needs to be part of the KIP, but I can add
> it to m
Thanks, Victor. Also check out the fault injection umbrella JIRA here:
https://issues.apache.org/jira/browse/KAFKA-5775 with more subtasks.
cheers,
Colin
On Fri, Sep 1, 2017, at 05:07, Viktor Somogyi wrote:
> Hi Colin,
>
> I'd be interested in this and also think it's a val
t; That is a workable alternative to providing 3 separate methods on the
> > AdminClient, but I don't see why it is objectively better. I don't see
> > clients commonly needing to do a mixture of alterations, and it assumes
> > that the options make sense for all alteration
in
this result
* even if the election was not successfully triggered.
*/
public KafkaFuture> partitions();
/**
* Return a future which gives an error result if we fail for any
partition.
*/
public KafkaFuture all();
}
We can fill in all thi
On Wed, Sep 6, 2017, at 00:20, Tom Bentley wrote:
> Hi Ted and Colin,
>
> Thanks for the comments.
>
> It seems you're both happier with reassign rather than assign, so I'm
> happy
> to stick with that.
>
>
> On 5 September 2017 at 18:46, Colin McCabe
On Wed, Sep 6, 2017, at 01:18, Tom Bentley wrote:
> Hi Colin,
>
> Thanks for taking the time to respond.
>
> On 5 September 2017 at 22:22, Colin McCabe wrote:
>
> > ...
> > Why does there need to be a map at all in the API?
>
>
> From a purely technical
unsubscribe
> On Apr 20, 2015, at 8:09 AM, Sriharsha Chintalapani (JIRA)
> wrote:
>
>
>[
> https://issues.apache.org/jira/browse/KAFKA-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14502761#comment-14502761
> ]
>
> Sriharsha Chintalapani com
Hi all,
I've been thinking about a KIP to improve the Kafka client's
compatibility policy. If you're interested, please check out:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-97%3A+Improved+Kafka+Compatibility+Policy
cheers,
Colin
Sorry, that link should be:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-97%3A+Improved+Kafka+Client+RPC+Compatibility+Policy
On Tue, Nov 29, 2016, at 11:04, Colin McCabe wrote:
> Hi all,
>
> I've been thinking about a KIP to improve the Kafka client's
> com
On Tue, Nov 29, 2016, at 11:39, Ashish Singh wrote:
> Hello Colin,
>
> In the KIP you mentioned that currently the client uses supported api
> versions information to check if the server supports its desired
> versions.
> Not sure, if that is true. I had put together a PR for
can use it as a building block for the stuff
described in this KIP. I'd be happy to review it.
Colin
On Wed, Nov 30, 2016, at 10:40, Ashish Singh wrote:
> Hello Ismael,
>
> It is good to know that you are willing to review KAFKA-3600 again. As
> before, we at Cloudera are hig
Hi all,
I updated the KIP to include a command to print out the version
information of brokers (KAFKA-4457). This will be a useful command for
administrators.
best,
Colin
On Wed, Nov 30, 2016, at 11:17, Colin McCabe wrote:
> Thanks, Ashish. I think the idea of having the client make
On Fri, Dec 2, 2016, at 13:41, Ashish Singh wrote:
> Colin,
>
> I just rebased KAFKA-3600's PR on trunk.
>
Thanks, Ashish!
> KAFKA-4457 is a good idea, however it is probably doing some redundant
> work. AdminClient has a network client that will already have api
> ve
best,
Colin McCabe
ng Kafka docker images for testing
here: https://issues.apache.org/jira/browse/KAFKA-4465 Once this is
done, it could be useful for trying out Kafka as well, I bet.
best,
Colin
>
>
> Thanks,
>
> Jared, (??)
> Software developer
> Interested in open source software, big data, Linux
ow must upgrade to Java 8.
Of course, there are still many people using Hadoop 2.x and
distributions derived from it, and will be for a while.
best,
Colin
On Mon, Nov 28, 2016, at 11:21, Ismael Juma wrote:
> By supporting two Java versions, I mean supporting the two most recent
> one
-97
(https://cwiki.apache.org/confluence/display/KAFKA/KIP-97%3A+Improved+Kafka+Client+RPC+Compatibility+Policy
).
The discussion thread can be found here:
https://www.mail-archive.com/dev@kafka.apache.org/msg60955.html
Thanks for your feedback.
best,
Colin McCabe
. I think it
will be pretty useful to be able to query broker versions, especially
during an upgrade.
cheers,
Colin
On Thu, Dec 8, 2016, at 09:39, Sriram Subramanian wrote:
> +1 (binding)
>
> On Thu, Dec 8, 2016 at 5:42 AM, Ismael Juma wrote:
>
> > Thanks for the KIP Colin, +1
With binding +1 votes from Gwen Shapira, Ismael Juma, Sriram
Subramanian, Guozhang Wang, Neha Narkhede, Jay Kreps, Ewen
Cheslack-Postava, and non-binding votes from Edoardo Comar and Rajini
Sivaram, vote passes. There were no +0 or -1 votes.
cheers,
Colin McCabe
On Sat, Dec 10, 2016, at 21:46
t is adding
quite as much value there as it might for a C/C++ application.
Is there a Maven or Gradle plugin that could generate this automatically
from the install tar.gz file the project already maintains?
best,
Colin
On Tue, Dec 6, 2016, at 06:04, Michael Hall wrote:
> Hello all,
>
&g
tify
particular types of traffic. Would it be more appropriate to call these
"traffic types" or "endpoint types"? Or am I misunderstanding the
proposal?
cheers,
Colin
On Thu, Dec 22, 2016, at 08:00, Ismael Juma wrote:
> I've updated the KIP to:
>
> 1. Incl
Can you be a little bit clearer on why you think that different keys
with the same digest value will be treated as the same key?
SkimpyOffsetMap#get and SkimpyOffsetMap#put compare the key, not just
the hash digest of the key.
best,
Colin
On Wed, Dec 21, 2016, at 23:27, Renkai Ge wrote:
>
I noticed that the throttle_time_ms added to all the message responses
is in milliseconds. Does it make sense to express this in microseconds
in case we start doing more fine-grained CPU throttling later on? An
int32 should still be more than enough if using microseconds.
best,
Colin
On Fri
+1 (non-binding).
Thanks, Ismael.
cheers,
Colin
On Mon, Feb 27, 2017, at 19:47, Ismael Juma wrote:
> Hi all,
>
> With 0.10.2.0 out of the way, I would like to volunteer to be the release
> manager for our next time-based release. See https://cwiki.apache.org/c
> onfluence/dis
Hi all,
Thanks for commenting, everyone. Does anyone have more questions or
comments, or should we vote? The latest proposal is up at
https://cwiki.apache.org/confluence/display/KAFKA/KIP-117%3A+Add+a+public+AdminClient+API+for+Kafka+admin+operations
best,
Colin
On Thu, Feb 16, 2017, at 15
That makes sense. I didn't see that this field already existed in some
of the replies-- good clarification.
best,
On Wed, Mar 1, 2017, at 05:41, Rajini Sivaram wrote:
> Colin,
>
> Thank you for the feedback. Since we are reusing the existing
> throttle_time_ms field
which may
> be
> too much freedom).
We don't need to express every optional bell and whistle by creating a
subclass. In fact, the proposal already had setConfigs() in the base
class, since it applies to every new topic creation.
Thinking about it a little more, though, the subclasses
On Fri, Mar 3, 2017, at 06:41, Ismael Juma wrote:
> Hi Colin,
>
> I still need to do a detailed review, but I have a couple of
> comments/questions:
>
> 1. I am not sure about having the options/response classes as inner
> classes
> of the interface. It means that file
e implementation, so that can be changed later. We
can materialize things in memory lazily if we want to, and so forth. I
think using the standard interface is better than rolling our own
nonstandard collection or iterator interfaces.
regards,
Colin
On Wed, Mar 1, 2017, at 12:59, Becket Qi
On Mon, Mar 6, 2017, at 05:50, Ismael Juma wrote:
> Thanks Colin. It seems like you replied to me accidentally instead of the
> list, so leaving your reply below for the benefit of others.
Thanks, Ismael. I actually realized my mistake right after I sent to
you, and re-posted it to the m
On Mon, Mar 6, 2017, at 11:55, Ismael Juma wrote:
> Thanks Colin.
>
> I am familiar with the protocol semantics, but we need to document the
> API
> for users who don't know the protocol. I still think it would be valuable
> to have some examples of how the API would be us
this is in, we can iterate on it before the release, and it will
also unblock a lot of other admin proposals. I think it would be good
to start the vote in a little bit, assuming there are no objections.
best,
Colin
On Wed, Mar 8, 2017, at 17:09, Colin McCabe wrote:
> On Mon, Mar 6, 2017, at
Hi all,
I'd like to start voting on KIP-117
(https://cwiki.apache.org/confluence/display/KAFKA/KIP-117%3A+Add+a+public+AdminClient+API+for+Kafka+admin+operations
).
The discussion thread can be found here:
https://www.mail-archive.com/dev@kafka.apache.org/msg65697.html
best,
Colin
o get the AdminClient interface in, and
start iterating on it incrementally as we discover ways it could be
better. This is similar to how some things in Streams were added as
unstable interfaces and then stabilized over time.
best,
Colin
>
> On Thu, Mar 9, 2017 at 2:14 PM, Colin McCabe
On Mon, Mar 13, 2017, at 22:29, Gwen Shapira wrote:
> I'm torn between my desire to get this in already and the fact that parts
> of the API feel a bit alien to Kafka.
>
> I will resolve my difficulties by giving my feedback here and then going
> to
> vote +1 on the v
the API are:
1. supports async via CompletableFuture
2. supports batching
3. easily extensible and configurable
The other stuff really is just details that we can easily change before
the release. For example, if you really feel strongly that request
classes are the way to go and can get everyone el
On Tue, Mar 14, 2017, at 13:36, Becket Qin wrote:
> The interface looks good overall. Thanks for the much needed work Colin.
Thanks, Becket.
> Just a few comments:
>
> 1. I agree with Gwen that it is a little unfortunate we have to double
> the
> methods for batching int
On Tue, Mar 14, 2017, at 18:43, Becket Qin wrote:
> Hi Colin,
> Thanks for the reply. Please see comments inline.
>
> On Tue, Mar 14, 2017 at 5:30 PM, Colin McCabe wrote:
> > I'm not sure if there is a benefit to removing createTopic and
> > deleteTopic. It seems
le try out the API a bit, it will be easier to evaluate these.
best,
Colin
On Tue, Mar 14, 2017, at 10:12, Dong Lin wrote:
> +1
>
> On Tue, Mar 14, 2017 at 8:50 AM, Grant Henke wrote:
>
> > +1
> >
> > On Tue, Mar 14, 2017 at 2:44 AM, Sriram Subramanian
> >
is for
> example when reading an avro topic but someone pushes a message that’s
> not avro, currently consumers would break.
Interesting idea. How about a Deserializer implementation that wraps
other Deserializer implementations in a try...catch block?
best,
Colin
>
> 2) Abili
Hi Amit,
In your example, computer A would be running the Kafka producer (which
is a software library) and computer B would be running the Kafka broker
(which is a long running-program, or daemon). Hope that helps.
best,
Colin
On Fri, Mar 10, 2017, at 01:27, amit tomar wrote:
> Hi Expe
On Fri, Mar 17, 2017, at 10:50, Jun Rao wrote:
> Hi, Colin,
>
> Thanks for the KIP. Looks good overall. A few comments below.
>
> 1. Sometimes we return
> CompletableFuture>
> and some other times we return
> Map>
> , which doesn't seem consiste
With binding +1 votes from Gwen Shapira, Sriram Subramanian, and Grant
Henke, and a non-binding vote from Dong Lin, the vote passes. There
were no +0 or -1 votes. As mentioned earlier, the interface will be
unstable at first and we will continue to evolve it.
thanks,
Colin McCabe
On Wed, Mar
ht to
combine them into one RP It seems that when both add and remove
operations are combined into one RPC, there are some thorny questions
about ordering (does a delete ACL operation on a topic happen first, or
an add ACL operation?)
best,
Colin
have
APIs like that, shouldn't we have AlterTopicsRequest and
DescribeTopicsRequest instead of ListAclsRequest,
ListConfigurationRequest, AlterAclsRequest, AlterConfigurationRequest?
I'm curious which approach seems better.
cheers,
Colin
On Thu, Apr 13, 2017, at 14:38, Ismael Juma wrot
o you envision the AdminClient APIs looking like for
getting/setting broker, topic, and client configs? I guess we could
just have getBrokerConfigs / setBrokerConfigs / getTopicConfigs /
setTopicConfigs / getClientConfigs / setClientConfigs. As you said,
though, there is a question whether th
here:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-142%3A+Add+ListTopicsRequest+to+efficiently+list+all+the+topics+in+a+cluster
cheers,
Colin
name, since you may trigger topic auto-create. Right now
your only choice is MetadataRequest(topics=*)
And the simplest application... "./bin/kafka-topics.sh --list" returns
just topic names, no other information by default.
best,
Colin
On Thu, Apr 20, 2017, at 15:18, Jeff Widman wro
/KAFKA/KIP-140%3A+Add+administrative+RPCs+for+adding%2C+deleting%2C+and+listing+ACLs
regards,
Colin
ns to CreateTopicsRequest... right now
it just returns an error code, but a text message would be a nice
addition.
cheers,
Colin
On Thu, Jan 5, 2017, at 13:41, dan wrote:
> it would be nice to have a dry-run or validate ability added to this kip.
> since we are offloading validation to a 3rd party im
That's a fair point. The calls to Arrays.equals are comparing just the
hashes, not the keys.
Colin
On Tue, Jan 3, 2017, at 17:15, radai wrote:
> looking at the code (SkimpyOffsetMap.get/put) they both start with
> hashInto(key, hash1) and then ignore key from that point on - so
Looks good. +1 (non-binding).
What do you think about changing "protocol label" to "listener key"?
best,
Colin
On Fri, Jan 6, 2017, at 09:23, Neha Narkhede wrote:
> +1
>
> On Fri, Jan 6, 2017 at 9:21 AM Jun Rao wrote:
>
> > Hi, Ismael,
> >
>
ior seems to be more desirable, since clients do not "get
stuck" on messages that are too big. I propose that we edit the wiki to
reflect the implemented behavior by deleting the references to special
behavior when max_bytes is MAX_INT.
cheers,
Colin
Thanks, all. I edited the wiki to reflect the implemented behavior by
dropping references to special behavior when max_bytes was INT_MAX.
cheers,
Colin
On Sat, Jan 21, 2017, at 09:44, radai wrote:
> +1
>
> On Fri, Jan 20, 2017 at 9:51 PM, Apurva Mehta
> wrote:
>
> > +
Thanks for looking at this, Akhilesh. Can you be a little bit clearer
about why keeping all the scripts or script symlinks in the same
directory is not an option for you?
best,
Colin
On Tue, Jan 24, 2017, at 06:01, Akhilesh Naidu wrote:
> Hi,
>
>
> The bug deals with
te designs" design, even if you end
up deciding it's not the way to go.
best,
Colin
On Thu, Jan 12, 2017, at 10:46, Dong Lin wrote:
> Hi all,
>
> We created KIP-112: Handle disk failure for JBOD. Please find the KIP
> wiki
> in the link https://cwiki.apache.org/confluence
an interesting idea, but... is there a user use-case for a property
like this? I'm having a hard time thinking of one, but maybe I missed
something.
cheers,
Colin
>
> Currently offsets.topic.replication.factor is used for that purpose, so
> with offsets.topic.replication.factor
+1 (non-binding)
On Wed, Jan 25, 2017, at 16:34, Onur Karaman wrote:
> I'd like to start the vote for KIP-115: Enforce
> offsets.topic.replication.factor
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-115%3A+Enforce+offsets.topic.replication.factor
>
> - Onur
On Wed, Jan 25, 2017, at 13:50, Dong Lin wrote:
> Hey Colin,
>
> Good point! Yeah we have actually considered and tested this solution,
> which we call one-broker-per-disk. It would work and should require no
> major change in Kafka as compared to this JBOD KIP. So it would be a go
that much-- maybe there is a good solution out there.
best,
Colin
On Thu, Jan 26, 2017, at 22:37, Akhilesh Naidu wrote:
> Hi Colin,
>
>
> I had picked up this bug from when it was reported specifically for the
> script 'kafka-console-consumer.sh'.
>
> Going through t
test
plan about injecting IOExceptions into disk handling code and verifying
that we can handle it correctly.
regards,
Colin
On Wed, Feb 1, 2017, at 10:02, Dong Lin wrote:
> Hey Grant,
>
> Yes, this KIP does exactly what you described:)
>
> Thanks,
> Dong
>
> On Wed, F
On Wed, Feb 1, 2017, at 11:35, Dong Lin wrote:
> Hey Grant, Colin,
>
> My bad, I misunderstood Grant's suggestion initially. Indeed this is a
> very
> interesting idea to just wait for replica.max.lag.ms for the replica on
> the
> bad disk to drop out of ISR instead
+AdministrativeClient+API+for+Kafka+admin+operations
regards,
Colin
On Thu, Feb 2, 2017, at 17:54, Dong Lin wrote:
> Hey Colin,
>
> Thanks for the KIP. I have a few comments below:
>
> - I share similar view with Ismael that a Future-based API is better.
> PurgeDataFrom() is an example API that user may want to do it
> asynchronously even
On Thu, Feb 2, 2017, at 21:45, Becket Qin wrote:
> Hi Colin,
>
> Thanks for the KIP. An admin client is probably a must after we block
> direct access to ZK. Some comments and thoughts below:
>
> 1. Do we have a clear scope for the admin client? It might be worth
> thinking
On Thu, Feb 2, 2017, at 15:02, Ismael Juma wrote:
> Hi Colin,
>
> Thanks for the KIP, great to make progress on this. I have some initial
> comments, will post more later:
>
> 1. We have KafkaProducer that implements the Producer interface and
> KafkaConsumer that im
On Fri, Feb 3, 2017, at 16:25, Guozhang Wang wrote:
> Thanks for the proposal Colin. A few comments below:
Thanks for taking a look, Guozhang.
>
> 1. There are a couple of classes that looks new to me but not defined
> anywhere. For example: NewTopic (topic name and configs?), T
On Fri, Feb 3, 2017, at 16:25, Guozhang Wang wrote:
> Thanks for the proposal Colin. A few comments below:
>
> 1. There are a couple of classes that looks new to me but not defined
> anywhere. For example: NewTopic (topic name and configs?), TopicInfo (is
> th
On Fri, Feb 3, 2017, at 16:57, Dong Lin wrote:
> Thanks for the reply, Colin. I have some comments inline.
Hi Dong L.,
>
> In addition, I also have some comments regarding the Future() in response
> to your latest email. As Ismael mentioned, we have added
> purgeDataBe
On Mon, Feb 6, 2017, at 13:54, Guozhang Wang wrote:
> Some follow-up on 2) / 3) below.
>
> On Mon, Feb 6, 2017 at 11:21 AM, Colin McCabe wrote:
>
> > On Fri, Feb 3, 2017, at 16:25, Guozhang Wang wrote:
> > > Thanks for the proposal Colin. A few comments below:
>
group.
This information isn't in the groups RPCs yet, so it would need a
separate KIP to implement. Let's talk about this more once we have the
basic API in.
best,
Colin
>
> Regards,
>
> -- Jianbin
>
> > On Feb 6, 2017, at 13:54, Guozhang Wang wrote:
> >
>
gt; 2. Since deleting topic is a totally async process, is there any way for
> me to make sure the topic is deleted successfully after invoking
> deleteTopic once the KIP is implemented?
One way would be to periodically list the topics and wait for it to go
away.
best,
Col
ion to the class and specify in the
> javadoc that the methods are subject to change (if necessary).
>
> Thoughts?
+1.
I'm going to reorganize the proposal a bit to use futures and to have
the grouping by API type proposed earlier.
best,
Colin
>
> Ismael
>
> On Fri, F
ssue before implementing it, though.
I think it would be good to get something out there, annotate it as
@Unstable, and get feedback from people building against trunk and using
it. We have removed or changed @Unstable APIs in streams before, so I
don't think we should worry that it will g
+1 (non-binding)
On Thu, Feb 9, 2017, at 07:31, Ismael Juma wrote:
> Hi everyone,
>
> Since everyone in the discuss thread was in favour (10 people responded),
> I
> would like to initiate the voting process for KIP-118: Drop Support for
> Java 7 in Kafka 0.11:
>
> https://cwiki.apache.org/con
On Wed, Feb 8, 2017, at 18:39, Dong Lin wrote:
> Hey Colin,
>
> Thanks for updating the KIP. I have two followup questions:
>
> - It seems that setCreationConfig(...) is a bit redundant given that most
> arguments (e.g. topic name, partition num) are already passed to
>
e context objects are extremely lightweight and are not intended to be
shared between multiple threads. So each thread would just do
client.topics().setClientTimeout(...).create(), and operate on its own
TopicsContext. I will add that to the wiki.
best,
Colin
>
> Thanks,
> Dong
>
h this is similar to Colin's
> >> > suggestion of one-broker-per-disk, which we have evaluated at LinkedIn
> >> and
> >> > considered it to be a good short term approach.
> >> >
> >> > As of now I don't think any of these approach is a be
On Thu, Feb 9, 2017, at 11:03, Colin McCabe wrote:
> Thanks, Dong L.
>
> Do we plan on bringing down the broker process when all log directories
> are offline?
>
> Can you explicitly state on the KIP that the log dirs are all considered
> good after the broker process is bo
On Thu, Feb 9, 2017, at 11:40, Dong Lin wrote:
> Thanks for all the comments Colin!
>
> To answer your questions:
> - Yes, a broker will shutdown if all its log directories are bad.
That makes sense. Can you add this to the writeup?
> - I updated the KIP to explicitly s
On Sun, Feb 12, 2017, at 09:21, Jay Kreps wrote:
> Hey Colin,
>
> Thanks for the hard work on this. I know going back and forth on APIs is
> kind of frustrating but we're at the point where these things live long
> enough and are used by enough people that it is worth the pa
is just about public
APIs.
It's worth thinking about for the future, though.
best,
Colin
>
> On Mon, Feb 13, 2017 at 11:51 AM, Colin McCabe
> wrote:
>
> > On Sun, Feb 12, 2017, at 09:21, Jay Kreps wrote:
> > > Hey Colin,
> > >
> > > Thanks f
is complete, or you
can wait on futures for individual topics being created.
I updated the wiki, so please take a look. Note that this new API
requires JDK8. It seems like JDK8 is coming soon, though, and the
disadvantages of sticking to Java 7 are pretty big here, I think.
best,
Colin
On Mon,
+1 for varints here-- it would save quite a bit of space. They are
pretty quick to implement as well.
I think it makes sense for values to be byte arrays. Users might want
to attach arbitrary payloads; they shouldn't be forced to serialize
everything to Java strings.
best,
Colin
On Thu
On Thu, Feb 16, 2017, at 14:11, Dong Lin wrote:
> Hey Colin,
>
> Thanks for the update. I have two comments:
>
> - I actually think it is simpler and good enough to have per-topic API
> instead of batch-of-topic API. This is different from the argument for
> batch-of-
Hi Brian,
Have you created a pull request for this?
best,
Colin
On Thu, Feb 9, 2017, at 15:21, Brian Cornally wrote:
> @apachekafka suggested addition to
> http://kafka.apache.org/documentation/#security - section 5 - Examples
> using console-producer and console-consumer:
>
s-for-an-application-instance
Another approach would be to feed your kafka stream into a database of
some kind and do queries against the database.
regards,
Colin
On Tue, Feb 14, 2017, at 08:42, Samy CHBINOU wrote:
> In kafka there is a Subscribe API to be notified of incoming message
> va
ity
perspective. Perhaps some better documentation could help here?
best,
Colin
On Thu, Feb 16, 2017, at 16:32, Cosmin Lehene wrote:
> Wow, I managed to send two incomplete messages thanks to the new mac
> touchbar :)
>
>
> I was suggesting either renaming to IllegalTopicExcepti
On Thu, Aug 15, 2019, at 11:47, Jason Gustafson wrote:
> Hey Colin, I think deleting all offsets is equivalent to deleting the
> group, which can be done with the `deleteConsumerGroups` api. I debated
> whether there should be a way to delete partitions for all unsubscribed
> topics, b
Thanks, Rajini. It looks good to me.
best,
Colin
On Thu, Aug 15, 2019, at 11:37, Rajini Sivaram wrote:
> Hi Colin,
>
> Thanks for the review. I have updated the KIP to move the interfaces for
> request context and server info to the authorizer package. These are
On Tue, Aug 13, 2019, at 11:19, David Jacot wrote:
> Hi Colin,
>
> Thank you for the KIP! Things are well explained!. It is huge improvement
> for the Kafka protocol. I have few comments on the proposal:
>
> 1. The interleaved tag/length header sounds like a great optimisatio
h the
> > possible exception of Fetch/Produce, where the ROI may be higher for the
> > manual work)
>
> Yeah, that makes sense. Maybe we can include the version bump for all RPCs
> in this KIP, but we can implement it lazily as the protocols are converted.
Good idea.
best,
Colin
+1 (binding)
Thanks, Rajini!
best,
Colin
On Fri, Aug 16, 2019, at 09:52, Rajini Sivaram wrote:
> Hi all,
>
> I would like to start the vote for KIP-504:
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-504+-+Add+new+Java+Authorizer+Interface
>
> This KIP replaces th
test
should know what the most appropriate time limit is (30 seconds, 5 minutes,
whatever) and should put in a timeout with code like this:
>@Rule
>final public Timeout globalTimeout = Timeout.millis(12);
That will avoid wasting a lot of Jenkins (and developer!) time.
best,
Col
mething, but I don't understand the discussion of
Security.insertProviderAt() that you included. SslEngineBuilder doesn't use
that API to get the security provider. Instead, it calls
"SSLContext.getInstance(protocol, provider)", where provider is the name of the
provider.
b
Hi David,
Good point. I think it makes the most sense to put the tagged fields sections
at the end of the header. For consistency's sake, we can also put them at the
end of the structures / requests / responses as well. I've updated the KIP.
best,
Colin
On Mon, Aug 19, 2019
501 - 600 of 2176 matches
Mail list logo
