THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- Add a new headers length and value (byte[]) to the core message format.
- Create a Header Interface and implementing class
Interface
Code Block public interface Header { String key(); byte[] value(); }
Implementation Detail
- Add a String key field to Header implementing class
Add a byte[] value field to Header implementing class
- Create a Headers Interface and implementing class
Interface
Code Block public interface Headers extends Iterable<Header> { Headers add(String key, byte[] valueHeader header); Collection<byte[]>Collection<Header> get(String key); Set<String> keys(); }
Implementation Detail
Add a headers Header[] field to Headers implementation class
- Add accessor methods on the Headers class - Headers add(String key, byte[] valueHeader) and a Collection<byte[]> Collection<Header> get(String)
- implement Iterable<Header>
- interceptors are expected to add headers during the produce intercept stage.
- Add a headers field to ProducerRecord and ConsumerRecord.
- Add constructor(s) of Producer/ConsumerRecord to allow passing in of Iterable<Header>
- use case is MirrorMakers able to copy headers.
- Add accessor methods on the Producer/ConsumerRecord Headers headers()
Code Block public class ProducerRecord<K, V> { ... public Headers headers(); ... }
Code Block public class ConsumerRecord<K, V> { ... public Headers headers(); ... }
- Add ProduceRequest/ProduceResponse V4 which uses the new message format.
- Add FetchRequest/FetchResponse V4 which uses the new message format.
- The serialisation of the [String, byte[]] header array will on the wire using a strict format
- Each headers value will be custom serialisable by the interceptors/plugins that use the header.
...
- Adds the ability for producers to set standard header key=value value pairs
- No incompatible client api change (only new methods)
- Allows users to specify the serialisation of the header value per header
- Provides a standardised interface to eco systems of tools that then can grow around the feature
The disadvantage of this proposal is:
- Change to the message object
Create a Headers Interface and Implementation to encapsulate headers protocol.
- Fields:
- Headers[] headersArray
- Constructors
- ()
- (bytes[] headerBytes)
- Methods
- Collection<byte[]> Collection<Header> get(String key)
- void Headers add(String key, byte[] valueHeader header)
- Collection<String> keys()
- byte[] asBytes()
Add a headers field Headers to both ProducerRecord and ConsumerRecord
- Accessor methods of Headers getHeaders() added to interface of the ProducerRecord/ConsumerRecord.
- Add constructor(s) of Producer/ConsumerRecord to allow passing in of existing he Iterable<Header>
- use case is MirrorMakers able to copy headers.
Wire protocol change - add array of headers to end of the message format
...