anchor.diff:            "default": 16384,
             "minimum": 0
   
  -=== lingerMs
  +`lingerMs`
   
   The producer groups together any records that arrive in between request transmissions into a single batched request. Normally this occurs only under load when records arrive faster than they can be sent out. However in some circumstances the client may want to reduce the number of requests even under moderate load. This setting accomplishes this by adding a small amount of artificial delay&mdash;that is, rather than immediately sending out a record the producer will wait for up to the given delay to allow other records to be sent so that the sends can be batched together. This can be thought of as analogous to Nagles algorithm in TCP. This setting gives the upper bound on the delay for batching: once we get batch.size worth of records for a partition it will be sent immediately regardless of this setting, however if we have fewer than this many bytes accumulated for this partition we will linger for the specified time waiting for more records to show up. This setting defaults to 0 (i.e. no delay). Setting linger.ms=5, for example, would have the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.
   
             "default": 0,
             "minimum": 0
   
  -=== deliveryTimeoutMs
  +`deliveryTimeoutMs`
   
   An upper bound on the time to report success or failure after a call to send() returns. This limits the total time that a record will be delayed prior to sending, the time to await acknowledgement from the broker (if expected), and the time allowed for retriable send failures. The producer may report failure to send a record earlier than this config if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch which reached an earlier delivery expiration deadline. The value of this config should be greater than or equal to the sum of request.timeout.ms and linger.ms.
   
             "default": 120000,
             "minimum": 0
   
  -=== clientId
  +`clientId`
   
   An id string to pass to the server when making requests. The purpose of this is to be able to track the source of requests beyond just ip/port by allowing a logical application name to be included in server-side request logging.
   
             "default": ""
   
  -=== sendBufferBytes
  +`sendBufferBytes`
   
   The size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is -1, the OS default will be used.
   
             "default": 131072,
             "minimum": -1
   
  -=== receiveBufferBytes
  +`receiveBufferBytes`
   
   The size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is -1, the OS default will be used.
   
             "default": 32768,
             "minimum": -1
   
  -=== maxRequestSize
  +`maxRequestSize`
   
   The maximum size of a request in bytes. This setting will limit the number of record batches the producer will send in a single request to avoid sending huge requests. This is also effectively a cap on the maximum uncompressed record batch size. Note that the server has its own cap on the record batch size (after compression if compression is enabled) which may be different from this.
   
             "default": 1048576,
             "minimum": -1
   
  -=== reconnectBackoffMs
  +`reconnectBackoffMs`
   
   The base amount of time to wait before attempting to reconnect to a given host. This avoids repeatedly connecting to a host in a tight loop. This backoff applies to all connection attempts by the client to a broker.
   
             "default": 50,
             "minimum": 0
   
  -=== reconnectBackoffMaxMs
  +`reconnectBackoffMaxMs`
   
   The maximum amount of time in milliseconds to wait when reconnecting to a broker that has repeatedly failed to connect. If provided, the backoff per host will increase exponentially for each consecutive connection failure, up to this maximum. After calculating the backoff increase, 20% random jitter is added to avoid connection storms.
   
             "default": 1000,
             "minimum": 0
   
  -=== retryBackoffMs
  +`retryBackoffMs`
   
   The amount of time to wait before attempting to retry a failed request to a given topic partition. This avoids repeatedly sending requests in a tight loop under some failure scenarios.
   
             "default": 100,
             "minimum": 0
   
  -=== maxBlockMs
  +`maxBlockMs`
   
   The configuration controls how long KafkaProducer.send() and KafkaProducer.partitionsFor() will block.These methods can be blocked either because the buffer is full or metadata unavailable.Blocking in the user-supplied serializers or partitioner will not be counted against this timeout.
   
             "default": 60000,
             "minimum": 0
   
  -=== requestTimeoutMs
  +`requestTimeoutMs`
   
   The configuration controls the maximum amount of time the client will wait for the response of a request. If the response is not received before the timeout elapses the client will resend the request if necessary or fail the request if retries are exhausted. This should be larger than replica.lag.time.max.ms (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.
   
             "default": 30000,
             "minimum": 0
   
  -=== metadataMaxAgeMs
  +`metadataMaxAgeMs`
   
   The period of time in milliseconds after which we force a refresh of metadata even if we havent seen any partition leadership changes to proactively discover any new brokers or partitions.
   
             "default": 30000,
             "minimum": 0
   
  -=== metadataMaxIdleMs
  +`metadataMaxIdleMs`
   
   Controls how long the producer will cache metadata for a topic thats idle. If the elapsed time since a topic was last produced to exceeds the metadata idle duration, then the topics metadata is forgotten and the next access to it will force a metadata fetch request.
   
             "default": 300000,
             "minimum": 5000
   
  -=== metricsSampleWindowMs
  +`metricsSampleWindowMs`
   
   The window of time a metrics sample is computed over.
   
            "default": 30000,
             "minimum": 0
   
  -=== metricsNumSamples
  +`metricsNumSamples`
   
   The number of samples maintained to compute metrics.
   
             "default": 2,
             "minimum": 1
   
  -=== metricsRecordingLevel
  +`metricsRecordingLevel`
   
   The highest recording level for metrics.
   
  
positive.code:           ]
            ----
  
  === batchSize
  
  The producer will attempt to batch records together into fewer requests whenever multiple records are being sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes.+
  No attempt will be made to batch records larger than this size.+
  
negative.code:             "none"
            ]
            
  `checkCRCS`
  
  Automatically check the CRC32 of the records consumed. This ensures no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so it may be disabled in cases seeking extreme performance.
  
            "default": true
            
  `metricsSampleWindowMs`
  
  The window of time a metrics sample is computed over.
  
            "default": 30000,
            "minimum": 0
  
  `metricsNumSamples`
  
  The number of samples maintained to compute metrics.
  
            "default": 2,
            "minimum": 1
            
  `metricsRecordingLevel`
  
  The highest recording level for metrics.
  
  