Short Description
It is possible for the thread calling Emitter.emit and the EmittingThread to race on the
firstEventTimestamp field. If the Emitter.emit thread was running Batch.tryAddFirstEvent
and gets context switched out after writing the event to the buffer
and incrementing the event count but before setting firstEventTimestamp, this can cause
timeSinceFirstEvent to be inaccurate, leading to the batch not being sealed within the configured
flushMillis.
private boolean tryAddFirstEvent(byte[] event)
{
if (!tryReserveFirstEventSizeAndLock(event)) {
return false;
}
try {
firstEventLock.writeLock().lock();
int bufferOffset = emitter.batchingStrategy.writeBatchStart(buffer);
writeEvent(event, bufferOffset);
eventCount.incrementAndGet();
firstEventTimestamp = System.currentTimeMillis();
return true;
}
finally {
firstEventLock.writeLock().unlock();
unlock();
}
}
void sealIfFlushNeeded() {
long timeSinceFirstEvent = System.currentTimeMillis() - firstEventTimestamp;
if (firstEventTimestamp > 0 && timeSinceFirstEvent > emitter.config.getFlushMillis()) {
seal();
}
}
Stack Trace
Stack Trace
Short Description
It is possible for the thread calling
Emitter.emitand theEmittingThreadto race on thefirstEventTimestampfield. If theEmitter.emitthread was runningBatch.tryAddFirstEventand gets context switched out after writing the event to the buffer
and incrementing the event count but before setting
firstEventTimestamp, this can causetimeSinceFirstEventto be inaccurate, leading to the batch not being sealed within the configuredflushMillis.Stack Trace
Stack Trace