This repository has been archived by the owner on Feb 9, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 3
/
producer.properties
43 lines (39 loc) · 2.4 KB
/
producer.properties
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
###
### Managed by puppet - all modifications will be lost!
###
### See here for documentation:
### http://kafka.apache.org/documentation.html#producerconfigs
###
### The client id is a user-specified string sent in each request to help trace
### calls. It should logically identify the application making the request.
### Defaults to empty string
client.id=cass-mm-test-producer
### This is for bootstrapping and the producer will only use it for getting metadata
### (topics, partitions and replicas). The socket connections for sending the actual
### data will be established based on the broker information returned in the metadata.
### The format is host1:port1,host2:port2, and the list can be a subset of brokers or
### a VIP pointing to a subset of brokers.
metadata.broker.list=localhost:9072
### This value controls when a produce request is considered completed. Specifically,
### how many other brokers must have committed the data to their log and acknowledged
### this to the leader? Typical values are:
### 0, which means that the producer never waits for an acknowledgement from the broker
### (the same behavior as 0.7). This option provides the lowest latency but the weakest
### durability guarantees (some data will be lost when a server fails).
### 1, which means that the producer gets an acknowledgement after the leader replica
### has received the data. This option provides better durability as the client waits
### until the server acknowledges the request as successful (only messages that were
### written to the now-dead leader but not yet replicated will be lost).
### -1, which means that the producer gets an acknowledgement after all in-sync replicas
### have received the data. This option provides the best durability, we guarantee that
### no messages will be lost as long as at least one in sync replica remains.
### XXX we chose -1 because the whole point of mirroring is that no messages are
### lost.
request.required.acks=1
### This parameter specifies whether the messages are sent asynchronously in a
### background thread. Valid values are (1) async for asynchronous send and (2) sync
### for synchronous send. By setting the producer to async we allow batching together
### of requests (which is great for throughput) but open the possibility of a failure
### of the client machine dropping unsent data.
### XXX we pick async, as acks is set to -1, and this is for mirroring. Default is sync
producer.type=async