This is interesting. But wouldn't the cost of the I/O here (writing to log,
requests to slave nodes) completely dominate the cost of locks?
That is not the point (mostly). While you're waiting for a lock, you can't
issue another IO request. Avoiding locking is worthwhile even if CPU is the
[
https://issues.apache.org/jira/browse/KAFKA-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140231#comment-13140231
]
Taylor Gautier commented on KAFKA-48:
-
Hi - please keep in mind the use case where a
[
https://issues.apache.org/jira/browse/KAFKA-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140242#comment-13140242
]
Taylor Gautier commented on KAFKA-170:
--
Hi Jun.
My approach works like this:
1)
[
https://issues.apache.org/jira/browse/KAFKA-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140242#comment-13140242
]
Taylor Gautier edited comment on KAFKA-170 at 10/31/11 4:00 PM:
Erik,
Thanks for the pointer. This could be useful optimization. However, we
probably don't want to optimize too early until we understand the use
cases. Also, the replication logic itself is already non-trivial. Perhaps
we can look into this after the first version of replication is done?
No problems.
You could first program all tasks serially and then convert to the use the
disrupter later. With cleanly separated tasks this should be very easy to do.
So easy in fact that it might not be worth the wait ;)
BTW I respect the non-trivialness of multi-broker replication. That
Erik,
There have been some discussions on the jira, but the design doc has been
updated. If you feel that something needs to be changed, feel free to
comment on the jira.
Thanks,
Jun
On Mon, Oct 31, 2011 at 9:21 AM, Erik van Oosten e.vanoos...@grons.nlwrote:
No problems.
You could first
[
https://issues.apache.org/jira/browse/KAFKA-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140419#comment-13140419
]
Jay Kreps commented on KAFKA-48:
Yes, these are all good points. The work I have done so far
[
https://issues.apache.org/jira/browse/KAFKA-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140450#comment-13140450
]
Taylor Gautier commented on KAFKA-48:
-
I can see how it would be reasonable to do the
[
https://issues.apache.org/jira/browse/KAFKA-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140450#comment-13140450
]
Taylor Gautier edited comment on KAFKA-48 at 10/31/11 7:04 PM:
---
[
https://issues.apache.org/jira/browse/KAFKA-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140467#comment-13140467
]
Jay Kreps commented on KAFKA-48:
Hi Taylor,
Could you give a little more detail on your use
https://issues.apache.org/jira/browse/KAFKA/fixforversion/12317243
I don't seen any open issues listed.
Cool, makes sense.
I think the design doc is the current best thinking for replication. I
believe the plan for the LinkedIn crew is to try to get the apache release
out the door and then begin working on the various replication tickets for
0.8.x. I got a little ahead of myself and started on the
Log files always touched when broker is bounced
---
Key: KAFKA-179
URL: https://issues.apache.org/jira/browse/KAFKA-179
Project: Kafka
Issue Type: Bug
Components: core
On 10/31/2011 06:55 PM, Neha Narkhede wrote:
Chris, please could you elaborate a little more on this ? I think if
this is a small change, we can cut the RC today.
I think we ought to include a NEWS file for users upgading from a
previous version. Projects varry in how they do this, some
Similar information, but different audience. This is about summarising
only what has changed and is operational relevant (special pre/post
upgrade procedure or in this case upgrade order) in plain language.
Think of the experience when you are downloading a tarball, not people
who write
[
https://issues.apache.org/jira/browse/KAFKA-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140895#comment-13140895
]
Jay Kreps commented on KAFKA-176:
-
tryCleanupZookeeper looks cut-and-pasted from place to
Clean up shell scripts
--
Key: KAFKA-180
URL: https://issues.apache.org/jira/browse/KAFKA-180
Project: Kafka
Issue Type: Bug
Reporter: Jay Kreps
Assignee: Jay Kreps
Currently it is a bit of a
[
https://issues.apache.org/jira/browse/KAFKA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay Kreps updated KAFKA-171:
Attachment: KAFKA-171-v2.patch
I actually don't think we should make the writeTo method return a long since
[
https://issues.apache.org/jira/browse/KAFKA-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140935#comment-13140935
]
Neha Narkhede commented on KAFKA-171:
-
nnarkhed-mn:kafka-171 nnarkhed$ find . -name
20 matches
Mail list logo
