Data Race between `Batch.tryAddFirstEvent` and `Batch.unlockAndSealIfNeeded`

[van-closed]

Short Description

When Emitter.emitAndReturnBatch is called concurrently, it is possible that the thread running Batch.tryAddFirstEvent
gets context switched out after writing the event to buffer and incrementing the event count but
before Batch.firstEventTimeStamp is set. 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();
    }
  }

  private void unlockAndSealIfNeeded()
  {
    if (eventCount.incrementAndGet() >= emitter.config.getFlushCount()) {
      unlockAndSeal();
    } else {
      firstEventLock.readLock().lock();
      long firstEventTimestampValue = firstEventTimestamp;
      firstEventLock.readLock().unlock();
      long timeSinceFirstEvent = System.currentTimeMillis() - firstEventTimestampValue;
      if (firstEventTimestampValue > 0 && timeSinceFirstEvent > emitter.config.getFlushMillis()) {
        unlockAndSeal();
      } else {
        unlock();
      }
    }
  }

Stack Trace

Stack Trace