Nice proposal.
Some comments.
On the section around cycle detection.
I would like to see support for this to be done by hops, as well e.g. using
approach is to use a header for the number of hops, as the mm2 replicates it
increases the hop count and you can make the mm2 configurable to only p
Re hops to stop the cycle and to allow a range of multi cluster topologies, see
https://www.rabbitmq.com/federated-exchanges.html where very similar was done
in rabbit.
On 12/7/18, 12:47 AM, "Michael Pearce" wrote:
Nice proposal.
Some comments.
On the section ar
n and mirror-maker's Handler. Maybe file a Jira
ticket to track this?
Really appreciate your feedback!
Ryanne
On Thu, Dec 6, 2018 at 7:03 PM Michael Pearce wrote:
> Re hops to stop the cycle and to allow a range of multi cluster
> topologies, see https://ww
ectly prefixed topics.
>
> If possible I'd much prefer header + hops based replication rather than
> lots of renamed topics. But either way, this KIP would be tremendously
> useful to us so I support it all the way! :)
>
> On Tue, Dec 11, 2018 at 5:32 AM Michael Pearce
>
ar from the naming convention that
"us-west.topic1" is a replicated topic with records originating from a
remote cluster.
I'm not sure I understand your concern w.r.t compacted topics and state.
Can you elaborate?
Ryanne
On Wed, Dec 12, 2018 at 8:41 AM Michael Pearce
wrote:
> Ryan
+1 (non-binding)
I personally think the current proposed Converters described in the KIP are
good, as Randall states it keeps it more in line with the pattern of the
Converter methods, I think this is a good reason.
-Original Message-
From: Jason Gustafson [mailto:ja...@confluent.io]
To me, this is a lot more in line with many other systems connections, to have
the ability to have a single connection string / uri, is this really that left
field suggesting or wanting this?
If anything this bring kafka more standardised approach imo, to have a unified
resource identifier, pro
; >
> > >>>> > So that would solve the serialization problem. How about
> connectors
> > >>>> and
> > >>>> > transforms that are implemented to expect a certain type of
header
> > >>>> value,
+1
Why not just drop the leading 0, and call next version 12.0.0 instead of 1.0.0,
I think in my head I’ve always just dropped the leading 0 anyhow.
On 21/07/2017, 04:15, "Neha Narkhede" wrote:
+1 on 1.0. It's about time :)
On Thu, Jul 20, 2017 at 5:11 PM Ewen Cheslack-Postava
wro
Hi Roger,
Thanks for the support.
I think the key thing is to have a common key space to make an ecosystem, there
does have to be some level of contract for people to play nicely.
Having map or as per current proposed in kip of having a
numerical key space of map is a level of the contract th
vert the message if the consumer version is old, right?
Thanks.
Jiangjie (Becket) Qin
On Wed, Nov 2, 2016 at 1:37 AM, Michael Pearce
wrote:
> Hi Joel , et al.
>
> Any comments on the below idea to handle roll out / compatibility of this
> feature, usin
For me 5c and 5a are almost identical.
The idea in the kip(5a) is that the core message just has a header length and
then the header bytes, which are then in a pre agreed sub wire protocol as
described.
5c instead of having a pre agreed wire format allows custom serialisation of a
map of
The
string, per header) to
be meaningful
* doesn't really say anything how to parse the tag's data, so it is in
effect useless on its own.
Regards,
Magnus
2016-11-07 18:32 GMT+01:00 Michael Pearce :
> Hi Roger,
>
> Thanks for the support.
>
> I think the key thing is to have a c
ove the value, right? In this case, we
> cannot wait for the log cleaner to do the down conversion because that
> message may have already been consumed before the log compaction happens.
>
> Thanks,
>
> Jiangjie (Becket) Qin
>
>
>
> On Mon, Nov 7, 2016 at 9:59 AM, Mic
Also we can add further guidance:
To avoid the below caveat to organisations by promoting of upgrading all
consumers first before relying on producing tombstone messages with data
Sent using OWA for iPhone
From: Michael Pearce
Sent: Tuesday, November 8
; detail.
>> >> >>>>>
>> >> >>>>> This is a single threaded benchmarks so all the measurements are
>> per
>> >> >>>>> thread.
>> >> >>>>>
>> >> >>>>> For 1M message
at has the attribute flag set for log
compacting but has a non null value. But this should be in first stage.
Once all the clients have upgraded (clients start recognizing the attribute
flag), we can move the broker to stage 2.
Thanks,
Mayuresh
On Tue, Nov 8, 2016 at 12:06 AM, Mich
; >
> >
> > On Wed, Nov 9, 2016 at 9:23 AM, Mayuresh Gharat <
> > gharatmayures...@gmail.com>
> > wrote:
> >
> > > I think it will be a good idea. +1
> > >
> > > Thanks,
> > >
> >
have completely miss-understood your 2 phased approach.
Cheers
Mike
On 10/11/2016, 11:22, "Michael Pearce" wrote:
Agree on this point by Raidai, im happy having a two stage roll out a
suggested by yourself Mayuresh, so for a period we have both as obviously a
transition peri
> > > Again this is more about semantics of correctness of end state.
> > > >
> > > > Thanks,
> > > >
> > > > Mayuresh
> > > >
> > > > On Wed, Nov 9, 2016 at 10:49 AM, Becket Qin
> > > wrote:
> > >
aratmayures...@gmail.com
> > wrote:
>
> > Sounds good Michael.
> >
> > Thanks,
> >
> > Mayuresh
> >
> > On Fri, Nov 11, 2016 at 12:48 AM, Michael Pearce
> > wrote:
> >
> > > @Mayuresh i don't think you've missed
Why do we not look to expose the lag broker side centrally?
Eg like burrow.
>From an operations point it's a lot easier to monitor lag centrally than per
>application. Also then you'd be able to see lag of consumers not alive or
>stalled.
The information if the consumer uses Kafka based or zoo
gt; something
> > > > so dynamic (and fragile) in practice.
> > > >
> > > > In the real world an application will be configured with a set of
> > plugins
> > > > to either add (producer)
> > > > or read (consumer) headers.
> &g
Should state I have no objections adding this client side, just more a question
to why we don't look and propose to add this broker side also.
Sent using OWA for iPhone
From: Michael Pearce
Sent: Monday, November 14, 2016 4:58:45 PM
To
t seems better to be discussed in another
KIP.
Thanks,
Jiangjie (Becket) Qin
On Mon, Nov 14, 2016 at 8:52 AM, Michael Pearce
wrote:
> I agree with Mayuresh.
>
> I don't see how having a magic byte helps here.
>
> What we are saying is that on day 1 after an upgrade both tom
Thanks guys, for discussing this offline and getting some consensus.
So its clear for myself and others what is proposed now (i think i understand,
but want to make sure)
Could i ask either directly update the kip to detail the migration strategy, or
(re-)state your offline discussed and agreed
,
Mayuresh
On Wed, Nov 16, 2016 at 11:07 PM, Michael Pearce
wrote:
> Thanks guys, for discussing this offline and getting some consensus.
>
> So its clear for myself and others what is proposed now (i think i
> understand, but want to make sure)
>
> Could i ask either directly u
Headers
For what it is worth also i agree. As a user:
1) Yes - Headers are worthwhile
2) Yes - Headers should be a top level option
14.11.2016, 21:15, "Ignacio Solis" :
> 1) Yes - Headers are worthwhile
> 2) Yes - Headers should be a top level option
>
> On Mon, Nov 14
This is a change to api level / client code making it more restrictive as such
would break code that has extended these classes. we should therefor have a
KIP for this.
At this time I would vote:
-1 this will break any existing code by organisations for imo unproven
performance improvement.
I
e the non-null message only in step (3) is this correct?
> ---> I do agree with you here.
>
> Becket, Ismael : can you guys review the migration plan listed above using
> magic byte?
>
> Thanks,
>
> Mayuresh
>
> On Fr
+1 it would be nice, and as is less restrive would not cause any issue.
Saying that agree this is a fix build not a feature build.
Sent using OWA for iPhone
From: Rajini Sivaram
Sent: Thursday, November 24, 2016 12:17:13 PM
To: dev@kafka.apache.org
Subjec
el
On Thu, Nov 24, 2016 at 7:56 PM, Michael Pearce
wrote:
> +1 it would be nice, and as is less restrive would not cause any issue.
>
> Saying that agree this is a fix build not a feature build.
>
> Sent using OWA for iPhone
>
> From: Raji
having a distinct compaction attribute “tombstone” flag instead
of relying on null value, allowing non-null value delete messages.
Many thanks,
Michael
On 22/11/2016, 15:52, "Michael Pearce" wrote:
Hi Mayuresh,
LGTM. Ive just made one small adjustment updating the wire p
this key other than matching?
Nacho
On Fri, Nov 18, 2016 at 9:30 AM, Michael Pearce
wrote:
> #jay #jun any concerns on 1 and 2 still?
>
> @all
> To get this moving along a bit more I'd also like to ask to get clarity on
> the below last point
h
> >
> >
> > > On Nov 29, 2016, at 3:18 AM, Michael Pearce
> > wrote:
> > >
> > > Hi All,
> > >
> > > We have been discussing in the below thread and final changes have
been
> > ma
ibe the down
conversion path to consumers (i.e., brokers on message format 0.10.2 and
consumers on older version).
Thanks,
Jun
On Tue, Nov 29, 2016 at 3:18 AM, Michael Pearce
wrote:
> Hi All,
>
> We have been discussing in the below thread and final
*Hi Jun,
Soo sorry for the typo/mistake.
On 02/12/2016, 11:19, "Michael Pearce" wrote:
Hi Jao
Thanks for the response. Sorry for slow reply, both with personal sickness
and also battling some critical issues encountered since upgrading to 0.10.1.0
1) Thans fo
ce you that headers in
Kafka
> > are
> > >> a
> > >> > >> good
> > >> > >> >> >>> > idea in general, so we can move ahead and try to agree
> on
> > the
> &g
IP-98 that also
intend to change the message format. If they all get approved, we should
think about whether it's better to just bump up the magic byte once to
incorporate multiple format changes like we did in KIP-31/KIP-32.
Thanks,
Jun
On Fri, Dec 2, 2016 at 3:19 AM,
for iPhone
From: James Cheng
Sent: Monday, December 5, 2016 8:50:30 AM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-82 - Add Record Headers
> On Dec 2, 2016, at 4:57 PM, Michael Pearce wrote:
>
> Hi Jun.
>
> RE Mirroring,
>
> [...]
>
> Lastly around
Hi Jun
do we have your vote on this now?
Any other concerns?
Cheers
Mike
Sent using OWA for iPhone
From: Michael Pearce
Sent: Saturday, December 3, 2016 1:37:45 AM
To: dev@kafka.apache.org
Subject: Re: [VOTE] KIP-87 - Add Compaction Tombstone Flag
Hi
For dealing with exactly once delivery.
As an alternative option has it been considered to have a message uuid in the
record, that then is deduped on consumption?
Similar to
https://activemq.apache.org/artemis/docs/1.0.0/duplicate-detection.html
Agreed this does not deal with transaction suppor
er message) since tombstone will be used rarely.
However, if the message format change here is combined with other KIPs,
then this optimization likely won't be needed. The latter probably makes
the code simpler. Jiangjie, Mayuresh, what do you think?
Other than those, +1 from me,
Thanks,
Jun
O
,
4. Hmm, does that mean the new client library can never send a null message
even to a regular topic? This seems like a change of the existing behavior.
Thanks,
Jun
On Tue, Dec 6, 2016 at 9:51 AM, Michael Pearce
wrote:
> Hi Jun,
>
> Re 4) That's because we expect the tombstone v
.2, 4.3 depend on whether the topic is compacted on not?
Thanks,
Jun
On Tue, Dec 6, 2016 at 10:35 AM, Michael Pearce
wrote:
> Not at all. This only acts on compacted topics just as what occurs today
>
> S
etween the concepts.
On Tue, Dec 6, 2016 at 9:04 AM, Michael Pearce
wrote:
> For dealing with exactly once delivery.
>
> As an alternative option has it been considered to have a message uuid in
> the record, that then is deduped on consumption?
>
My apologies, my computer is auto spellchecking and I didn’t notice before
sending.
*@Sriram
Thanks
Mike
On 08/12/2016, 08:35, "Michael Pearce" wrote:
@Shiram,
I would like to be able to have though exactly once delivery without the
need to use more heavy weight transact
two essential
ingredients needed to complete the exactly-once story, so we prefer to keep
them together.
-Jason
On Thu, Dec 8, 2016 at 12:36 AM, Michael Pearce
wrote:
> My apologies, my computer is auto spellchecking and I didn’t notice before
> sending.
>
> *@Sriram
>
> Thank
Like wise I think handling transactions separately is important as we should
consider supporting or at least a how in future session transactions, xa
transactions etc
Sent using OWA for iPhone
From: Michael Pearce
Sent: Thursday, December 8, 2016 6:12
Hi Jay,
For me having an XA transaction allows for ensuring ACID across my application.
I believe it is part of the JMS api, and obviously JMS still is in enterprise
very widely adopted for Messaging transport , so obviously to say it isn't
widely used i think is ignoring a whole range of users
the accounts. To move this flow to Kafka we
would need support of XA transaction.
Sent using OWA for iPhone
From: Michael Pearce
Sent: Friday, December 9, 2016 6:09:06 AM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-98: Exactly Once Delivery and
ons to be resilient to message duplication and loss,
rather
> than tightly coupling resource managers and ending up with something
fragile.
>
> Don't get me wrong. This is not an anti-Kafka rant. I just work with
people
> used to traditional transactional systems, making use of
ot; and the write to the destination needs to be
transactional, but it's not clear to me that you need isolation that spans
both operations. Can you dive into the system architecture a bit more and
explain why Kafka needs to participate in the same transaction as the
destination system?
-Ja
nd implementation for pluggable
multi-system XA.
-Jay
On Fri, Dec 9, 2016 at 10:25 AM, Michael Pearce
wrote:
> Hi Jay,
>
> I can't go too deep into exact implantation due to no NDA. So apologies
> here.
>
> Essentially we have multiple processes each owning selection of
Apologies on the spelling.
*Hi Jay,
From: Michael Pearce
Sent: Friday, December 9, 2016 7:52:25 PM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-98: Exactly Once Delivery and Transactional Messaging
Hi Jey
1) I agree, these should be used to add
e and send null to
mean delete. It seems like this would break compatibility with them, and
they would have to be rewritten to right?
-Jay
On Thu, Dec 8, 2016 at 12:12 AM, Michael Pearce
wrote:
> Hi Jun,
>
> 4) On v3 we honour the tombstone. As such we expect it to be set correctly
&g
ith null (or optional schemas in other formats), e.g. [null,
string], in which case losing the schema truly is losing information
(whereas null is already the only valid value for a pure null schema).
-Ewen
On Sat, Dec 10, 2016 at 9:24 PM, Michael Pearce
wrote:
> Hi Jay,
>
> Good point
null as an acceptable
value sent by the producer and expected by the consumer.
-Jay
On Sun, Dec 11, 2016 at 3:26 AM, Michael Pearce
wrote:
> Hi Ewen,
>
> I think the easiest way to show this is with code.
>
> As you can see we keep the existing behaviour for code/binaries c
common to maintain both or use KIP-71
to maintain a hybrid compacted/retention topic.
-Ewen
On Sun, Dec 11, 2016 at 1:18 PM, Michael Pearce
wrote:
> Hi Jay,
>
> Why wouldn't that work, the tombstone value is only looked at by the
> broker, on a topic configured for compaction as suc
mechanics?
@Mayuresh, Radai, Becket, Jun as you’ve all +1 voted on the existing solution
to do this by upgrading the existing compaction policy would any of you have
concerns with the alternative?
Regards,
Mike
On 11/12/2016, 23:33, "Michael Pearce" wrote:
Hi Ewen
So this i
ications
> might care to know the difference between a delete and a null value. In
> fact both versions of the same log (compacted and time-retention) could be
> useful and I don't think it'll be uncommon to maintain both or use KIP-71
> to maintain a hybrid compacted/retention topic.
Is there any update on this, when do we expect and RC1 for vote?
We see KAFKA-4497 is marked Resolved.
Cheers
Mike
On 13/12/2016, 00:59, "Guozhang Wang" wrote:
I see. Currently the upload command has not included the 2.12 version yet,
I will manually do that in the next RC.
Guozha
Hi Chaps,
Can we either get one more +1 binding (we have 2 already) on the existing?
Or have some response on the below possible alternative. We are keen to get
working on this, so we make next feature release.
Cheers
Mike
On 13/12/2016, 16:32, "Michael Pearce" wrote:
out of band or not be in sync with your code in
some environment seems worse to me then where we currently are. I think the
question is how would this combination be explained to users and does it
make sense?
-Jay
On Fri, Dec 16, 2016 at 9:25 AM, Michael Pearce
wrote:
> Hi Chaps,
>
&g
for the (what I think) are the right semantics.
Ismael
On Tue, Dec 13, 2016 at 8:32 AM, Michael Pearce
wrote:
> Hi Ismael
>
> Did you see our email this morning, what's your thoughts on this approach
> to instead we simply have a brand new polic
up. I hope
that explains my reasoning. Does it make sense at all?
Ismael
On Fri, Dec 16, 2016 at 1:53 PM, Michael Pearce
wrote:
> Hi Ismael
>
>
> So I understand what is being suggested, is we allow on the ProducerRecord
> at time of construction to be nullable aka big B, Boolean
vice
versa? As you may have noticed I'm somewhat emotionally invested in the
simplicity of the core data model, so my default position is let's try to
avoid stuffing more stuff in, but if we have to add stuff I like each of
these individually more than doing both. :-)
-Jay
On Fri, De
Wow just read that def over tired. Hopefully it makes sense. Or you get the
gist at least.
From: Michael Pearce
Sent: Monday, December 19, 2016 9:19:02 PM
To: dev@kafka.apache.org
Subject: Re: [VOTE] KIP-87 - Add Compaction Tombstone Flag
Hi Jay
V" (in the payload part of a message).
> if you have proper headers you obviously dont need to to stick them in V
> and so wont run into this, but its still a valid issue.
>
> On Mon, Dec 19, 2016 at 3:06 PM, Jay Kreps wrote:
>
>> Makes sense!
>>
>> -Jay
copy the whole record.
On Wed, Feb 22, 2017 at 5:09 PM, Michael Pearce
wrote:
> Im happy to compromise to keep it mutable but move to an append style api.
> (as in guava interables concat)
>
> class Headers {
>H
head 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
wrote:
> Im happy to compromise to keep it mutable but move to an append style api.
> (as in gua
d. 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
wrote:
> Hi
>
> On 1, How can you guarantee two separate implemented clients would add
> the headers in the same o
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" wrote:
Pattern.compile is expensive, and even if cached String.equals is faster
than matched. also if we end up with an in
oduced in
KIP-98?
The rest of the KIP looks good to me.
-Jason
On Fri, Feb 24, 2017 at 12:46 PM, Michael Pearce
wrote:
> I’ve added the methods on the ProducerRecord that will return a new
> instance of ProducerRecord with modified headers.
>
>
son
On Fri, Feb 24, 2017 at 2:22 PM, Michael Pearce
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
oduceRequest. 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" wrote:
We’re trying to make an eco-s
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
wrote:
> KIP updated in response to the below comme
, 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
> wrote:
>
Hi Radai:
RE:
Header header(String key) - returns JUST ONE (the very last) value given a
key
Iterable headers(String key) - returns ALL under a key
void add(Header header) - appends a header (key inside).
void remove(String key) - removes ALL HEADERS under a key.
I don't think this one is neede
f the
operation succeeded?
Cheers
Mike
________
From: Michael Pearce
Sent: Wednesday, March 1, 2017 5:55 AM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-82 - Add Record Headers
Hi Radai:
RE:
Header header(String key) - returns JUST ONE (the very last)
Hi Jun,
Thanks the comments I’ve updated the KIP a little where agreement.
My comments:
1) Good point, removed from the interface. See updated KIP
2) I think, Radai’s suggested header(String key) is a cleaner method name, but
happy to change if community believe lastHeader is better. I’ll keep
Hi Ismael,
Sorry,
The response below was in regards to your comments, got my wires crossed,
apologies.
Hi Jun,
I’m happy with the change, I see Jason updated our KIP, many thanks for this,
and thanks for implementing for us ☺
Cheers
Mike
On 20/03/2017, 13:19, "Michael Pearce&qu
think the type should instead by [Key Value] in our BNF, where key
> and
> >> value are both short strings as used elsewhere. This brings it in
> >> line with
> >> the rest of the protocol.
> >> 3. Could we
t;Jun Rao" wrote:
>
> > Hi, Michael,
> >
> > The KIP looks good to me overall. Just one comment. The wiki says "This
> > will be done by calling "close()" method". However, there is no close()
> in
> > Headers.
Renu Tewari
Jeroen van Disseldorp
Michael Pearce
Non Binding -1: 0
Non binding +0: 0
Based on the above result, we now have a lazy majority I am now closing this
voting thread as accepted.
I will move the KIP to accepted, and start work on implementation.
As per KIP discussion Jason has
AM, Michael Pearce
wrote:
> Hi Jun,
>
> Thanks for your vote, I’ve updated the wiki to document this detail.
>
> Cheers
> Mike
>
> On 24/03/2017, 05:00, "Jun Rao" wrote:
>
> Hi, Ismael,
>
> Ok, that make sense.
>
>
> Hi, Michael,
Hi All,
PR to add the client api building on the protocol changes already in
trunk/master is raised in GitHub
https://github.com/apache/kafka/pull/2772
Thanks Jeroen for feedback already :).
Please note we have dropped Java 8 bits for now and replaced with Java 7
compatible until KIP-118 is c
If moving to a wither pattern instead of a builder. How will this enforce
immutability? Eg current PR it is now changing to allow possible change values
once set.
Or are you proposing to change it to a mutable record? And move to a closable
record similar to the closing of the headers on send.
Hi all,
We would like to start the voting process for KIP-82 – Add record headers. The
KIP can be found
at
https://cwiki.apache.org/confluence/display/KAFKA/KIP-82+-+Add+Record+Headers
Discussion thread(s) can be found here:
http://search-hadoop.com/m/Kafka/uyzND1nSTOHTvj81?subj=Re+DISCUSS+KIP
3
> >
> > On Tue, Feb 14, 2017 at 9:42 AM, Michael Pearce
> > wrote:
> >
> > > Hi all,
> > >
> > > We would like to start the voting process for KIP-82 – Add record
> > headers.
> > > The KIP can
of the "type
> definition DSL")
>
> 2. this is an implementation detail, and not even a very "user facing"
one?
> to the best of my understanding the vote process is on proposed
> API/behaviour. also - since we're willing to go with string
>> >> other thing I find slightly odd is the fact that null headers has no
>> >> actual
>> >> semantic meaning for the message (unlike null keys and values). It is
>> >> just
>> >> a space optimization. It seems a bit bett
, "Michael Pearce" wrote:
On the point re: headers in the message protocol being a byte array and not
a count of elements followed by the elements. Again this was discussed/argued
previously.
It was agreed on for a few reasons some of which you have obviously picked
up on:
+0
I think need some unified agreement on the VarInts.
Would this also change in all other area’s 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" wrote:
Hi Jun,
Thanks fo
we would rather have them implement headers directly in their own
schema. Supposing for the sake of argument that it was possible, my
question is whether it be sufficient to expose the headers in the
interceptor API and not in the common API?
-Jason
On Fri, Feb 17, 2017 at 3:26 AM, Michael Pearce
wrot
d is figuring out how an MM use case would work. It
> > would be more cumbersome to replicate headers through an interceptor,
> > though arguably MM should be working at a lower level anyway.
> >
> > -Jason
> >
> > On Fri, Feb 17, 2017 at 10:16 AM, Michael Pearc
lazily to avoid
parsing out all the headers into little objects. HashMaps themselves are
kind of expensive and the consumer is very perf sensitive so and making
gazillions of hashmaps that may or may not get used is probably a bad idea.”
On 17/02/2017, 19:44, "Michael P
se cases. Let me see if I can come up with a
concrete proposal for that problem.
-Jason
On Fri, Feb 17, 2017 at 11:55 AM, Michael Pearce
wrote:
> I am happy to move the definition of the header into the message body, but
> would cause us not to lazy initialise
[] with
length value makes this a lot easier to skip.
On 17/02/2017, 20:37, "Michael Pearce" wrote:
What’s the issue with exposing a method getHeaders on the producer/consumer
record? It doesn’t break anything. We don’t need any special version.
Current batch consumer
t; tracing.
I still don't understand the point about batching. The consumer records are
exposed as a batch in the consumer interceptor, but you can still iterate
them individually. It is no different for the consumer API itself.
-Jason
On Fri, Feb 17, 201
1 - 100 of 156 matches
Mail list logo
