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 C71F1200C25 for ; Fri, 24 Feb 2017 20:48:36 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id C5ACE160B69; Fri, 24 Feb 2017 19:48:36 +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 C9576160B62 for ; Fri, 24 Feb 2017 20:48:34 +0100 (CET) Received: (qmail 47230 invoked by uid 500); 24 Feb 2017 19:48:33 -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 47218 invoked by uid 99); 24 Feb 2017 19:48:33 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Feb 2017 19:48:33 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id DB0F01A0294 for ; Fri, 24 Feb 2017 19:48:32 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.98 X-Spam-Level: * X-Spam-Status: No, score=1.98 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=confluent-io.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id aGgntMshlIAq for ; Fri, 24 Feb 2017 19:48:23 +0000 (UTC) Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com [209.85.213.52]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id DFDF25F24C for ; Fri, 24 Feb 2017 19:48:22 +0000 (UTC) Received: by mail-vk0-f52.google.com with SMTP id r136so17440228vke.1 for ; Fri, 24 Feb 2017 11:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=confluent-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=TvB2cwMU9DZ1ynZ56tjdYAn+OaB9RFiFmWZHkq9t9qs=; b=elKXLUjgg/2gSJRxA3ghqqxyGPc6MfoGWz4VsRgkWk+D9RUzDNcRlWPB8HzMD56IHO LPzWxhimNLWnOJcT0XOhnxdOhsnRt2AZFVb3zdq+Wi8XtY612NBRMexHpxXTwe5WBqbf ImEXBKA9zM64g90XNeFJLCAkj4tLVJh8m5zATaVEO5neLi1wj2REWT0vloZR/JUHcKwC /+P0jUViafGNFA4nlJKwwMTRyRKHXek7szHdmZYO/kAKHtK+qF3RPE9VyYvmzGmdT1sB nqjFUPRFT1ooSx0noeH/SY92SZ+hEiu/InAiCpzs+JWB5/WK0Nok9DcPwtstQy/yJrS2 /Uaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=TvB2cwMU9DZ1ynZ56tjdYAn+OaB9RFiFmWZHkq9t9qs=; b=qpyA6P5GyA0XkG0rSKb4O1ROs3TMDBOXDBPcNIvfJGB6waUx2//yPCJCy7yn4e5eKu 3r8JcLG8uSzjFxhkRSraYRoF/Pq6TL0lznVbYpgygScxbgDaabkUYrE3NXpkZwR3DbBU WGOeefOu/AKME1k1fhMuX7iNJ0BWxJRNwyfKOHtqvkPuMgRkkvdNcRvTi+P0dao5QdUu JquReEDoxniSNFXvup1Azd7mK4Hb4CRvi7oxDBXEDX/xIc4PS8k0ybJciNxJJ0xQxhby LyfuQIW2mIKHr9mwwR2r28AHR1519JmNLhE9qdWqHy+9Mh9HlBKNwCFg3sDED7Skbh9b /D2A== X-Gm-Message-State: AMke39lPBVugZ9SAmiByFXTL00jy5HPacjNBQKSQONyAtDZM4gkkRlBPnBgL24r5o9gYAaVvHMzIyTgw64lBEqLV X-Received: by 10.31.196.194 with SMTP id u185mr1844280vkf.71.1487965695356; Fri, 24 Feb 2017 11:48:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.151.131 with HTTP; Fri, 24 Feb 2017 11:48:14 -0800 (PST) In-Reply-To: References: <9B8EAB4A-4260-4507-873D-9FDC3EF37AFC@ig.com> <99FD60C5-7D0E-4976-B079-3C15C9A9D923@ig.com> <16DF1834-DE93-4B73-839B-8BF3C9429588@ig.com> From: Jason Gustafson Date: Fri, 24 Feb 2017 11:48:14 -0800 Message-ID: Subject: Re: [VOTE] KIP-98: Exactly Once Delivery and Transactional Messaging To: dev@kafka.apache.org Content-Type: multipart/alternative; boundary=001a114e665eb5d30705494c02a2 archived-at: Fri, 24 Feb 2017 19:48:37 -0000 --001a114e665eb5d30705494c02a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 from me (duh). Thanks to all the reviewers. The KIP has been much improved because of it! -Jason On Wed, Feb 22, 2017 at 8:48 AM, Ismael Juma wrote: > Great work on the proposal and iterating on it based on community feedbac= k. > As Jun (and others) said, it's likely that minor changes will happen as t= he > PR is reviewed and additional testing takes place since this is a > significant change. > > I am +1 (binding) on the proposal without optional keys and values to kee= p > things consistent. If we show during performance testing that this is > worthwhile, we can update the proposal. > > Ismael > > On Tue, Feb 21, 2017 at 6:23 PM, Jun Rao wrote: > > > It seems that it's simpler and more consistent to avoid optional keys a= nd > > values. Not sure if it's worth squeezing every byte at the expense of > > additional complexity. Other than that, +1 from me. > > > > Also, since this is a large KIP, minor changes may arise as we start th= e > > implementation. It would be good if we can keep the community posted of > > those changes, if any. > > > > Thanks, > > > > Jun > > > > On Tue, Feb 21, 2017 at 4:33 PM, Michael Pearce > > wrote: > > > > > If the argument and objective within this KIP is to keep the overhead > of > > > the protocol as small as possible and remove redundancy, and every by= te > > is > > > being counted and the introduction of varInts, then it would make sen= se > > to > > > use attributes to me. > > > > > > > > > On 22/02/2017, 00:14, "Jason Gustafson" wrote: > > > > > > Done. I've left the key and value as optional since we may not ha= ve > > > reached > > > consensus on whether to use attributes or not. Perhaps we should > just > > > keep > > > it simple and not do it? The benefit seems small. > > > > > > -Jason > > > > > > On Tue, Feb 21, 2017 at 4:05 PM, Michael Pearce < > > Michael.Pearce@ig.com > > > > > > > wrote: > > > > > > > Ok, no worries, can you add it back ValueLen on this KIP, and > > update > > > the > > > > doc, then we can work from that =E2=98=BA > > > > > > > > Cheers > > > > Mike > > > > > > > > On 22/02/2017, 00:02, "Jason Gustafson" > > wrote: > > > > > > > > I feel it was a little odd to leave out the value length > > anyway, > > > so I > > > > would > > > > rather add it back and put headers at the end. This is more > > > consistent > > > > with > > > > the rest of the Kafka protocol. > > > > > > > > -Jason > > > > > > > > On Tue, Feb 21, 2017 at 3:58 PM, Michael Pearce < > > > Michael.Pearce@ig.com > > > > > > > > > wrote: > > > > > > > > > Or we keep as is (valuelen removed), and headers are adde= d > > with > > > > headers > > > > > length.. > > > > > > > > > > On 21/02/2017, 23:38, "Apurva Mehta" > > > wrote: > > > > > > > > > > Right now, we don't need the value length: since it i= s > > the > > > last > > > > item > > > > > in the > > > > > message, and we have the message length, we can deduc= e > > the > > > value > > > > > length. > > > > > However, if we are adding record headers to the end, = we > > > would > > > > need to > > > > > introduce the value length along with that change. > > > > > > > > > > On Tue, Feb 21, 2017 at 3:34 PM, Michael Pearce < > > > > Michael.Pearce@ig.com > > > > > > > > > > > wrote: > > > > > > > > > > > It seems I cannot add comment on the doc. > > > > > > > > > > > > In the section around the message protocol. > > > > > > > > > > > > It has stated: > > > > > > > > > > > > Message =3D> > > > > > > Length =3D> uintVar > > > > > > Attributes =3D> int8 > > > > > > TimestampDelta =3D> intVar > > > > > > OffsetDelta =3D> uintVar > > > > > > KeyLen =3D> uintVar [OPTIONAL] > > > > > > Key =3D> data [OPTIONAL] > > > > > > Value =3D> data [OPTIONAL] > > > > > > > > > > > > Should it not be: (added missing value len) > > > > > > > > > > > > Message =3D> > > > > > > Length =3D> uintVar > > > > > > Attributes =3D> int8 > > > > > > TimestampDelta =3D> intVar > > > > > > OffsetDelta =3D> uintVar > > > > > > KeyLen =3D> uintVar [OPTIONAL] > > > > > > Key =3D> data [OPTIONAL] > > > > > > ValueLen =3D> uintVar [OPTIONAL] > > > > > > Value =3D> data [OPTIONAL] > > > > > > > > > > > > > > > > > > > > > > > > On 21/02/2017, 23:07, "Joel Koshy" < > > jjkoshy.w@gmail.com> > > > > wrote: > > > > > > > > > > > > I left a couple of comments/questions directly = on > > the > > > > google-doc > > > > > > > > > > > GjUGtdXJK94XGsEIK7CP1SnQGdp2eF0wSw9ra8> > > > > > > - I found it much more tractable for a proposal > of > > > this > > > > size to > > > > > > discuss in > > > > > > context within the doc. The permissions on the > doc > > > don't > > > > let > > > > > everyone > > > > > > view > > > > > > comments, so if there are any material changes > that > > > come > > > > out of > > > > > the > > > > > > discussions in those comment threads we can > > > summarize here. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Joel > > > > > > > > > > > > On Mon, Feb 20, 2017 at 4:08 PM, Becket Qin < > > > > > becket.qin@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Thanks for the explanation, Guozhang. That > makes > > > sense. > > > > > > > > > > > > > > On Sun, Feb 19, 2017 at 7:28 PM, Guozhang Wan= g > < > > > > > wangguoz@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > > Thanks Becket. > > > > > > > > > > > > > > > > Actually sequence is associated with a > message, > > > not a > > > > > message set. > > > > > > For > > > > > > > > example if a message set sent by producer > > > contains 100 > > > > > messages, > > > > > > and the > > > > > > > > first message's sequence is 5, then the las= t > > > message's > > > > > sequence > > > > > > number > > > > > > > > would be 104, and the next message set's > first > > > > sequence is > > > > > > expected to be > > > > > > > > 105. > > > > > > > > > > > > > > > > > > > > > > > > Guozhang > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Feb 19, 2017 at 4:48 PM, Becket Qin= < > > > > > becket.qin@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > > +1. Thanks for the great work on the KIP! > > > > > > > > > > > > > > > > > > I have only one minor question, in the wi= ki > > > (and the > > > > doc) > > > > > the new > > > > > > > message > > > > > > > > > set format has a "FirstSequence" field, > > should > > > it > > > > just be > > > > > > "Sequence" if > > > > > > > > the > > > > > > > > > sequence is always associated with a > message > > > set? > > > > > > > > > > > > > > > > > > On Fri, Feb 17, 2017 at 3:28 AM, Michael > > > Pearce < > > > > > > Michael.Pearce@ig.com > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > +0 > > > > > > > > > > > > > > > > > > > > I think need some unified agreement on > the > > > VarInts. > > > > > > > > > > > > > > > > > > > > Would this also change in all other > area=E2=80=99s > > > of the > > > > > protocol, > > > > > > e.g. > > > > > > > value > > > > > > > > > and > > > > > > > > > > key length in message protocol, to keep > > this > > > > uniform > > > > > across all > > > > > > > > protocols > > > > > > > > > > going forwards? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 17/02/2017, 00:23, "Apurva Mehta" < > > > > > apurva@confluent.io> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Jun, > > > > > > > > > > > > > > > > > > > > Thanks for the reply. Comments > inline. > > > > > > > > > > > > > > > > > > > > On Thu, Feb 16, 2017 at 2:29 PM, Ju= n > > Rao > > > < > > > > > jun@confluent.io > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Hi, Apurva, > > > > > > > > > > > > > > > > > > > > > > Thanks for the reply. A couple of > > > comment > > > > below. > > > > > > > > > > > > > > > > > > > > > > On Wed, Feb 15, 2017 at 9:45 PM, > > Apurva > > > > Mehta < > > > > > > > > apurva@confluent.io > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi Jun, > > > > > > > > > > > > > > > > > > > > > > > > Answers inline: > > > > > > > > > > > > > > > > > > > > > > > > 210. Pid snapshots: Is the numb= er > > of > > > pid > > > > snapshot > > > > > > > configurable > > > > > > > > or > > > > > > > > > > > hardcoded > > > > > > > > > > > > > with 2? When do we decide to > roll > > > a new > > > > > snapshot? > > > > > > Based on > > > > > > > > > time, > > > > > > > > > > byte, > > > > > > > > > > > or > > > > > > > > > > > > > offset? Is that configurable > too? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > When a replica becomes a follower= , > we > > > do a > > > > bit log > > > > > > truncation. > > > > > > > > > > Having an > > > > > > > > > > > older snapshot allows us to recov= er > > the > > > > > PID->sequence > > > > > > mapping > > > > > > > > much > > > > > > > > > > quicker > > > > > > > > > > > than rescanning the whole log. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is a good point. I have update= d > > the > > > doc > > > > with a > > > > > more > > > > > > detailed > > > > > > > > > > proposal. > > > > > > > > > > Essentially, snapshots will be > created > > > on a > > > > periodic > > > > > > basis. A > > > > > > > > > > reasonable > > > > > > > > > > period would be every 30 or 60 > seconds. > > > We > > > > will keep > > > > > at > > > > > > most 2 > > > > > > > > copies > > > > > > > > > > of > > > > > > > > > > the snapshot file. With this setup, > we > > > would > > > > have to > > > > > > replay at > > > > > > > most > > > > > > > > > 60 > > > > > > > > > > or > > > > > > > > > > 120 seconds of the log in the event > of > > > log > > > > truncation > > > > > > during > > > > > > > leader > > > > > > > > > > failover. > > > > > > > > > > > > > > > > > > > > If we need to make any of this > > > configurable, > > > > we can > > > > > expose > > > > > > a > > > > > > > config > > > > > > > > > in > > > > > > > > > > the > > > > > > > > > > future. It would be easier to add a > > > config we > > > > need > > > > > than > > > > > > remove > > > > > > > one > > > > > > > > > with > > > > > > > > > > marginal utility. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 211. I am wondering if we > should > > > store > > > > > > ExpirationTime in > > > > > > > the > > > > > > > > > > producer > > > > > > > > > > > > > transactionalId mapping messa= ge > > as > > > we do > > > > in the > > > > > > producer > > > > > > > > > > transaction > > > > > > > > > > > > status > > > > > > > > > > > > > message. If a producer only > calls > > > > > > initTransactions(), but > > > > > > > > never > > > > > > > > > > > publishes > > > > > > > > > > > > > any data, we still want to be > > able > > > to > > > > expire > > > > > and > > > > > > remove the > > > > > > > > > > producer > > > > > > > > > > > > > transactionalId mapping > message. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Actually, the document was > > > inaccurate. The > > > > > > transactionalId > > > > > > > will > > > > > > > > > be > > > > > > > > > > > expired > > > > > > > > > > > > only if there is no active > > > transaction, > > > > and the > > > > > age of > > > > > > the > > > > > > > last > > > > > > > > > > > transaction > > > > > > > > > > > > with that transactionalId is > older > > > than the > > > > > > transactioanlId > > > > > > > > > > expiration > > > > > > > > > > > > time. With these semantics, > storing > > > the > > > > > expiration > > > > > > time in > > > > > > > the > > > > > > > > > > > > transactionalId mapping message > > > won't be > > > > useful, > > > > > since > > > > > > the > > > > > > > > > > expiration > > > > > > > > > > > time > > > > > > > > > > > > is a moving target based on > > > transaction > > > > activity. > > > > > > > > > > > > > > > > > > > > > > > > I have updated the doc with a > > > > clarification. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Currently, the producer > > transactionalId > > > > mapping > > > > > message > > > > > > doesn't > > > > > > > > > carry > > > > > > > > > > > ExpirationTime, but the producer > > > transaction > > > > status > > > > > > message > > > > > > > does. > > > > > > > > > > It would > > > > > > > > > > > be useful if they are consistent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You are right. The document has bee= n > > > updated to > > > > > remove the > > > > > > > > > > ExpirationTime > > > > > > > > > > from the transaction status message= s > as > > > well. > > > > Any > > > > > utility > > > > > > for > > > > > > > this > > > > > > > > > > field > > > > > > > > > > can be achieved by using the > timestamp > > > of the > > > > message > > > > > > itself > > > > > > > along > > > > > > > > > with > > > > > > > > > > another expiration time (like > > > transactionalId > > > > > expiration > > > > > > time, > > > > > > > > > > transaction > > > > > > > > > > expiration time, etc.). > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Apurva > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The information contained in this email > is > > > strictly > > > > > > confidential and > > > > > > > > for > > > > > > > > > > the use of the addressee only, unless > > > otherwise > > > > > indicated. If > > > > > > you are > > > > > > > > not > > > > > > > > > > the intended recipient, please do not > read, > > > copy, > > > > use or > > > > > > disclose to > > > > > > > > > others > > > > > > > > > > this message or any attachment. Please > also > > > notify > > > > the > > > > > sender > > > > > > by > > > > > > > > replying > > > > > > > > > > to this email or by telephone (+44(020 > 7896 > > > 0011) > > > > and > > > > > then > > > > > > delete the > > > > > > > > > email > > > > > > > > > > and any copies of it. Opinions, > conclusion > > > (etc) > > > > that do > > > > > not > > > > > > relate > > > > > > > to > > > > > > > > > the > > > > > > > > > > official business of this company shall > be > > > > understood as > > > > > > neither > > > > > > > given > > > > > > > > > nor > > > > > > > > > > endorsed by it. IG is a trading name of > IG > > > Markets > > > > > Limited (a > > > > > > company > > > > > > > > > > registered in England and Wales, compan= y > > > number > > > > > 04008957) and > > > > > > IG > > > > > > > Index > > > > > > > > > > Limited (a company registered in Englan= d > > and > > > Wales, > > > > > company > > > > > > number > > > > > > > > > > 01190902). Registered address at Cannon > > > Bridge > > > > House, 25 > > > > > > Dowgate > > > > > > > Hill, > > > > > > > > > > London EC4R 2YA. Both IG Markets Limite= d > > > (register > > > > number > > > > > > 195355) and > > > > > > > > IG > > > > > > > > > > Index Limited (register number 114059) > are > > > > authorised and > > > > > > regulated > > > > > > > by > > > > > > > > > the > > > > > > > > > > Financial Conduct Authority. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > -- Guozhang > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The information contained in this email is strictly > > > > confidential and > > > > > for > > > > > > the use of the addressee only, unless otherwise > > > indicated. If > > > > you > > > > > are not > > > > > > the intended recipient, please do not read, copy, u= se > > or > > > > disclose to > > > > > others > > > > > > this message or any attachment. Please also notify > the > > > sender > > > > by > > > > > replying > > > > > > to this email or by telephone (+44(020 7896 0011) a= nd > > > then > > > > delete > > > > > the email > > > > > > and any copies of it. Opinions, conclusion (etc) th= at > > do > > > not > > > > relate > > > > > to the > > > > > > official business of this company shall be understo= od > > as > > > > neither > > > > > given nor > > > > > > endorsed by it. IG is a trading name of IG Markets > > > Limited (a > > > > company > > > > > > registered in England and Wales, company number > > > 04008957) and > > > > IG > > > > > Index > > > > > > Limited (a company registered in England and Wales, > > > company > > > > number > > > > > > 01190902). Registered address at Cannon Bridge Hous= e, > > 25 > > > > Dowgate > > > > > Hill, > > > > > > London EC4R 2YA. Both IG Markets Limited (register > > number > > > > 195355) > > > > > and IG > > > > > > Index Limited (register number 114059) are authoris= ed > > and > > > > regulated > > > > > by the > > > > > > Financial Conduct Authority. > > > > > > > > > > > > > > > > > > > > > The information contained in this email is strictly > > > confidential and > > > > for > > > > > the use of the addressee only, unless otherwise indicated= . > If > > > you > > > > are not > > > > > the intended recipient, please do not read, copy, use or > > > disclose to > > > > others > > > > > this message or any attachment. Please also notify the > sender > > > by > > > > replying > > > > > to this email or by telephone (+44(020 7896 0011) and the= n > > > delete > > > > the email > > > > > and any copies of it. Opinions, conclusion (etc) that do > not > > > relate > > > > to the > > > > > official business of this company shall be understood as > > > neither > > > > given nor > > > > > endorsed by it. IG is a trading name of IG Markets Limite= d > (a > > > company > > > > > registered in England and Wales, company number 04008957) > and > > > IG > > > > Index > > > > > Limited (a company registered in England and Wales, compa= ny > > > number > > > > > 01190902). Registered address at Cannon Bridge House, 25 > > > Dowgate > > > > Hill, > > > > > London EC4R 2YA. Both IG Markets Limited (register number > > > 195355) > > > > and IG > > > > > Index Limited (register number 114059) are authorised and > > > regulated > > > > by the > > > > > Financial Conduct Authority. > > > > > > > > > > > > > > > > > The information contained in this email is strictly confidentia= l > > and > > > for > > > > the use of the addressee only, unless otherwise indicated. If y= ou > > > are not > > > > the intended recipient, please do not read, copy, use or disclo= se > > to > > > others > > > > this message or any attachment. Please also notify the sender b= y > > > replying > > > > to this email or by telephone (+44(020 7896 0011) and then dele= te > > > the email > > > > and any copies of it. Opinions, conclusion (etc) that do not > relate > > > to the > > > > official business of this company shall be understood as neithe= r > > > given nor > > > > endorsed by it. IG is a trading name of IG Markets Limited (a > > company > > > > registered in England and Wales, company number 04008957) and I= G > > > Index > > > > Limited (a company registered in England and Wales, company > number > > > > 01190902). Registered address at Cannon Bridge House, 25 Dowgat= e > > > Hill, > > > > London EC4R 2YA. Both IG Markets Limited (register number 19535= 5) > > > and IG > > > > Index Limited (register number 114059) are authorised and > regulated > > > by the > > > > Financial Conduct Authority. > > > > > > > > > > > > > The information contained in this email is strictly confidential and > for > > > the use of the addressee only, unless otherwise indicated. If you are > not > > > the intended recipient, please do not read, copy, use or disclose to > > others > > > this message or any attachment. Please also notify the sender by > replying > > > to this email or by telephone (+44(020 7896 0011) and then delete the > > email > > > and any copies of it. Opinions, conclusion (etc) that do not relate t= o > > the > > > official business of this company shall be understood as neither give= n > > nor > > > endorsed by it. IG is a trading name of IG Markets Limited (a company > > > registered in England and Wales, company number 04008957) and IG Inde= x > > > Limited (a company registered in England and Wales, company number > > > 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill= , > > > London EC4R 2YA. Both IG Markets Limited (register number 195355) and > IG > > > Index Limited (register number 114059) are authorised and regulated b= y > > the > > > Financial Conduct Authority. > > > > > > --001a114e665eb5d30705494c02a2--