fix emit wait time #2869
fix emit wait time #2869
Conversation
|
@gianm checkout this |
| @@ -24,7 +24,8 @@ All the configuration parameters for graphite emitter are under `druid.emitter.g | |||
| |`druid.emitter.graphite.flushPeriod` | Queue flushing period in milliseconds. |no|1 minute| | |||
| |`druid.emitter.graphite.maxQueueSize`| Maximum size of the queue used to buffer events. |no|`MAX_INT`| | |||
| |`druid.emitter.graphite.alertEmitters`| List of emitters where alerts will be forwarded to. |no| empty list (no forwarding)| | |||
| |`druid.emitter.graphite.emitWaitTime` | wait time in milliseconds to try to send the event otherwise emitter will throwing event. |no|1000 (1 sec)| | |||
There was a problem hiding this comment.
IMO the default should be 0, it's rare that people would want to block their query threads waiting for metrics emission rather than just drop some metrics and have queries return faster.
|
@gianm fixed |
|
I still think the default for |
|
The rest generally looks good though |
|
@gianm make sense, fixed |
| "Throwing event [%s] on the floor Graphite queue is full please increase the capacity or/and the consumer frequency", | ||
| mapper.writeValueAsString(event) | ||
| ); | ||
| countLostEvents.getAndIncrement(); |
There was a problem hiding this comment.
this increment isn't necessary, it's happening again on the next line.
|
👍 lgtm |
|
Running io.druid.query.extraction.namespace.TestKafkaExtractionCluster |
Fix for #2868