So on mutable, and headers just at message level seems we're all agreed then.
On Radai's comments.
1) agreed - kip updated.
2) Now i totally get the nasty code having this would create as noted by your
example. And obviously we want an API which means boiler plate code and most
common interaction is supported.
not sure what we should do here, so via protocol and as per previous
discussion, it was compromised to support multiple values for a key. I believe
this was Gwen's request, and compromised accepted.
Now in Guava multimap interface it has "Collection<V> get(K key)", there is no
single "V get(K key)" styled method.
org.apache.collections varient is the same.
Two ideas i had to address this would be:
A) add two additional methods something
/**
* Returns the first header for a key if present, else returns null.
*/
Header first(K key)
/**
* Replaces an existing header where the key and value for the old equal an
existing header.
*/
replace(Header old, Header new)
B) Change the previous agreement to support multiple values for a key (aka
multimap), and if someone wants a collection for their value they should code
this in their value byte[].
My personal opinion is I think option B is a lot cleaner and will make for a
cleaner interface. But it will mean negating on a previous discussion
agreement. Would everyone be happy with that? If not Radai is option A ok with
you? Or any other ideas?
Cheers
Mike
________________________________________
From: Jason Gustafson <ja...@confluent.io>
Sent: Tuesday, February 28, 2017 1:38 AM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-82 - Add Record Headers
If I understand correctly, the suggestion is to let headers be mutable on
the producer side basically until after they've passed through the
interceptors. That sounds like a reasonable compromise to me.
@Becket
3. It might be useful to have headers at MessageSet level as well so we can
> avoid decompression in some cases. But given this KIP is already
> complicated, I would rather leave this out of the scope and address that
> later when needed, e.g. after having batch level interceptors.
Yeah, I had the same thought. I was considering factoring the map of header
names to generated integer ids into the message set and only using the
integer ids in the individual messages. It's a bit complex though, so I
agree it's probably best left out. I guess for now if users have a lot of
headers, they should just enable compression.
-Jason
On Mon, Feb 27, 2017 at 1:16 PM, radai <radai.rosenbl...@gmail.com> wrote:
> a few comments on the KIP as it is now:
>
> 1. instead of add(Header) + add (Iterable<Header>) i suggest we use add +
> addAll. this is more in line with how java collections work and may
> therefor be more intuitive
>
> 2. common user code dealing with headers will want get("someKey") /
> set("someKey"), or equivalent. code using multiple headers under the same
> key will be rare, and code iterating over all headers would be even rarer
> (probably only for kafka-connect equivalent use cases, really). as the API
> looks right now, the most common and trivial cases will be gnarly:
> get("someKey") -->
> record.headers().headers("someKey").iterator().next().value(). and this is
> before i start talking about how nulls/emptys are handled.
> replace("someKey") -->
> record.headers().remove(record.headers().headers("someKey"));
> record.headers().append(new Header("someKey", value));
>
> this is why i think we should start with get()/set() which are single-value
> map semantics (so set overwrites), then add getAll() (multi-map), append()
> etc on top. make the common case pretty.
>
> On Sun, Feb 26, 2017 at 2:01 AM, Michael Pearce <michael.pea...@ig.com>
> wrote:
>
> > Hi Becket,
> >
> > On 1)
> >
> > Yes truly we wanted mutable headers also. Alas we couldn't think of a
> > solution would address Jason's point around, once a record is sent it
> > shouldn't be possible to mutate it, for cases where you send twice the
> same
> > record.
> >
> > Thank you so much for your solution i think this will work very nicely :)
> >
> > Agreed we only need to do mutable to immutable conversion
> >
> > I think you solution with a ".close()" taken from else where in the kafka
> > protocol where mutability is existent is a great solution, and happy
> middle
> > ground.
> >
> > @Jason you agree, this resolves your concerns if we had mutable headers?
> >
> >
> > On 2)
> > Agreed, this was only added as i couldn't think of a solution to that
> > would address Jason's concern, but really didn't want to force end users
> to
> > constantly write ugly boiler plate code. If we agree on you solution for
> 1,
> > very happy to remove these.
> >
> > On 3)
> > I also would like to keep the scope of this KIP limited to Message
> Headers
> > for now, else we run the risk of not getting even these delivered for
> next
> > release and we're almost now there on getting this KIP to the state
> > everyone is happy. As you note address that later if theres the need.
> >
> >
> > Ill leave it 24hrs and update the kip if no strong objections based on
> > your solution for 1 & 2.
> >
> > Cheers
> > Mike
> >
> > __________ ______________________________
> > From: Becket Qin <becket....@gmail.com>
> > Sent: Saturday, February 25, 2017 10:33 PM
> > To: dev@kafka.apache.org
> > Subject: Re: [DISCUSS] KIP-82 - Add Record Headers
> >
> > Hey Michael,
> >
> > Thanks for the KIP. It looks good overall and it looks we only have few
> > things to agree on.
> >
> > 1. Regarding the mutability.
> >
> > I think it would be a big convenience to have headers mutable during
> > certain stage in the message life cycle for the use cases you mentioned.
> I
> > agree there is a material benefit especially given that we may have to
> > modify the headers for each message.
> >
> > That said, I also think it is fair to say that in the producer, in order
> to
> > guarantee the correctness of the entire logic, it is necessary that at
> some
> > point we need to make producer record immutable. For example we probably
> > don't want to see that users accidentally updated the headers when the
> > producer is doing the serialization or compression.
> >
> > Given that, would it be possible to make Headers to be able to switch
> from
> > mutable to immutable? We have done this for the Batch in the producer.
> For
> > example, initially the headers are mutable, but after it has gone through
> > all the interceptors, we can call Headers.close() to make it immutable
> > afterwards.
> >
> > On the consumer side, we can probably always leave the the ConsumerRecord
> > mutable because after we give the messages to the users, Kafka consumer
> > itself does not care about whether the headers are modified or not
> anymore.
> >
> > So far I think we only need to do the mutable to immutable conversion. If
> > there are use case require immutable to mutable conversion, we may need
> > something more than a closable.
> >
> > 2. If we agree on what mentioned above, I think it probably makes sense
> to
> > put the addHeaders()/removeHeaders() methods into Headers class and just
> > leave the headers() method in ProducerRecord and ConsumerRecord.
> >
> > 3. It might be useful to have headers at MessageSet level as well so we
> can
> > avoid decompression in some cases. But given this KIP is already
> > complicated, I would rather leave this out of the scope and address that
> > later when needed, e.g. after having batch level interceptors.
> >
> > Thanks,
> >
> > Jiangjie (Becket) Qin
> >
> > On Fri, Feb 24, 2017 at 3:56 PM, Michael Pearce <michael.pea...@ig.com>
> > wrote:
> >
> > > KIP updated in response to the below comments:
> > >
> > > > 1. Is the intent of `Headers.filter` to include or exclude the
> > > headers
> > > > matching the key? Can you add a javadoc to clarify?
> > > > 2. The KIP mentions that we will introduce V4 of FetchRequest
> > > and V4 of
> > > > ProduceRequest. Can you change this to say that the changes
> > will
> > > > piggyback
> > > > onto V3 of ProduceRequest and V4 of FetchRequest which were
> > > introduced
> > > > in
> > > > KIP-98?
> > >
> > >
> > >
> > >
> > > On 24/02/2017, 23:20, "Michael Pearce" <michael.pea...@ig.com> wrote:
> > >
> > > We’re trying to make an eco-system for people to be able to use
> > > headers, I think we want to ensure some least common features are
> > supported
> > > and not limited.
> > >
> > >
> > > Some examples we have already.
> > >
> > > On consume interceptors a security interceptor may need to take the
> > > current header, decrypt the data and replace the token with the next
> > token
> > > for the next processing, in case of a single decryption token being one
> > > time use only.
> > >
> > > On produce it could be the interceptors add some values in the
> clear
> > > from the systems that supply them, but later a security header
> > interceptor
> > > needs to encrypt some headers, as such needs to replace the current
> value
> > > with new one.
> > >
> > > I note Radai already requested this in the thread, I assume he has
> > > some use case also. S
> > >
> > > Simple add / remove is a least common feature.
> > >
> > > Rgds,
> > > Mike
> > >
> > >
> > > On 24/02/2017, 23:00, "Jason Gustafson" <ja...@confluent.io>
> wrote:
> > >
> > > Hey Michael,
> > >
> > > I'm not strongly opposed to them; I just don't see a lot of
> > > benefit. One
> > > thing it would be good to understand is why a consumer
> > interceptor
> > > would
> > > need to add headers and why a producer interceptor would need
> to
> > > remove
> > > them. Maybe we only need the common cases?
> > >
> > > Thanks,
> > > Jason
> > >
> > > On Fri, Feb 24, 2017 at 2:22 PM, Michael Pearce <
> > > michael.pea...@ig.com>
> > > wrote:
> > >
> > > > Hi Jason,
> > > >
> > > > Sorry I thought this was the agreed compromise to provide an
> > api
> > > that
> > > > avoid boiler plate in return for immutabilty.
> > > >
> > > > If not then mutability will be needed as a goal is to have a
> > > single clean
> > > > method call to append/remove a header.
> > > >
> > > > Cheers
> > > > Mike
> > > >
> > > > On 24/02/2017, 22:15, "Jason Gustafson" <ja...@confluent.io>
> > > wrote:
> > > >
> > > > Hey Michael,
> > > >
> > > > I didn't actually comment on the new methods for
> > > ProducerRecord and
> > > > ConsumerRecord. If they only save some boilerplate, I'd
> > just
> > > as well
> > > > not
> > > > have them.
> > > >
> > > > Also a couple minor comments:
> > > >
> > > > 1. Is the intent of `Headers.filter` to include or
> exclude
> > > the headers
> > > > matching the key? Can you add a javadoc to clarify?
> > > > 2. The KIP mentions that we will introduce V4 of
> > > FetchRequest and V4 of
> > > > ProduceRequest. Can you change this to say that the
> changes
> > > will
> > > > piggyback
> > > > onto V3 of ProduceRequest and V4 of FetchRequest which
> were
> > > introduced
> > > > in
> > > > KIP-98?
> > > >
> > > > The rest of the KIP looks good to me.
> > > >
> > > > -Jason
> > > >
> > > > On Fri, Feb 24, 2017 at 12:46 PM, Michael Pearce <
> > > > michael.pea...@ig.com>
> > > > wrote:
> > > >
> > > > > I’ve added the methods on the ProducerRecord that will
> > > return a new
> > > > > instance of ProducerRecord with modified headers.
> > > > >
> > > > > On 24/02/2017, 19:22, "Michael Pearce" <
> > > michael.pea...@ig.com>
> > > > wrote:
> > > > >
> > > > > Pattern.compile is expensive, and even if cached
> > > String.equals is
> > > > > faster than matched. also if we end up with an internal
> > > map in
> > > > future for
> > > > > performance it will be easier to be by key.
> > > > >
> > > > > As all that's needed is to get header by key.
> > > > >
> > > > > With like the other arguements of let's implement
> > > simple and
> > > > then we
> > > > > can always add pattern later as well if it's found it's
> > > needed. (As
> > > > noted
> > > > > it's easier to add methods than to take away)
> > > > >
> > > > > Great I'll update kip with extra methods on
> > > producerecord and a
> > > > note
> > > > > that new objects are returned by method calls.
> > > > >
> > > > >
> > > > >
> > > > > Sent using OWA for iPhone
> > > > > ________________________________________
> > > > > From: Jason Gustafson <ja...@confluent.io>
> > > > > Sent: Friday, February 24, 2017 6:51:45 PM
> > > > > To: dev@kafka.apache.org
> > > > > Subject: Re: [DISCUSS] KIP-82 - Add Record Headers
> > > > >
> > > > > The APIs in the current KIP look good to me. Just a
> > > couple
> > > > questions:
> > > > > why
> > > > > does filter not return Headers? Also would it be
> > > useful if the
> > > > key is a
> > > > > regex?
> > > > >
> > > > > On the point of immutability.. One option might be
> to
> > > use a
> > > > mutable
> > > > > object
> > > > > only when passing the headers through the
> interceptor
> > > chain. I
> > > > think as
> > > > > long as we resort to mutability only when clear
> > > performance
> > > > results
> > > > > show
> > > > > that it is worthwhile, I am satisfied. As Ismael
> > > noted, for
> > > > common
> > > > > scenarios it is possible to get reasonable
> > performance
> > > with
> > > > immutable
> > > > > objects.
> > > > >
> > > > > -Jason
> > > > >
> > > > > On Fri, Feb 24, 2017 at 8:48 AM, Michael Pearce <
> > > > michael.pea...@ig.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi
> > > > > >
> > > > > > On 1, How can you guarantee two separate
> > > implemented clients
> > > > would
> > > > > add
> > > > > > the headers in the same order we are not
> specifying
> > > an order
> > > > at the
> > > > > > protocol level (nor should we) with regards to
> > keyA
> > > being
> > > > ordered
> > > > > before
> > > > > > keyB? We shouldn’t be expecting keyA to be always
> > > set before
> > > > keyB.
> > > > > >
> > > > > > On 2, I believe we have changed the naming based
> on
> > > feedback
> > > > from
> > > > > Jason
> > > > > > already, e.g. we don’t have “get” method that
> > > inferred O(1)
> > > > > performance,
> > > > > > like wise nor “put” but we have an “append”
> > > > > >
> > > > > > On 3, in the KafkaProducer, I think we have
> > > mutability
> > > > already, the
> > > > > value
> > > > > > for time is changed if it is null, at the point
> of
> > > send:
> > > > > > “
> > > > > > long timestamp = record.timestamp()
> ==
> > > null ?
> > > > > > time.milliseconds() : record.timestamp();
> > > > > > “
> > > > > >
> > > > > > As such the timestamp is already mutable, so
> what’s
> > > the
> > > > difference
> > > > > here,
> > > > > > we already have some mixed semantics. On
> timestamp.
> > > > > > e.g. currently if I send to records with
> timestamp
> > > not set,
> > > > the wire
> > > > > > binary sent the value for the timestamp would be
> > > different, as
> > > > such
> > > > > we have
> > > > > > mutation for the same record.
> > > > > >
> > > > > > On 4, I think we should not expect not 1 or 2
> > > headers, but
> > > > infact
> > > > > 10’s of
> > > > > > headers. This is the concern on immutable
> headers,
> > > whilst the
> > > > append
> > > > > > self-reference works nicely, what if someone
> needs
> > > to remove a
> > > > > header?
> > > > > >
> > > > > > Trying to get this moving:
> > > > > >
> > > > > > If we really wanted Immutable Headers and
> > > essentially you guys
> > > > wont
> > > > > give
> > > > > > +1 for it without.
> > > > > >
> > > > > > Whats the feeling for adding methods to
> > > ProducerRecord that
> > > > does the
> > > > > > boiler plate code or creating a new
> ProducerRecord
> > > with the
> > > > altered
> > > > > new
> > > > > > headers (appended or removed) inside. E.g.
> > > > > >
> > > > > > ProducerRecord {
> > > > > >
> > > > > >
> > > > > > ProducerRecord append(Iterable<Headers>
> > > headersToAppend){
> > > > > > return new ProducerRecord(key, value,
> > > headers.append(
> > > > > headersToAppend),
> > > > > > ….)
> > > > > > }
> > > > > >
> > > > > > ProducerRecord remove(Iterable<Headers>
> > > headersToAppend){
> > > > > > return new ProducerRecord(key, value,
> > > headers.remove(
> > > > > headersToAppend),
> > > > > > ….)
> > > > > > }
> > > > > >
> > > > > > }
> > > > > >
> > > > > > Were the headers methods actually returns new
> > > objects, and the
> > > > > producer
> > > > > > records methods create a new producer record with
> > > all the
> > > > current
> > > > > values,
> > > > > > but with the new modified headers.
> > > > > >
> > > > > > Then interceptors / code return this new object?
> > > > > >
> > > > > >
> > > > > > Cheers
> > > > > > Mike
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 24/02/2017, 16:02, "isma...@gmail.com on
> behalf
> > > of Ismael
> > > > Juma" <
> > > > > > isma...@gmail.com on behalf of ism...@juma.me.uk
> >
> > > wrote:
> > > > > >
> > > > > > Hi Michael,
> > > > > >
> > > > > > Did you mean that you were happy to
> compromise
> > > to keep it
> > > > > mutable or
> > > > > > immutable? You wrote the former, but it
> sounded
> > > from the
> > > > > sentence that
> > > > > > it
> > > > > > could have been a typo. So, my thoughts on
> this
> > > is that
> > > > there
> > > > > are a few
> > > > > > things to take into account:
> > > > > >
> > > > > > 1. Semantics
> > > > > > 2. Simplicity of use (the common operations
> > > should be easy
> > > > to do)
> > > > > > 3. If it's easy to reason about and safe
> > > (immutability
> > > > helps
> > > > > with this)
> > > > > > 4. Efficiency (both memory and CPU usage)
> > > > > >
> > > > > > Regarding 1, I think it would be good to be
> > very
> > > clear
> > > > about the
> > > > > > guarantees
> > > > > > that we are providing. It seems that we are
> > > saying that
> > > > keys are
> > > > > > unordered,
> > > > > > but what about the case where there are
> > multiple
> > > values
> > > > for the
> > > > > same
> > > > > > key?
> > > > > > It seems that for some use cases (e.g.
> > lineage),
> > > it may be
> > > > > useful to
> > > > > > add
> > > > > > values to the same key while preserving the
> > > order.
> > > > > >
> > > > > > Regarding 2, I agree that it's useful to have
> > > methods in
> > > > > `Headers` for
> > > > > > the
> > > > > > very common use cases although we have to be
> > > careful with
> > > > the
> > > > > naming to
> > > > > > avoid giving the wrong impression. Also, when
> > it
> > > comes to
> > > > > `Map.Entry`,
> > > > > > I
> > > > > > think I'd prefer a `toMap` method that simply
> > > gives the
> > > > user a
> > > > > Map if
> > > > > > that's what they want (it makes it clear that
> > > there's a
> > > > > conversion
> > > > > > happening).
> > > > > >
> > > > > > Regarding 3, the concern I have if we make
> the
> > > headers
> > > > mutable
> > > > > is that
> > > > > > it
> > > > > > seems to introduce some inconsistencies and
> > > potential edge
> > > > > cases. At
> > > > > > the
> > > > > > moment, it's safe to keep a ProducerRecord
> and
> > > resend it,
> > > > for
> > > > > example.
> > > > > > If
> > > > > > the record is mutated by an interceptor, then
> > > this can
> > > > lead to
> > > > > weird
> > > > > > behaviour. Also, it seems inconsistent that
> one
> > > has to
> > > > create a
> > > > > new
> > > > > > ProducerRecord to modify the record
> timestamp,
> > > but that
> > > > one has
> > > > > to
> > > > > > mutate
> > > > > > the record to add headers. It seems like one
> > > should either
> > > > > embrace
> > > > > > immutability or mutability, but mixing both
> is
> > > not ideal.
> > > > > >
> > > > > > Regarding 4, for the cases where there are a
> > > small number
> > > > of
> > > > > headers
> > > > > > and/or
> > > > > > 1 or 2 interceptors, it doesn't seem
> difficult
> > > to come up
> > > > with
> > > > > > reasonable
> > > > > > implementations for mutable and immutable
> cases
> > > that do a
> > > > good
> > > > > enough
> > > > > > job.
> > > > > > However, if the number of headers and
> > > interceptors is
> > > > large,
> > > > > then care
> > > > > > is
> > > > > > needed for the immutable case to avoid
> > > unnecessary
> > > > copying. A
> > > > > simple
> > > > > > option
> > > > > > that adds little memory overhead if we have
> > > Header
> > > > instances is
> > > > > to
> > > > > > simply
> > > > > > add a self-reference to the previous Header
> in
> > > the linked
> > > > list.
> > > > > >
> > > > > > Ismael
> > > > > >
> > > > > > On Thu, Feb 23, 2017 at 1:09 AM, Michael
> > Pearce <
> > > > > michael.pea...@ig.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Im happy to compromise to keep it mutable
> but
> > > move to an
> > > > append
> > > > > > style api.
> > > > > > > (as in guava interables concat)
> > > > > > >
> > > > > > > class Headers {
> > > > > > > Headers append(Iterable<Header>
> > > headers);
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > > I don’t think we’d want prepend, this would
> > > give the
> > > > idea of
> > > > > > guaranteed
> > > > > > > ordering, when in actual fact we don’t
> > provide
> > > that
> > > > guarantee
> > > > > (.e.g
> > > > > > one
> > > > > > > client can put headerA, then headerB, but
> > > another could
> > > > put
> > > > > headerB
> > > > > > then
> > > > > > > headerA, this shouldn’t cause issues), Also
> > > what if we
> > > > changed
> > > > > to a
> > > > > > hashmap
> > > > > > > for the internal implementation, its just a
> > > bucket of
> > > > entries
> > > > > no
> > > > > > ordering.
> > > > > > > I think we just need to provide an api to
> > > add/append
> > > > headers.
> > > > > > >
> > > > > > > This ok? If so ill update KIP to record
> this.
> > > > > > >
> > > > > > > Cheers
> > > > > > > Mike
> > > > > > >
> > > > > > > On 23/02/2017, 00:37, "Jason Gustafson" <
> > > > ja...@confluent.io>
> > > > > wrote:
> > > > > > >
> > > > > > > The point about usability is fair. It's
> > > also
> > > > reasonable to
> > > > > > expect that
> > > > > > > common use cases such as appending
> > headers
> > > should be
> > > > done
> > > > > > efficiently.
> > > > > > >
> > > > > > > Perhaps we could compromise with
> > something
> > > like this?
> > > > > > >
> > > > > > > class Headers {
> > > > > > > Headers append(Iterable<Header>
> > headers);
> > > > > > > Headers prepend(Iterable<Header>
> > headers);
> > > > > > > }
> > > > > > >
> > > > > > > That retains ease of use while still
> > giving
> > > > ourselves some
> > > > > > flexibility
> > > > > > > in
> > > > > > > the implementation.
> > > > > > >
> > > > > > > -Jason
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Feb 22, 2017 at 3:03 PM,
> Michael
> > > Pearce <
> > > > > > michael.pea...@ig.com
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I wasn’t referring to the headers
> > > needing to be
> > > > copied,
> > > > > im
> > > > > > meaning
> > > > > > > the
> > > > > > > > fact we’d be forcing a new producer
> > > record to be
> > > > > created, with
> > > > > > all
> > > > > > > the
> > > > > > > > contents copied.
> > > > > > > >
> > > > > > > > i.e what will happen is utility
> method
> > > will be
> > > > created
> > > > > or end
> > > > > > up
> > > > > > > being
> > > > > > > > used, which does this, and returns
> the
> > > new
> > > > ProducerRecord
> > > > > > instance.
> > > > > > > >
> > > > > > > > ProducerRecord
> > addHeader(ProducerRecord
> > > record,
> > > > Header
> > > > > > header){
> > > > > > > > Return New ProducerRecord(record.key,
> > > record.value,
> > > > > > > record.timestamp…..,
> > > > > > > > record.headers.concat(header))
> > > > > > > > }
> > > > > > > >
> > > > > > > > To me this seems ugly, but will be
> > > inevitable if we
> > > > > don’t make
> > > > > > adding
> > > > > > > > headers to existing records a simple
> > > clean method
> > > > call.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 22/02/2017, 22:57, "Michael
> Pearce"
> > <
> > > > > michael.pea...@ig.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Lazy init can achieve/avoid that.
> > > > > > > >
> > > > > > > > Re the concat, why don’t we
> > > implement that
> > > > inside the
> > > > > > Headers
> > > > > > > rather
> > > > > > > > than causing everyone to implement
> this
> > > as adding
> > > > > headers in
> > > > > > > interceptors
> > > > > > > > will be a dominant use case. We want
> a
> > > user
> > > > friendly API.
> > > > > > Having as
> > > > > > > a user
> > > > > > > > having to code this instead of having
> > > the headers
> > > > handle
> > > > > this
> > > > > > for me
> > > > > > > seems
> > > > > > > > redundant.
> > > > > > > >
> > > > > > > > On 22/02/2017, 22:34, "Jason
> > > Gustafson" <
> > > > > > ja...@confluent.io>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > I thought the argument was
> > > against
> > > > creating the
> > > > > extra
> > > > > > objects
> > > > > > > > unnecessarily
> > > > > > > > (i.e. if they were not
> > > accessed). And note
> > > > that
> > > > > making
> > > > > > the
> > > > > > > Headers
> > > > > > > > immutable doesn't necessarily
> > > mean that
> > > > they
> > > > > need to be
> > > > > > > copied:
> > > > > > > > you can do
> > > > > > > > a trick like Guava's
> > > Iterables.concat to
> > > > add
> > > > > additional
> > > > > > > headers
> > > > > > > > without
> > > > > > > > changing the underlying
> > > collections.
> > > > > > > >
> > > > > > > > -Jason
> > > > > > > >
> > > > > > > > On Wed, Feb 22, 2017 at 2:22
> > PM,
> > > Michael
> > > > Pearce <
> > > > > > > > michael.pea...@ig.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > If the argument for not
> > having
> > > a map
> > > > holding
> > > > > the
> > > > > > key, value
> > > > > > > > pairs is due
> > > > > > > > > to garbage creation of
> > HashMap
> > > entry's,
> > > > > forcing the
> > > > > > > creation of
> > > > > > > > a whole new
> > > > > > > > > producer record to simply
> add
> > > a head,
> > > > surely is
> > > > > > creating
> > > > > > > a-lot
> > > > > > > > more?
> > > > > > > > >
> > ______________________________
> > > __________
> > > > > > > > > From: Jason Gustafson <
> > > > ja...@confluent.io>
> > > > > > > > > Sent: Wednesday, February
> 22,
> > > 2017 10:09
> > > > PM
> > > > > > > > > To: dev@kafka.apache.org
> > > > > > > > > Subject: Re: [DISCUSS]
> KIP-82
> > > - Add
> > > > Record
> > > > > Headers
> > > > > > > > >
> > > > > > > > > The current producer
> > > interceptor API is
> > > > this:
> > > > > > > > >
> > > > > > > > > ProducerRecord<K, V>
> > > > onSend(ProducerRecord<K,
> > > > > V>
> > > > > > record);
> > > > > > > > >
> > > > > > > > > So adding a header means
> > > creating a new
> > > > > > ProducerRecord
> > > > > > > with a
> > > > > > > > new header
> > > > > > > > > added to the current
> headers
> > > and
> > > > returning it.
> > > > > Would
> > > > > > that
> > > > > > > not
> > > > > > > > work?
> > > > > > > > >
> > > > > > > > > -Jason
> > > > > > > > >
> > > > > > > > > On Wed, Feb 22, 2017 at
> 1:45
> > > PM, Michael
> > > > > Pearce <
> > > > > > > > michael.pea...@ig.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > So how would you have
> this
> > > work if not
> > > > > mutable
> > > > > > where
> > > > > > > > interceptors would
> > > > > > > > > > add headers?
> > > > > > > > > >
> > > > > > > > > > Sent using OWA for iPhone
> > > > > > > > > >
> > > ______________________________
> > > > __________
> > > > > > > > > > From: Jason Gustafson <
> > > > ja...@confluent.io>
> > > > > > > > > > Sent: Wednesday, February
> > > 22, 2017
> > > > 8:42:27 PM
> > > > > > > > > > To: dev@kafka.apache.org
> > > > > > > > > > Subject: Re: [DISCUSS]
> > > KIP-82 - Add
> > > > Record
> > > > > Headers
> > > > > > > > > >
> > > > > > > > > > I think the point on the
> > > mutability of
> > > > > Headers is
> > > > > > worth
> > > > > > > > discussing a
> > > > > > > > > little
> > > > > > > > > > more. As far as I can
> tell,
> > > once the
> > > > > > ProducerRecord (or
> > > > > > > > ConsumerRecord)
> > > > > > > > > is
> > > > > > > > > > constructed, there should
> > be
> > > no need to
> > > > > further
> > > > > > change
> > > > > > > the
> > > > > > > > headers. Is
> > > > > > > > > that
> > > > > > > > > > correct? If so, then why
> > not
> > > enforce
> > > > that
> > > > > that is
> > > > > > the
> > > > > > > case
> > > > > > > > through the
> > > > > > > > > API?
> > > > > > > > > > One problem with
> mutability
> > > it that it
> > > > > constrains
> > > > > > the
> > > > > > > > implementation of
> > > > > > > > > > Headers. For example, if
> we
> > > were
> > > > backing
> > > > > with a
> > > > > > byte
> > > > > > > slice,
> > > > > > > > would we
> > > > > > > > > recopy
> > > > > > > > > > the bytes if a header is
> > > added or
> > > > would we
> > > > > > maintain a
> > > > > > > satellite
> > > > > > > > > collection
> > > > > > > > > > of added records. Seems
> not
> > > great
> > > > either
> > > > > way. If we
> > > > > > > really
> > > > > > > > think
> > > > > > > > > mutability
> > > > > > > > > > is needed, perhaps we
> could
> > > add a
> > > > method to
> > > > > > headers to
> > > > > > > convert
> > > > > > > > it to a
> > > > > > > > > > mutable type (e.g. a
> > > Headers.toMap)?
> > > > > > > > > >
> > > > > > > > > > I'm also with Ismael
> about
> > > exposing
> > > > > Headers.get().
> > > > > > I
> > > > > > > thought
> > > > > > > > it might
> > > > > > > > > make
> > > > > > > > > > sense to have a method
> like
> > > this
> > > > instead:
> > > > > > > > > >
> > > > > > > > > > Iterable<Header>
> > > findMatching(Pattern
> > > > > pattern);
> > > > > > > > > >
> > > > > > > > > > This makes the
> (potential)
> > > need to
> > > > scan the
> > > > > headers
> > > > > > > clear in
> > > > > > > > the API. I'd
> > > > > > > > > > also be fine exposing no
> > > getter at
> > > > all. In
> > > > > > general, Ï
> > > > > > > think
> > > > > > > > it's good to
> > > > > > > > > > start with a minimalistic
> > > API and work
> > > > from
> > > > > there
> > > > > > since
> > > > > > > it's
> > > > > > > > always
> > > > > > > > > easier
> > > > > > > > > > to add methods than
> remove
> > > them.
> > > > > > > > > >
> > > > > > > > > > -Jason
> > > > > > > > > >
> > > > > > > > > > On Wed, Feb 22, 2017 at
> > 9:16
> > > AM,
> > > > Michael
> > > > > Pearce <
> > > > > > > > michael.pea...@ig.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Hi Ismael
> > > > > > > > > > >
> > > > > > > > > > > On point 1,
> > > > > > > > > > >
> > > > > > > > > > > Sure makes sense will
> > > update shortly.
> > > > > > > > > > >
> > > > > > > > > > > On point 2,
> > > > > > > > > > >
> > > > > > > > > > > Setter/getter typical
> to
> > > > > properties/headers api’s
> > > > > > > > traditionally are map
> > > > > > > > > > > styled interfaces and
> > what
> > > I believe
> > > > is
> > > > > most
> > > > > > expected
> > > > > > > styled
> > > > > > > > thus the
> > > > > > > > > > Key,
> > > > > > > > > > > Value setter.
> > > > > > > > > > > Also it would mean
> rather
> > > than an
> > > > > interface, we
> > > > > > would
> > > > > > > be
> > > > > > > > making our
> > > > > > > > > > > internal header impl
> > > object we have
> > > > for the
> > > > > > array,
> > > > > > > exposed.
> > > > > > > > E.g. if we
> > > > > > > > > > had
> > > > > > > > > > > a Map really this would
> > be
> > > Map.Entry
> > > > > interface,
> > > > > > this
> > > > > > > is the
> > > > > > > > same
> > > > > > > > > reasons
> > > > > > > > > > on
> > > > > > > > > > > the map interface I
> > cannot
> > > actually
> > > > make
> > > > > the
> > > > > > > underlying Node
> > > > > > > > object
> > > > > > > > > > that’s
> > > > > > > > > > > the implementation for
> > > HashMap, so
> > > > that
> > > > > > internals can
> > > > > > > be
> > > > > > > > changed.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On point 3,
> > > > > > > > > > >
> > > > > > > > > > > I think it people do
> > > expect it to be
> > > > > performant,
> > > > > > thus
> > > > > > > why
> > > > > > > > originally
> > > > > > > > > > > concern I raised with
> > > using an array
> > > > for
> > > > > to me
> > > > > > is an
> > > > > > > early
> > > > > > > > memory
> > > > > > > > > > > optimisation. I think
> the
> > > user
> > > > experience
> > > > > of
> > > > > > > > properties/headers is on a
> > > > > > > > > > > get/set model. This is
> > why
> > > its
> > > > important
> > > > > we have
> > > > > > > > encapsulated logic
> > > > > > > > > that
> > > > > > > > > > > then allows us to
> change
> > > this to a
> > > > map, if
> > > > > this
> > > > > > > becomes and
> > > > > > > > issue, and
> > > > > > > > > > the
> > > > > > > > > > > memory overhead of
> > hashmap
> > > is less
> > > > so.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 22/02/2017, 15:56, "
> > > > isma...@gmail.com
> > > > > on
> > > > > > behalf of
> > > > > > > > Ismael Juma" <
> > > > > > > > > > > isma...@gmail.com on
> > > behalf of
> > > > > ism...@juma.me.uk
> > > > > > >
> > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi all,
> > > > > > > > > > >
> > > > > > > > > > > Great to see the
> > > progress that
> > > > has been
> > > > > > achieved
> > > > > > > on this
> > > > > > > > one. :) A
> > > > > > > > > > few
> > > > > > > > > > > comments regarding
> > the
> > > APIs (I'm
> > > > still
> > > > > > reviewing
> > > > > > > the
> > > > > > > > message format
> > > > > > > > > > > changes):
> > > > > > > > > > >
> > > > > > > > > > > 1. Nit:
> `getHeaders`
> > in
> > > > > `ProducerRecord` and
> > > > > > > > `ConsumerRecord`
> > > > > > > > > should
> > > > > > > > > > be
> > > > > > > > > > > named `headers` (we
> > > avoid the
> > > > `get`
> > > > > prefix in
> > > > > > > Kafka)
> > > > > > > > > > >
> > > > > > > > > > > 2. The `Headers`
> > class
> > > is mutable
> > > > > (there's
> > > > > > an `add`
> > > > > > > > method). Does
> > > > > > > > > it
> > > > > > > > > > > need
> > > > > > > > > > > to be? If so, it
> > would
> > > be good to
> > > > > explain
> > > > > > why.
> > > > > > > Related
> > > > > > > > to that, we
> > > > > > > > > > > should
> > > > > > > > > > > also explain the
> > > thinking around
> > > > > > thread-safety. If
> > > > > > > we
> > > > > > > > keep the
> > > > > > > > > `add`
> > > > > > > > > > > method, it may make
> > > sense for it
> > > > to
> > > > > take a
> > > > > > `Header`
> > > > > > > > (that way we
> > > > > > > > > can
> > > > > > > > > > > add
> > > > > > > > > > > things to `Header`
> > > without
> > > > changing the
> > > > > > interface).
> > > > > > > > > > >
> > > > > > > > > > > 3. Do we need the
> > > `Headers.get()`
> > > > > method?
> > > > > > People
> > > > > > > usually
> > > > > > > > assume
> > > > > > > > > that
> > > > > > > > > > > `get`
> > > > > > > > > > > would be efficient,
> > but
> > > > depending on
> > > > > the
> > > > > > > implementation
> > > > > > > > (the
> > > > > > > > > current
> > > > > > > > > > > proposal states
> that
> > > an array
> > > > would be
> > > > > > used), it
> > > > > > > may not
> > > > > > > > be. If we
> > > > > > > > > > > expect
> > > > > > > > > > > the number of
> headers
> > > to be
> > > > small, it
> > > > > doesn't
> > > > > > > matter
> > > > > > > > though.
> > > > > > > > > > >
> > > > > > > > > > > Ismael
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Feb 21,
> 2017
> > > at 6:38 PM,
> > > > > Michael
> > > > > > Pearce <
> > > > > > > > > > michael.pea...@ig.com
> > > > > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Jason,
> > > > > > > > > > > >
> > > > > > > > > > > > Have converted
> the
> > > > interface/api
> > > > > bullets
> > > > > > into
> > > > > > > > interface code
> > > > > > > > > > > snippets.
> > > > > > > > > > > >
> > > > > > > > > > > > Agreed
> > > implementation won’t
> > > > take too
> > > > > long.
> > > > > > We
> > > > > > > have
> > > > > > > > early versions
> > > > > > > > > > > already.
> > > > > > > > > > > > Maybe a week
> before
> > > you think
> > > > about
> > > > > > merging I
> > > > > > > would
> > > > > > > > assume it
> > > > > > > > > would
> > > > > > > > > > > be more
> > > > > > > > > > > > stabilised? I was
> > > thinking
> > > > then we
> > > > > could
> > > > > > fork
> > > > > > > from
> > > > > > > > your confluent
> > > > > > > > > > > branch,
> > > > > > > > > > > > making and then
> > > holding KIP-82
> > > > > changes in
> > > > > > a patch
> > > > > > > > file, that we
> > > > > > > > > can
> > > > > > > > > > > then
> > > > > > > > > > > > re-fork from
> apache
> > > once KIP98
> > > > final
> > > > > is
> > > > > > merged,
> > > > > > > and
> > > > > > > > apply patch
> > > > > > > > > > with
> > > > > > > > > > > last
> > > > > > > > > > > > minute changes.
> > > > > > > > > > > >
> > > > > > > > > > > > Cheers
> > > > > > > > > > > > Mike
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On 22/02/2017,
> > > 00:56, "Jason
> > > > > Gustafson" <
> > > > > > > > ja...@confluent.io>
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hey Michael,
> > > > > > > > > > > >
> > > > > > > > > > > > Awesome. I
> have
> > > a minor
> > > > request.
> > > > > The
> > > > > > APIs are
> > > > > > > > currently
> > > > > > > > > > > documented as a
> > > > > > > > > > > > wiki list.
> > Would
> > > you mind
> > > > adding
> > > > > a code
> > > > > > > snippet
> > > > > > > > instead?
> > > > > > > > > It's a
> > > > > > > > > > > bit
> > > > > > > > > > > > easier
> > > > > > > > > > > > to process.
> > > > > > > > > > > >
> > > > > > > > > > > > How will be
> > best
> > > to manage
> > > > this,
> > > > > as we
> > > > > > will
> > > > > > > > obviously build
> > > > > > > > > off
> > > > > > > > > > > your
> > > > > > > > > > > > KIP’s
> > > > > > > > > > > > > protocol
> > > changes, to
> > > > avoid a
> > > > > merge
> > > > > > hell,
> > > > > > > should
> > > > > > > > we branch
> > > > > > > > > > from
> > > > > > > > > > > your
> > > > > > > > > > > > branch
> > > > > > > > > > > > > in the
> > > confluent repo or
> > > > is it
> > > > > worth
> > > > > > > having a
> > > > > > > > KIP-98
> > > > > > > > > special
> > > > > > > > > > > branch
> > > > > > > > > > > > in the
> > > > > > > > > > > > > apache git,
> > > that we can
> > > > > branch/fork
> > > > > > from?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I was
> thinking
> > > about this
> > > > also.
> > > > > > Ideally we'd
> > > > > > > like
> > > > > > > > to get the
> > > > > > > > > > > changes
> > > > > > > > > > > > in as
> > > > > > > > > > > > close
> together
> > > as possible
> > > > since
> > > > > we
> > > > > > only
> > > > > > > want one
> > > > > > > > magic bump
> > > > > > > > > > and
> > > > > > > > > > > some
> > > > > > > > > > > > users
> > > > > > > > > > > > deploy trunk.
> > > The level of
> > > > > effort to
> > > > > > change
> > > > > > > the
> > > > > > > > format for
> > > > > > > > > > > headers
> > > > > > > > > > > > seems
> > > > > > > > > > > > not too high.
> > Do
> > > you
> > > > agree? My
> > > > > guess
> > > > > > is that
> > > > > > > the
> > > > > > > > KIP-98
> > > > > > > > > message
> > > > > > > > > > > format
> > > > > > > > > > > > patch will
> take
> > > 2-3 weeks
> > > > to
> > > > > review
> > > > > > before we
> > > > > > > > merge to trunk,
> > > > > > > > > > so
> > > > > > > > > > > you
> > > > > > > > > > > > could
> > > > > > > > > > > > hold off
> > > implementing
> > > > until that
> > > > > patch
> > > > > > has
> > > > > > > somewhat
> > > > > > > > > stabilized.
> > > > > > > > > > > That
> > > > > > > > > > > > would
> > > > > > > > > > > > save some
> > > potential rebase
> > > > pain.
> > > > > > > > > > > >
> > > > > > > > > > > > -Jason
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 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,
> > > > > > company
> > > > > > > > number 04008957)
> > > > > > > > > > > and IG
> > > > > > > > > > > > Index 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
> > > > > > > > > > > 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 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,
> > > > company
> > > > > number
> > > > > > > 04008957)
> > > > > > > > and IG Index
> > > > > > > > > > > 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 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 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,
> > > > company
> > > > > number
> > > > > > > 04008957) and
> > > > > > > > IG Index
> > > > > > > > > > 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 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 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, company
> > > > number
> > > > > > 04008957)
> > > > > > > and IG
> > > > > > > > Index
> > > > > > > > > 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 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
> > > > > > > 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,
> > company
> > > number
> > > > > 04008957) and
> > > > > > IG
> > > > > > > Index
> > > > > > > > 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
> > > > > > > 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
> > > > > > 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, company
> > number
> > > > 04008957) and
> > > > > IG
> > > > > > Index
> > > > > > > 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
> > > > > > 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
> > > > > 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, company number
> > > 04008957) and
> > > > IG
> > > > > Index
> > > > > > 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
> > > > > 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 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,
> > > company number
> > > > > 04008957) and IG Index 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 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 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, company number 04008957) and
> > IG
> > > Index
> > > > 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 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 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, company number
> > > 04008957) and IG Index 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 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 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, company number 04008957) and IG Index
> > 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 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 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, company number 04008957) and IG Index 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 by the Financial Conduct Authority.
