[jira] [Updated] (KAFKA-657) Add an API to commit offsets

[ https://issues.apache.org/jira/browse/KAFKA-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Arthur updated KAFKA-657: --- Attachment: KAFKA-657v2.patch v2 of the patch. Includes OffsetFetch and OffsetCommit APIs, some unit t

[jira] [Commented] (KAFKA-669) Irrecoverable error on leader while rolling to a new segment

[ https://issues.apache.org/jira/browse/KAFKA-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531526#comment-13531526 ] Jay Kreps commented on KAFKA-669: - To summarize I think this bug is fixed once those other

[jira] [Resolved] (KAFKA-670) Cleanup spurious .index files if present in the log directory on initialization

[ https://issues.apache.org/jira/browse/KAFKA-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Kreps resolved KAFKA-670. - Resolution: Fixed Closing since Neha checked in the patch. > Cleanup spurious .index file

[jira] [Commented] (KAFKA-669) Irrecoverable error on leader while rolling to a new segment

[ https://issues.apache.org/jira/browse/KAFKA-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531525#comment-13531525 ] Jay Kreps commented on KAFKA-669: - To close the loop on this there are multiple issues here

[jira] [Commented] (KAFKA-670) Cleanup spurious .index files if present in the log directory on initialization

[ https://issues.apache.org/jira/browse/KAFKA-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531497#comment-13531497 ] Neha Narkhede commented on KAFKA-670: - I checked in v1 as part of testing if the git re

[jira] [Commented] (KAFKA-673) Broker recovery check logic is reversed

[ https://issues.apache.org/jira/browse/KAFKA-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531498#comment-13531498 ] Neha Narkhede commented on KAFKA-673: - +1 :) > Broker recovery check l

[jira] [Updated] (KAFKA-673) Broker recovery check logic is reversed

[ https://issues.apache.org/jira/browse/KAFKA-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Kreps updated KAFKA-673: Attachment: KAFKA-673.patch Oopsy daisy. > Broker recovery check logic is reversed > --

[jira] [Updated] (KAFKA-673) Broker recovery check logic is reversed

[ https://issues.apache.org/jira/browse/KAFKA-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Kreps updated KAFKA-673: Affects Version/s: 0.8 > Broker recovery check logic is reversed > -

[jira] [Created] (KAFKA-673) Broker recovery check logic is reversed

Jay Kreps created KAFKA-673: --- Summary: Broker recovery check logic is reversed Key: KAFKA-673 URL: https://issues.apache.org/jira/browse/KAFKA-673 Project: Kafka Issue Type: Bug Reporte

[jira] [Commented] (KAFKA-664) Kafka server threads die due to OOME during long running test

[ https://issues.apache.org/jira/browse/KAFKA-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531344#comment-13531344 ] Jay Kreps commented on KAFKA-664: - +1 on doing cleanup in the expiry thread--expiry is a lo

Re: order guarantee failure: better/best effort?

So to expand on that, as a result my belief is that since we only allow one outstanding request per socket at a time it should be impossible to re-order requests. But we haven't rigorously tested this. If someone has a script that doesn't use the scala client and makes lots of requests I think we c

Re: order guarantee failure: better/best effort?

That is correct, but the network server only enqueues a single request from each socket at any given time. -Jay On Thu, Dec 13, 2012 at 9:40 AM, Prashanth Menon wrote: > From my understanding (correct me if I'm wrong here, Jay), if a client does > non-blocking writes on a single socket connect

[jira] [Commented] (KAFKA-664) Kafka server threads die due to OOME during long running test

[ https://issues.apache.org/jira/browse/KAFKA-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531337#comment-13531337 ] Neha Narkhede commented on KAFKA-664: - Thanks for patch v3, Joel ! It works correctly,

[jira] Subscription: outstanding kafka patches

Issue Subscription Filter: outstanding kafka patches (59 issues) The list of outstanding kafka patches Subscriber: kafka-mailing-list Key Summary KAFKA-672 Merge 0.8 changes to trunk https://issues.apache.org/jira/browse/KAFKA-672 KAFKA-670 Cleanup spurious .index f

[jira] [Commented] (KAFKA-374) Move to java CRC32 implementation

[ https://issues.apache.org/jira/browse/KAFKA-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531328#comment-13531328 ] Scott Carey commented on KAFKA-374: --- I was thinking of using Akka Actors, as they can pro

Re: can't commit to Kafka svn

That's wierd. We have to update the git ticket with ok, when we haven't really confirmed something basic like a push works. Ok, I'm updating that ticket with an ok. Thanks, Neha On Thu, Dec 13, 2012 at 10:34 AM, Jun Rao wrote: > The git repo is supposed to remain ready-only until we update the

Re: can't commit to Kafka svn

The git repo is supposed to remain ready-only until we update the ticket with an ok. Thanks, Jun On Thu, Dec 13, 2012 at 10:32 AM, Neha Narkhede wrote: > I tried to commit KAFKA-670 and I get this error - > > nnarkhed-ld:apache-kafka-git nnarkhed$ git push origin 0.8 > Counting objects: 29, don

Re: can't commit to Kafka svn

I tried to commit KAFKA-670 and I get this error - nnarkhed-ld:apache-kafka-git nnarkhed$ git push origin 0.8 Counting objects: 29, done. Delta compression using up to 8 threads. Compressing objects: 100% (12/12), done. Writing objects: 100% (15/15), 1.71 KiB, done. Total 15 (delta 7), reused 0 (d

Re: can't commit to Kafka svn

Ok. Thanks. Is the idea to leave site under svn after the git move? Thanks, Jun On Thu, Dec 13, 2012 at 9:55 AM, Joel Koshy wrote: > [0955][jkoshy@jkoshy-ld:~/kafka]$ git branch -r > origin/0.7 > origin/0.7.0 > origin/0.7.1 > origin/0.7.2 > origin/0.8 > origin/HEAD -> origin/trunk

Re: can't commit to Kafka svn

[0955][jkoshy@jkoshy-ld:~/kafka]$ git branch -r origin/0.7 origin/0.7.0 origin/0.7.1 origin/0.7.2 origin/0.8 origin/HEAD -> origin/trunk origin/consumer_redesign origin/legacy_client_libraries origin/trunk On Thu, Dec 13, 2012 at 9:49 AM, Jun Rao wrote: > https://git-wip-us.a

Re: can't commit to Kafka svn

https://git-wip-us.apache.org/repos/asf/kafka.git seems to be pointing to trunk. Do you know where is the 0.8 branch? Thanks, Jun On Wed, Dec 12, 2012 at 8:43 PM, Jay Kreps wrote: > I checked it out and ran tests. Looks good to me. Not sure if any one else > wants to kick the tires before we c

Re: order guarantee failure: better/best effort?

>From my understanding (correct me if I'm wrong here, Jay), if a client does non-blocking writes on a single socket connection, then it's entirely possible to see out-of-order writes in the server from the client's perspective. The requests are serialized/ordered on a connection only until it hits

Re: order guarantee failure: better/best effort?

So my belief is that we handle this correctly and that I was mistaken in filing that bug. However, since, as the bug points out, the problem can't exist in the scala client this may be mistaken and a problem may well remain. There are two reasons that requests should have enforced ordering: 1. The

order guarantee failure: better/best effort?

Hello all, While running my own system tests against 0.8/HEAD, I was seeing repeated ordering failures, and tracked it down a bit further. In simple summary, I am sending out 2 consecutive ProduceRequests, X and Y. Y gets written to disk before X. Consumer sees Y before X. Bug #382

order guarantee failure: better/best effort?

Hello all, While running my own system tests against 0.8/HEAD, I was seeing repeated ordering failures, and tracked it down a bit further. In simple summary, I am sending out 2 consecutive ProduceRequests, X and Y. Y gets written to disk before X. Consumer sees Y before X. Bug #382