Re: Broker Interceptors

t; right, this interceptor is going to tap into nearly everything. If you > > > have > > > strong guarantee (min.in.sync.replicas = N-1) then this may incur some > > > delay (and let's not forget inter broker comms protection by TLS > config). > > > This may not be desirable for some systems. That said, it would be good > > to > > > know what others think about this. > > > > > > Thanks, > > > > > > > > > > > Regards, > > > > > > > > Tom Aley > > > > thomas.a...@ibm.com > > > > Unless stated otherwise above: > > > > IBM United Kingdom Limited - Registered in England and Wales with > > number > > > > 741598. > > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 > > > 3AU > > > > > > > > > > > > > > > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with > number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > > > > > > > > > -- Nacho - Ignacio Solis - iso...@igso.net

Re: [DISCUSS] KIP-82 - Add Record Headers

at this method >> > returns >> > > that >> > > > encapsulates the headers protocol and logic. >> > > > >> > > > Best, >> > > > Mike >> > > > >> > > > ==Original questions from the vote thread from Jay.== >> > > > >> > > > Couple of things I think we still need to work out: >> > > > >> > > >1. I think we agree about the key, but I think we haven't >> > talked about >> > > >the value yet. I think if our goal is an open ecosystem of these >> > > header >> > > >spread across many plugins from many systems we should consider >> > making >> > > > this >> > > >a string as well so it can be printed, set via a UI, set in >> > config, >> > > etc. >> > > >Basically encouraging pluggable serialization formats here will >> > lead >> > > to >> > > > a >> > > >bit of a tower of babel. >> > > >2. This proposal still includes a pretty big change to our >> > > serialization >> > > >and protocol definition layer. Essentially it is introducing an >> > > optional >> > > >type, where the format is data dependent. I think this is >> > actually a >> > > big >> > > >change though it doesn't seem like it. It means you can no >> > longer >> > > > specify >> > > >this type with our type definition DSL, and likewise it requires >> > > custom >> > > >handling in client libs. This isn't a huge thing, since the >> > Record >> > > >definition is custom anyway, but I think this kind of protocol >> > > >inconsistency is very non-desirable and ties you to hand-coding >> > > things. >> > > > I >> > > >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 get more specific about the exact Java API change to >> > > >ProducerRecord, ConsumerRecord, Record, etc? >> > > > >> > > > -Jay >> > > > >> > > >> > >> > >> > 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. >> > -- Nacho - Ignacio Solis - iso...@igso.net

[DISCUSS] Control Messages - [Was: KIP-82 - Add Record Headers]

I'm renaming this thread in case we start deep diving. I'm in favor of so called "control messages", at least the notion of those. However, I'm not sure about the design. What I understood from the original mail: A. Provide a message that does not get returned by poll() B. Provide a way for

Re: [DISCUSS] KIP-82 - Add Record Headers

4). > > I think for purpose of getting this KIP moving past this, we can state the > > key will be a 4 bytes space that can will be naturally interpreted as an > > Int32 (if namespacing is later wanted you can easily split this into two > > int16 spaces), from the wire protocol imp

Re: [DISCUSS] 0.10.1.1 Plan

Sorry, that was a hasty reply. There are also various logging things that change format. This could break parsers. None of them are important, my only argument is that the final keyword removal is not important either. Nacho On Tue, Nov 29, 2016 at 1:25 PM, Ignacio Solis <iso...@igso.

Re: [DISCUSS] 0.10.1.1 Plan

ase goes out. > > Ismael > > On 29 Nov 2016 9:09 pm, "Ignacio Solis" <iso...@igso.net> wrote: > > > Some of the changes in the 0.10.1 branch already are not bug fixes. Some > > break compatibility. > > > > Having said that, at this level we should mai

Re: [DISCUSS] 0.10.1.1 Plan

ity, we could document it so that users can choose to do > > weird > > > things if they want, etc. > > > > > > Another thing that is usually good to think about is the expectation > for > > > `equals` and `hashCode`. What if subclasses implement them to have > value > > > semantics instead of identity semantics. Is that OK or would it break > > > things? > > > > > > Designing for implementation inheritance is generally complex although > > for > > > simple "record" like classes, it can be easier by following a few > > > guidelines. > > > > > > Ismael > > > > > > -- Nacho - Ignacio Solis - iso...@igso.net

Re: [DISCUSS] KIP-82 - Add Record Headers

with 32 bits. > > > > > > > On 18/11/2016, 20:34, "ignacio.so...@gmail.com on behalf of Ignacio > Solis" <ignacio.so...@gmail.com on behalf of iso...@igso.net> wrote: > > Summary: > > 3) Yes - Header value as byte[] > > 4a) Int,Int - No

Re: [DISCUSS] KIP-82 - Add Record Headers

lso 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" <iso...@igso.net>: > > 1) Yes - Headers are worthwhile > > 2) Yes - Headers should be a top level optio

Re: [DISCUSS] KIP-82 - Add Record Headers

1) Yes - Headers are worthwhile 2) Yes - Headers should be a top level option On Mon, Nov 14, 2016 at 9:16 AM, Michael Pearce wrote: > Hi Roger, > > The kip details/examples the original proposal for key spacing , not the > new mentioned as per discussion namespace idea.

Re: [DISCUSS] KIP-87 - Add Compaction Tombstone Flag

; > > > you're > > > > > > > > expecting > > > > > > > > > >>>>> (compaction). So, depending on the > > > > behavior > > > > > of the > > > > > > > > broker on > > > > > > > > > >>>> encountering > > >