Todd Palino created KAFKA-6559:
--
Summary: Iterate record sets before calling Log.append
Key: KAFKA-6559
URL: https://issues.apache.org/jira/browse/KAFKA-6559
Project: Kafka
Issue Type
search using the zk shell but couldn't find...
>
> Sagar.
>
> On Fri, Dec 22, 2017 at 7:45 PM, Todd Palino wrote:
>
> > Preferred replica election is naive. It will always follow the order of
> the
> > replicas as they are set. So if you want to set the default leader,
Preferred replica election is naive. It will always follow the order of the
replicas as they are set. So if you want to set the default leader, just
make it the first replica in the list for the partition. We build the JASON
this way all the time.
-Todd
On Dec 22, 2017 6:46 AM, "Sagar" wrote:
but I haven't looked into it further
> > than that. I agree that I don't see how this is going to help us at the
> app
> > layer.
> >
> > -Todd
> >
> > On Tuesday, September 6, 2016, Ismael Juma wrote:
> >
> > > Hi Todd,
> > >
[
https://issues.apache.org/jira/browse/KAFKA-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Palino updated KAFKA-5056:
---
Summary: Shuffling of partitions in old consumer fetch requests removed
(was: Shuffling of
[
https://issues.apache.org/jira/browse/KAFKA-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Palino updated KAFKA-5056:
---
Reviewer: Joel Koshy
Status: Patch Available (was: In Progress)
> Shuffling of partitions
[
https://issues.apache.org/jira/browse/KAFKA-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KAFKA-5056 started by Todd Palino.
--
> Shuffling of partitions in old consume fetch requests remo
Todd Palino created KAFKA-5056:
--
Summary: Shuffling of partitions in old consume fetch requests
removed
Key: KAFKA-5056
URL: https://issues.apache.org/jira/browse/KAFKA-5056
Project: Kafka
less common
> than thread pool configuration changes.
>
> Thanks,
>
> Jun
>
> On Tue, Mar 7, 2017 at 4:45 PM, Todd Palino wrote:
>
> > I’ve been following this one on and off, and overall it sounds good to
> me.
> >
> > - The SSL question is a good one.
I’ve been following this one on and off, and overall it sounds good to me.
- The SSL question is a good one. However, that type of overhead should be
proportional to the bytes rate, so I think that a bytes rate quota would
still be a suitable way to address it.
- I think it’s better to make the q
[
https://issues.apache.org/jira/browse/KAFKA-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15893728#comment-15893728
]
Todd Palino commented on KAFKA-1342:
[~wushujames], I'm not sure about incre
> > have
> > > > > tested RAID5's performance by creating a file system whose block
> size
> > > > > matches the RAID stripe size (https://www.percona.com/blog/
> > > > > 2011/12/16/setting-up-xfs-the-simple-edition/). This way, writing
&g
27;t you be in the
> business of making sure everyone uses them properly? Making sure
> everyone includes the right headers you need, not using the header
> names you intend to use, etc. I don't think the "policing" business
> will ever go away.
>
> On Thu, Dec 1, 2016 a
eaders in Kafka. I absolutely don't mind it if you do it...
> I think the Apache convention for "good idea, but not willing to put
> any work toward it" is +0.5? anyway, that's what I was trying to
> convey :)
>
> On Thu, Dec 1, 2016 at 3:05 PM, Todd Palino wrote:
&g
(Todd)... I am
> just looking for something concrete we can do to move the discussion
> along to the yummy design details (which is the argument I really am
> looking forward to).
>
> On Thu, Dec 1, 2016 at 1:53 PM, Todd Palino wrote:
> > So, Gwen, to your question (even though I’m
on a workable standard that we can adopt.
-Todd
On Thu, Dec 1, 2016 at 1:39 PM, Todd Palino wrote:
> C. per message encryption
>> One drawback of this approach is that this significantly reduce the
>> effectiveness of compression, which happens on a set of serialized
>> mes
>
> C. per message encryption
> One drawback of this approach is that this significantly reduce the
> effectiveness of compression, which happens on a set of serialized
> messages. An alternative is to enable SSL for wire encryption and rely on
> the storage system (e.g. LUKS) for at rest encryptio
[
https://issues.apache.org/jira/browse/KAFKA-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15700938#comment-15700938
]
Todd Palino commented on KAFKA-3959:
+1 as well. I think keeping the co
[
https://issues.apache.org/jira/browse/KAFKA-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15668010#comment-15668010
]
Todd Palino commented on KAFKA-3959:
As noted, I just want the config enforced. I
o help us at the app
layer.
-Todd
On Tuesday, September 6, 2016, Ismael Juma wrote:
> Hi Todd,
>
> Thanks for sharing your experience enabling TLS in your clusters. Very
> helpful. One comment below.
>
> On Sun, Sep 4, 2016 at 6:28 PM, Todd Palino > wrote:
> >
> >
o have Kafka over SSL working with
> reasonably good performance, but the current performance isn't promising.
> Expecting this to be fixed in the next couple of months and have it
> available in 0.10.x is probably too much to expect, but if we know the
> plans around this
t; > > > Kafka committer
> >> > > > about a year ago. I am glad to announce that Gwen is now a member
> of
> >> > > Kafka
> >> > > > PMC.
> >> > > >
> >> > > > Congratulations, Gwen!
> >>
on the current
> proposal?
>
> Jun
>
> On Thu, Aug 18, 2016 at 11:00 AM, Todd Palino wrote:
>
> > Joel just reminded me to take another look at this one :) So first off,
> > this is great. It’s something that we definitely need to have, especially
> > as we get in
gt; > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>> On Tue, Aug 9, 2016 at 10:49 AM, Joel Koshy <
> >> > > >>>>>> jjkosh...@gmail.com >
> >> > > >>>>>>>>>>> wrote:
> >> > &g
t;>>>>>>>>> the leader, and “move” partitions from the throttled
> > > >>>> replica
> > > >>>>>>>> fetchers
> > > >>&
[
https://issues.apache.org/jira/browse/KAFKA-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15425756#comment-15425756
]
Todd Palino commented on KAFKA-4050:
So first off, yes, the thread dump (w
[
https://issues.apache.org/jira/browse/KAFKA-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15423400#comment-15423400
]
Todd Palino commented on KAFKA-4050:
It appears to be called every time somet
Todd Palino created KAFKA-4050:
--
Summary: Allow configuration of the PRNG used for SSL
Key: KAFKA-4050
URL: https://issues.apache.org/jira/browse/KAFKA-4050
Project: Kafka
Issue Type
[
https://issues.apache.org/jira/browse/KAFKA-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420091#comment-15420091
]
Todd Palino commented on KAFKA-3959:
If that's the case, then the default
[
https://issues.apache.org/jira/browse/KAFKA-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419365#comment-15419365
]
Todd Palino commented on KAFKA-3959:
Agree with Onur 100% here. We've bee
[
https://issues.apache.org/jira/browse/KAFKA-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323930#comment-15323930
]
Todd Palino commented on KAFKA-3797:
Obviously we can't do something like th
[
https://issues.apache.org/jira/browse/KAFKA-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318854#comment-15318854
]
Todd Palino commented on KAFKA-3797:
I think the first option is more reasonable,
[
https://issues.apache.org/jira/browse/KAFKA-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15312288#comment-15312288
]
Todd Palino commented on KAFKA-3725:
I'll take a look at this and put toge
[
https://issues.apache.org/jira/browse/KAFKA-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Palino reassigned KAFKA-3725:
--
Assignee: Todd Palino
> Update documentation with regards to
t; I'm on 0.9.0.1. "broker-list" is invalid and zookeeper is required
> regardless of the bootstrap-server parameter.
>
>
> Thanks,
>
> Cliff
>
> On Sun, May 8, 2016 at 7:35 PM, Todd Palino wrote:
>
> > It looks like you’re just missing the proper mess
ain confidential and privileged
> information. Any unauthorized use of this email is strictly prohibited.
> ©2016 Signal. All rights reserved.
>
--
*—-*
*Todd Palino*
Staff Site Reliability Engineer
Data Infrastructure Streaming
linkedin.com/in/toddpalino
[
https://issues.apache.org/jira/browse/KAFKA-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15126292#comment-15126292
]
Todd Palino commented on KAFKA-3174:
Yeah, definitely no problems with Java
ge() -- whether all messages sent were
> acknowledged. I
> > > > also
> > > > > > > think that it would be better to solve this without
> interceptors,
> > > > such
> > > > > as
> > > > > > > fix error handling in t
> > the
> > > following API to producer and consumer interceptors:
> > >
> > > ProducerInterceptor:
> > > SerializedKeyValue onEnqueued(TopicPartition tp, ProducerRecord
> > > record, SerializedKeyValue serializedKeyValue);
> > >
> >
ival
> > > > and we won't need a console auditor.
> > > >
> > > > One potential issue in this approach and any elaborate on-arrival
> > > > processing for that matter is that you may need to deserialize the
> > > message
> >
> > >
> > > >
> > > >
> > > > This email and any attachments may contain confidential and
> privileged
> > > > material for the sole use of the intended recipient. Any review,
> > copying,
> > > > or distribution of this email (or any attachments) by others is
> > > prohibited.
> > > > If you are not the intended recipient, please contact the sender
> > > > immediately and permanently delete this email and any attachments. No
> > > > employee or agent of TiVo Inc. is authorized to conclude any binding
> > > > agreement on behalf of TiVo Inc. by email. Binding agreements with
> TiVo
> > > > Inc. may only be made by a signed written agreement.
> > > >
> > >
> > >
> > >
> > > --
> > > Thanks,
> > > Neha
> > >
> >
>
--
*—-*
*Todd Palino*
Staff Site Reliability Engineer
Data Infrastructure Streaming
linkedin.com/in/toddpalino
[
https://issues.apache.org/jira/browse/KAFKA-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15065636#comment-15065636
]
Todd Palino commented on KAFKA-3015:
[~jkreps] So yes, I'm essentially sayi
[
https://issues.apache.org/jira/browse/KAFKA-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15065239#comment-15065239
]
Todd Palino commented on KAFKA-3015:
While this seems good on the surface, it m
On Thu, Dec 3, 2015 at 11:37 AM, Jay Kreps wrote:
> Hey Todd,
>
> I actually agree on both counts.
>
> I would summarize the first comment as "Zookeeper is not hard to
> operationalize if you are Todd Palino"--also in that category of
> things that are not ha
tion
> with
> > no
> > > > operational dependencies.
> > > >
> > > > Thoughts?
> > > >
> > > > -Jay
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Dec 1,
[
https://issues.apache.org/jira/browse/KAFKA-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14994590#comment-14994590
]
Todd Palino commented on KAFKA-2759:
The thought we had internally on the situa
[
https://issues.apache.org/jira/browse/KAFKA-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14971806#comment-14971806
]
Todd Palino commented on KAFKA-2235:
I don't think we can. I have already
[
https://issues.apache.org/jira/browse/KAFKA-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14971740#comment-14971740
]
Todd Palino commented on KAFKA-2235:
I'm sure [~jjkoshy] will follow along
+1 (non-binding)
On Wed, Oct 21, 2015 at 6:53 PM, Jiangjie Qin
wrote:
> +1 (non-binding)
>
> On Wed, Oct 21, 2015 at 3:40 PM, Joel Koshy wrote:
>
> > +1 binding
> >
> > On Wed, Oct 21, 2015 at 8:17 AM, Flavio Junqueira
> wrote:
> >
> > > Thanks everyone for the feedback so far. At this point,
On Wed, Oct 21, 2015 at 3:38 PM, Flavio Junqueira wrote:
>
> > On 21 Oct 2015, at 21:54, Todd Palino wrote:
> >
> > Thanks for the clarification on that, Jun. Obviously, we haven't been
> doing
> > much with ZK authentication around here yet. There is still
step
> > is an advantage, though.
> >
> > > Given we are assuming all the information in zookeeper is world
> readable
> > ,
> > > I don¹t see SSL support as a must have or a blocker for this KIP.
> >
> > OK, but keep in mind that SSL is only av
, Oct 21, 2015 at 9:56 AM, Flavio Junqueira wrote:
>
> > On 21 Oct 2015, at 17:47, Todd Palino wrote:
> >
> > There seems to be a bit of detail lacking in the KIP. Specifically, I'd
> > like to understand:
> >
> > 1) What znodes are the brokers
ugh.
>
> Thanks,
> -Flavio
>
> > On 21 Oct 2015, at 17:41, Todd Palino wrote:
> >
> > While this is a great idea, is it really ready for vote? I don't see any
> > detail in the wiki about what trees will be secured, and whether or not
> > that is confi
There seems to be a bit of detail lacking in the KIP. Specifically, I'd
like to understand:
1) What znodes are the brokers going to secure? Is this configurable? How?
2) What ACL is the broker going to apply? Is this configurable?
3) How will the admin tools (such as preferred replica election and
While this is a great idea, is it really ready for vote? I don't see any
detail in the wiki about what trees will be secured, and whether or not
that is configurable. I also don't see anything about how the use of admin
tools is going to be addressed.
-Todd
On Wed, Oct 21, 2015 at 8:48 AM, Grant
[
https://issues.apache.org/jira/browse/KAFKA-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964228#comment-14964228
]
Todd Palino commented on KAFKA-2017:
I think we definitely need to maintain
[
https://issues.apache.org/jira/browse/KAFKA-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964003#comment-14964003
]
Todd Palino commented on KAFKA-2580:
It's about as graceful as an OOM, wh
[
https://issues.apache.org/jira/browse/KAFKA-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963986#comment-14963986
]
Todd Palino commented on KAFKA-2580:
I agree with [~jkreps] here, that having a
[
https://issues.apache.org/jira/browse/KAFKA-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14960809#comment-14960809
]
Todd Palino commented on KAFKA-2017:
Just to throw in my 2 cents here, I don
We should also consider what else should be negotiated between the broker
and the client as this comes together. The version is definitely first, but
there are other things, such as the max message size, that should not need
to be replicated on both the broker and the client. Granted, max message
s
I tend to like the idea of a pluggable locator. For example, we already
have an interface for discovering information about the physical location
of servers. I don't relish the idea of having to maintain data in multiple
places.
-Todd
On Mon, Sep 28, 2015 at 4:48 PM, Aditya Auradkar <
aaurad...@l
+1000
!
-Todd
On Wednesday, September 23, 2015, Jiangjie Qin
wrote:
> Hi,
>
> Thanks a lot for the reviews and feedback on KIP-31. It looks all the
> concerns of the KIP has been addressed. I would like to start the voting
> process.
>
> The short summary for the KIP:
> We are going to use the
So, with regards to why you want to search by timestamp, the biggest
problem I've seen is with consumers who want to reset their timestamps to a
specific point, whether it is to replay a certain amount of messages, or to
rewind to before some problem state existed. This happens more often than
anyo
[
https://issues.apache.org/jira/browse/KAFKA-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708282#comment-14708282
]
Todd Palino commented on KAFKA-1566:
This makes a lot of sense. We don't u
It does not. That last connection, the one in CLOSE_WAIT, is an outbound
connection from the broker you are looking at to one of the other brokers.
57821 is the source TCP port, and it is selected (somewhat) randomly from a
range of high port numbers. Note that the other end of the connection is
90
, but this may not be as
> secure). I think we also need the broker to be able to re-compress
> data, and since we always encrypt compressed bits (compressing
> encrypted bits doesn't compress), we need the broker to decrypt before
> re-compressing.
>
>
>
> On Fri, Jul 31, 20
It does limit it to clients that have an implementation for encryption,
however encryption on the client side is better from an auditing point of
view (whether that is SOX, HIPAA, PCI, or something else). Most of those
types of standards are based around allowing visibility of data to just the
peop
Since I've been dealing with the fallout of this particular problem all
week, I'll add a few thoughts...
On Wed, Jul 22, 2015 at 10:51 AM, Gwen Shapira
wrote:
>
>
> > On July 21, 2015, 11:15 p.m., Gwen Shapira wrote:
> > > core/src/main/scala/kafka/network/SocketServer.scala, line 465
> > > <
>
gt;> that most organizations are mostly consistent about naming topics -- they
>>>> standardize on one or the other.
>>>>
>>>> Since there's no "right" way to name them, I'd just leave it supporting
>>>> both and document the pot
n too. I agree that it is perverse,
> but
> > > people seem to do it. Breaking all the topics with '.' in the name
> seems
> > > like it could be worse than combining metrics for people who have a
> > > 'foo_bar' AND 'foo.bar' (and after
ve a
> > 'foo_bar' AND 'foo.bar' (and after all, having both is DEEPLY perverse,
> > no?).
> >
> > Where is our Dean of Compatibility, Ewen, on this?
> >
> > -Jay
> >
> > On Fri, Jul 10, 2015 at 1:32 PM, Todd Palino wrote:
> &
better.
>
> Gwen
>
>
>
> On Fri, Jul 10, 2015 at 1:22 PM, Grant Henke wrote:
> > Found it was added here: https://issues.apache.org/jira/browse/KAFKA-697
> >
> > On Fri, Jul 10, 2015 at 3:18 PM, T
ntary
in the ticket at the time, Gwen's identified a very good reason to be
restrictive about topic naming.
-Todd
On Fri, Jul 10, 2015 at 1:22 PM, Grant Henke wrote:
> Found it was added here: https://issues.apache.org/jira/browse/KAFKA-697
>
> On Fri, Jul 10, 2015 at 3:18 PM,
character other than ASCII alphanumerics, '.', '_' and
> '-'")
> case None => throw new InvalidTopicException("topic name " + topic +
> " is illegal, contains a character other than ASCII alphanumerics, '.',
> '_&#x
I had to go look this one up again to make sure -
https://issues.apache.org/jira/browse/KAFKA-495
The only valid character names for topics are alphanumeric, underscore, and
dash. A period is not supposed to be a valid character to use. If you're
seeing them, then one of two things have happened:
Congrats, Gwen! It's definitely deserved.
-Todd
> On Jul 6, 2015, at 6:08 PM, Joe Stein wrote:
>
> I am pleased to announce that the Apache Kafka PMC has voted to invite Gwen
> Shapira as a committer and Gwen has accepted.
>
> Please join me on welcoming and congratulating Gwen.
>
> Thanks f
[
https://issues.apache.org/jira/browse/KAFKA-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14586437#comment-14586437
]
Todd Palino commented on KAFKA-2252:
I moved the normal connection closed messag
o
>> be
>>>> ConfigOverrideManager and have it handle all the override types we will
>>>> have? I think I may just be unclear on what you are proposing...
>>>>
>>>> -Jay
>>>>
>>>> On Mon, May 18, 2015 at 1:34 PM, Aditya
Agree with Jun here on the JSON format. I think your intention was likely
to have actual JSON here and it was just a typo in the wiki?
-Todd
On Mon, May 18, 2015 at 12:07 PM, Jun Rao wrote:
> Aditya,
>
> Another thing to consider. In KIP-4, we are adding a new RPC request to
> change and retrie
I don't believe we're using the ResponsesBeingSent information at all. I
know we use NetworkProcessorAvgIdlePercent to keep track of the utilization
of the pool.
-Todd
On Thu, May 14, 2015 at 11:36 AM, Joel Koshy wrote:
> I'm also not sure how useful it is, but there is some discussion on it
>
not
> sure if I understand. Is that because we need to give the URL for ZK?
> Wouldn't the same argument work to say that we can't use configuration
> files because we have to specify the file path? I think we can just give
> the server the same --zookeeper argument we use ever
I've been watching this discussion for a while, and I have to jump in and
side with Gwen here. I see no benefit to putting the configs into Zookeeper
entirely, and a lot of downside. The two biggest problems I have with this
are:
1) Configuration management. OK, so you can write glue for Chef to p
[
https://issues.apache.org/jira/browse/KAFKA-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Palino reassigned KAFKA-2175:
--
Assignee: Todd Palino (was: Neha Narkhede)
> Reduce server log verbosity at info le
[
https://issues.apache.org/jira/browse/KAFKA-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Palino updated KAFKA-2175:
---
Attachment: KAFKA-2175.patch
> Reduce server log verbosity at info le
[
https://issues.apache.org/jira/browse/KAFKA-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Palino updated KAFKA-2175:
---
Status: Patch Available (was: Open)
> Reduce server log verbosity at info le
Todd Palino created KAFKA-2175:
--
Summary: Reduce server log verbosity at info level
Key: KAFKA-2175
URL: https://issues.apache.org/jira/browse/KAFKA-2175
Project: Kafka
Issue Type: Improvement
I tend to agree with Parth's point here. Most ACL systems I run into have deny
and allow. In general, you have a default policy of allow, then you follow your
rules stopping at the first line that matches. If you would like a default deny
policy, you have a bunch of allow rules and your last rul
/O throughput that you should optimize) and would then try to rebalance.
> To do the rebalance it would do a background copy of the log from the
> current disk to the new disk, then it would take the partition offline and
> delete the old log, then bring the partition back using the new log
I think this is a good start. We've been discussing JBOD internally, so
it's good to see a discussion going externally about it as well.
The other big blocker to using JBOD is the lack of intelligent partition
assignment logic, and the lack of tools to adjust it. The controller is not
smart enough
[
https://issues.apache.org/jira/browse/KAFKA-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484278#comment-14484278
]
Todd Palino commented on KAFKA-1342:
Bump
I think we need to revive this. We ha
I agree with Jun here, that it would make it easier to do lag checking.
However, for individual checks it's really not that much trouble to do the
second request. If you're doing a lot of lag checking (like every consumer
and every topic) where the scale would start to make a difference, I would
ar
the fs write queues up for a long-ass time). I think
> we need a separate client timeout which should be fairly long and unlikely
> to be hit (default to 30 secs or something).
>
> -Jay
>
> On Tue, Mar 10, 2015 at 10:12 AM, Todd Palino wrote:
>
> > Thanks, Jay. On the i
I understand the desire to not bloat this one change with too much more
work, and it's a good change to start with. That said, I have one note on
your comments:
"I don't agree with this because right now you get back "the current state of
the partitions" so you can (today) write whatever logic you
nger of slowing down a producing
> app that is configured to block. But actually this danger is no different
> than what will happen if it exceeds the node capacity now--when that
> happens requests will start getting slow and the app will block. The only
> difference is that that lim
Todd Palino created KAFKA-2012:
--
Summary: Broker should automatically handle corrupt index files
Key: KAFKA-2012
URL: https://issues.apache.org/jira/browse/KAFKA-2012
Project: Kafka
Issue Type
First, a couple notes on this...
3 - I generally agree with the direction of not pre-optimizing. However, in
this case I'm concerned about the calculation of the cost of doing plugins
now vs. trying to refactor the code to do it later. It would seem to me
that doing it up front will have less fric
o another, will we end up with some
> unread messages hanging around and no one thinks or knows it is their
> responsibility to take care of them?
>
> Thanks.
>
> Tong
>
> Sent from my iPhone
>
> > On Mar 5, 2015, at 10:46 AM, Todd Palino wrote:
> >
> &g
Apologize for the late comment on this...
So fair assignment by count (taking into account the current partition
count of each broker) is very good. However, it's worth noting that all
partitions are not created equal. We have actually been performing more
rebalance work based on the partition siz
Todd Palino created KAFKA-1987:
--
Summary: Potential race condition in partition creation
Key: KAFKA-1987
URL: https://issues.apache.org/jira/browse/KAFKA-1987
Project: Kafka
Issue Type: Bug
>
> Does that make sense?
>
> Gwen
>
>
>
> On Thu, Feb 12, 2015 at 12:34 PM, Todd Palino wrote:
>
> > The idea is more about isolating the intra-cluster traffic from the
> normal
> > clients as much as possible. There's a couple situations we've s
1 - 100 of 133 matches
Mail list logo
