forked from ifwe/bruce
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathbruce_conf.xml
199 lines (172 loc) · 9.71 KB
/
bruce_conf.xml
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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
<?xml version="1.0" encoding="US-ASCII"?>
<!-- example Bruce configuration -->
<bruceConfig>
<batching>
<namedConfigs>
<config name="low_latency">
<!-- Here we define thresholds that trigger completion of a
batch when exceeded. The "value" attribute of any of the
3 elements below can be set to "disable". However, at
least one of them must have its value set to something
other than "disable". -->
<!-- Set 500 milliseconds max batching delay. Here, you must
specify integer values directly rather than using syntax
such as "10k". Specifying "disable" for this setting is
not recommended, since it can cause Bruce to batch a
message indefinitely if not enough other messages arrive
to exceed one of the other two batching thresholds below.
-->
<time value="500" />
<!-- No limit on message count. You can specify a value here
such as "10" or "10k". A value of "10k" is interpreted as
(10 * 1024) messages. -->
<messages value="disable" />
<!-- Somewhat arbitrary upper bound on batch data size. As
above, "256k" is interpreted as (256 * 1024) bytes. A
simple integer value such as "10000" can also be
specified. This value applies to the actual message
content (keys and values). The total size of a batch will
be a bit larger due to header overhead. -->
<bytes value="256k" />
</config>
<config name="default_latency">
<time value="10000" />
<messages value="disable" />
<bytes value="256k" />
</config>
</namedConfigs>
<!-- Somewhat arbitrary upper bound on produce request size. As above,
a value such as "100k" is interpreted as (100 * 1024) bytes. You
can also specify simple integer values such as "100000" directly.
Here, you can not specify "disable". A nonnegative integer value
must be specified. This value applies to the actual message
content (keys and values). The total size of a produce request
will be a bit larger due to header overhead. -->
<produceRequestDataLimit value="1024k" />
<!-- This value should be exactly the same as the message.max.bytes
value in the Kafka broker configuration. A larger value will
cause Kafka to send MessageSizeTooLarge error ACKs to Bruce for
large compressed message sets, which will cause Bruce to discard
them. A smaller value will not cause data loss, but will
unnecessarily restrict the size of a compressed message set. As
above, you can supply a value such as "1024k". Specifying
"disable" here is not permitted. -->
<messageMaxBytes value="1000000" />
<!-- This specifies the configuration for combined topics batching
(where a single batch may contain multiple topics). Setting
"enable" to false is strongly discouraged due to performance
considerations.
-->
<combinedTopics enable="true" config="default_latency" />
<!-- This specifies how batching is handled for topics not specified in
"topicConfigs" below. Allowed values for the "action" attribute
are as follows:
"perTopic": This setting will cause each topic not listed in
"topicConfigs" to be batched individually on a per-topic
basis, with the "config" attribute specifying a batching
configuration from "namedConfigs" above.
"combinedTopics": This setting will cause all topics not
listed in "topicConfigs" to be batched together in mixed
topic batches. In this case, "config" must be either
missing or set to the empty string, and the batching
configuration is determined by the "combinedTopics"
element above. This is the setting that most people will
want.
"disable": This setting will cause batching to be disabled for
all topics not listed in "topicConfigs". In this case,
the "config" attribute is optional and ignored. This
setting is strongly discouraged due to performance
considerations.
-->
<defaultTopic action="combinedTopics" config="" />
<topicConfigs>
<!-- Uncomment and customize the settings in here if you wish to
have batching configurations that differ on a per-topic basis.
As above, allowed settings for the "action" attribute are
"perTopic", "combinedTopics", and "disable". The "disable"
setting is strongly discouraged due to performance
considerations.
<topic name="low_latency_topic_1" action="perTopic"
config="low_latency" />
<topic name="low_latency_topic_2" action="perTopic"
config="low_latency" />
-->
</topicConfigs>
</batching>
<compression>
<namedConfigs>
<!-- Don't bother to compress a message set whose total size is
less than minSize bytes. As above, a value such as "1k" is
interpreted as (1 * 1024) bytes. Here, a value of "disable"
is not recognized, but you can specify "0". The value of 128
below is somewhat arbitrary, and not based on experimental
data. Currently the only allowed values for "type" are
"snappy" and "none".
-->
<config name="snappy_config" type="snappy" minSize="128" />
<!-- "minSize" is ignored (and optional) if type is "none". -->
<config name="no_compression" type="none" />
</namedConfigs>
<!-- This must be an integer value at least 0 and at most 100. If the
compressed size of a message set is greater than this percentage
of the uncompressed size, then Bruce sends the data uncompressed,
so the Kafka brokers don't waste CPU cycles dealing with the
compression. The value below is somewhat arbitrary, and not based
on experimental data. -->
<sizeThresholdPercent value="75" />
<!-- This specifies the compression configuration for all topics not
listed in "topicConfigs" below.
-->
<defaultTopic config="snappy_config" />
<topicConfigs>
<!-- Uncomment and customize the settings in here if you wish to
configure compression on a per-topic basis.
<topic name="no_compression_topic_1" config="no_compression" />
<topic name="no_compression_topic_2" config="no_compression" />
-->
</topicConfigs>
</compression>
<topicRateLimiting>
<namedConfigs>
<!-- This configuration specifies that all messages should be
discarded. -->
<config name="zero" interval="1" maxCount="0" />
<!-- This configuration specifies no rate limit (i.e. don't discard
any messages regardless of their arrival rate). -->
<config name="infinity" interval="1" maxCount="unlimited" />
<!-- This configuration specifies a limit of at most 1000 messages
every 10000 milliseconds. Messages that would exceed this
limit are discarded. -->
<config name="config1" interval="10000" maxCount="1000" />
<!-- This configuration specifies a limit of at most (4 * 1024)
messages every 15000 milliseconds. Messages that would exceed
this limit are discarded. -->
<config name="config2" interval="15000" maxCount="4k" />
</namedConfigs>
<!-- This specifies a default configuration for topics not listed in
<topicConfigs> below. Each such topic is rate-limited
individually. In other words, with this configuration, topic
"topic_a" would be allowed 1000 messages every 10000 milliseconds,
and "topic_b" would also be allowed 1000 messages every 10000
milliseconds. -->
<defaultTopic config="config1" />
<topicConfigs>
<!-- Rate limit configurations for individual topics go here. -->
<topic name="activities" config="infinity" />
<topic name="incidents" config="infinity" />
<topic name="attacks" config="infinity" />
</topicConfigs>
</topicRateLimiting>
<initialBrokers>
<!-- When Bruce starts, it chooses a broker in this list to contact for
metadata. If Bruce cannot get metadata from the host it chooses,
it tries other hosts until it succeeds. Once Bruce successfully
gets metadata, the broker list in the metadata determines which
brokers Bruce will connect to for message transmission and future
metadata requests. Specifying a single host is ok, but multiple
hosts are recommended to guard against the case where a single
specified host is down.
-->
<broker host="kafkahost" port="9092" />
</initialBrokers>
</bruceConfig>