Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 03DEE200D1C for ; Sun, 1 Oct 2017 04:00:29 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id ECFC31609EE; Sun, 1 Oct 2017 02:00:28 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 1742F1609D5 for ; Sun, 1 Oct 2017 04:00:27 +0200 (CEST) Received: (qmail 44099 invoked by uid 500); 1 Oct 2017 02:00:21 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 44087 invoked by uid 99); 1 Oct 2017 02:00:21 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Oct 2017 02:00:21 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 331881807E8 for ; Sun, 1 Oct 2017 02:00:21 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.23 X-Spam-Level: *** X-Spam-Status: No, score=3.23 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=2, KAM_INFOUSMEBIZ=0.75, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id MyvRzAPMCH4n for ; Sun, 1 Oct 2017 02:00:17 +0000 (UTC) Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id ACB145F1EE for ; Sun, 1 Oct 2017 02:00:16 +0000 (UTC) Received: by mail-qk0-f173.google.com with SMTP id o187so378563qke.7 for ; Sat, 30 Sep 2017 19:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=i+VcnaWWnHoYyJumG9QlZEXUPGarbsQDQIC9mRT2tpg=; b=jbbcv/h+Bvj1cs0fdExWdzNGB/HUivwkzrpbyXN5Yu7dt/0U8+4rIBD1GWYvGumd2E S84hT+V4sVvcQP1VmuC62RvQfitljpY5tkOUjo5XvwcYvW9aINOdPympnsiDyCzBQnUA dSCjXI6kIdAKNvYGsPEuZX/8FK3N0tK87RHmydy+r+YrfaADy7Gez1XpNbqMRXaBMMF0 kwZEwK/pgPB7UK5Y8caWDl7clp5NE3cOCRJgBDTzypdd9K5JdQs3m2sgYvXM/lb5xSMd ELwKWLuVZyes17mf8p7GchjdS1+J3egIV+VyIy43/NOVIuRROOWK5MqU4V02biHPJvJu DOaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=i+VcnaWWnHoYyJumG9QlZEXUPGarbsQDQIC9mRT2tpg=; b=ImC0sMGnx9DAqIXfk2DbTFMGYwMHUHeBg9wjNKs/dR+sTwoib2pJ3L+SQ0PoVPU1pQ Sg91teU7ngm9gHd2BCg6XhA1a5bZ4/tV1+DLfgwwH7i/qjPbWMJ0EAylbPzS8lxXM6aV GiuiLEa7BjGRf+4Gg8ozNrwAFSXqOaStTdoLTNp5JhhLRDLjoszHOhpkJzsNGZN8g+gs KNdJX1lrl6ikQzZlnKnoskqp3SPkDgPxqAfCgBGUjToM6gPqPLSNWEd0kC/UgzcowqiX nHtw4jfoRUVY8i6XjX+tpnWwDVK72f0FYPD3wehc8T0sn9MREMUGoH1HZonCPAOpHWKl PjVg== X-Gm-Message-State: AMCzsaXtsPitW8r6BHVqv4EoyrZEpa9t/JkJtLbJvK9b+I1dLXC210zX /oje4JgHL3RPXLIWNdDQDqDoMA+jET3/pMvAq/+E1A== X-Google-Smtp-Source: AOwi7QCfua//qrcZa9HPxp/lXvCzBITFzYPIl3eaeYMU5b2AJbQl7x0u+x1X1Biymzsm2iJubJi0kLPX4yN4jUhVg0c= X-Received: by 10.55.161.200 with SMTP id k191mr2114112qke.158.1506823209859; Sat, 30 Sep 2017 19:00:09 -0700 (PDT) MIME-Version: 1.0 Sender: ismaelj@gmail.com Received: by 10.12.149.130 with HTTP; Sat, 30 Sep 2017 18:59:29 -0700 (PDT) In-Reply-To: References: From: Ismael Juma Date: Sun, 1 Oct 2017 02:59:29 +0100 X-Google-Sender-Auth: JnxcwEJWADZBuW5DWVUwCPv_KcM Message-ID: Subject: Re: How is CorrelationId used for matching request and response To: dev@kafka.apache.org Content-Type: multipart/alternative; boundary="94eb2c06f34029be3b055a729e95" archived-at: Sun, 01 Oct 2017 02:00:29 -0000 --94eb2c06f34029be3b055a729e95 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Haseeb, That is the point, the server should always send a response with the same correlation id as the request it has received. If there's a bug in the networking layer where a response is never sent back or there is reordering somewhere in the stack, then this will be identified by the client when the correlation id does not match. Does this help? Ismael On Sun, Oct 1, 2017 at 2:39 AM, Javed, Haseeb wrote: > Thanks all for reaching out. > > > > Ted - I am looking at the 0.11.0 release. Particularly here > https://github.com/apache/kafka/blob/0.11.0/clients/src/ > main/java/org/apache/kafka/common/requests/AbstractResponse.java > > In this release, the Server uses the following method in almost all cases > (ApiVersionResponses.unsupportedVersionSend(...) being the only exception= ) > > public Send toSend(String destination, RequestHeader requestHeader) { > return toSend(destination, requestHeader.apiVersion(), requestHeader. > toResponseHeader()); > } > > > Jay - I understand the purpose of correlationId but what I don't > understand is how the request/response matching logic is being implemente= d. > From the code, I see that server always uses the request header to genera= te > the response header so in effect both request and response headers end up > having the same correlationId. There seems to be no situation where > response and request could possible have different correlationIds. > main/java/org/apache/kafka/common/requests/AbstractResponse.java> > > > Haseeb > > ________________________________ > From: Jay Kreps > Sent: Saturday, September 30, 2017 11:43:30 PM > To: dev@kafka.apache.org > Subject: Re: How is CorrelationId used for matching request and response > > Yes the idea of the correlation id is to make it easier for the client to > match a particular response to the request it answers. Kafka=E2=80=99s pr= otocol > allows sending multiple requests without waiting for the response. In > theory you can just rely on ordering, but that can be a bit fragile if th= e > client has any kind of bug. So this id is an explicit check=E2=80=94a res= ponse with > id 42 is the answer to the request you sent with id 42. Hope that helps! > > -Jay > > On Fri, Sep 29, 2017 at 4:52 PM Ted Yu wrote: > > > Which release / version are you looking at ? > > In trunk branch, I only see one toSend(): > > > > protected Send toSend(String destination, ResponseHeader header, > short > > apiVersion) { > > > > return new NetworkSend(destination, serialize(apiVersion, > header)); > > > > On Fri, Sep 29, 2017 at 4:49 PM, Javed, Haseeb < > > javed.19@buckeyemail.osu.edu > > > wrote: > > > > > The Kafka protocol guide mentions that each request and response > contains > > > a correlationId which is a user-supplied integer to match requests an= d > > > corresponding responses. However, when I look at the code in the clas= s > > > AbstractResponse, we have a method defined as following: > > > > > > > > > public Send toSend(String destination, RequestHeader requestHeader) { > > > return toSend(destination, requestHeader.apiVersion(), > requestHeader. > > > toResponseHeader()); > > > } > > > > > > So basically we are just using the requestHeader to generate the > > > responseHeader so doesn't this pretty much guarantees that the > > > correlationId for the Request and the Response would always be the > same, > > or > > > am I missing something? > > > > > > > > > > > > --94eb2c06f34029be3b055a729e95--