Package org.apache.kafka.streams.kstream

Interface Suppressed.BufferConfig<BC extends Suppressed.BufferConfig<BC>>

All Known Subinterfaces:
Suppressed.EagerBufferConfig, Suppressed.StrictBufferConfig
Enclosing interface:
Suppressed<K>
public static interface Suppressed.BufferConfig<BC extends Suppressed.BufferConfig<BC>>

  • Method Details

    • maxRecords

      static Suppressed.EagerBufferConfig maxRecords(long recordLimit)
      Create a size-constrained buffer in terms of the maximum number of keys it will store.

    • withMaxRecords

      BC withMaxRecords(long recordLimit)
      Set a size constraint on the buffer in terms of the maximum number of keys it will store.

    • maxBytes

      static Suppressed.EagerBufferConfig maxBytes(long byteLimit)
      Create a size-constrained buffer in terms of the maximum number of bytes it will use.

    • withMaxBytes

      BC withMaxBytes(long byteLimit)
      Set a size constraint on the buffer, the maximum number of bytes it will use.

    • unbounded

      static Suppressed.StrictBufferConfig unbounded()
      Create a buffer unconstrained by size (either keys or bytes). As a result, the buffer will consume as much memory as it needs, dictated by the time bound. If there isn't enough heap available to meet the demand, the application will encounter an OutOfMemoryError and shut down (not guaranteed to be a graceful exit). Also, note that JVM processes under extreme memory pressure may exhibit poor GC behavior. This is a convenient option if you doubt that your buffer will be that large, but also don't wish to pick particular constraints, such as in testing. This buffer is "strict" in the sense that it will enforce the time bound or crash. It will never emit early.

    • withNoBound

      Suppressed.StrictBufferConfig withNoBound()
      Set the buffer to be unconstrained by size (either keys or bytes). As a result, the buffer will consume as much memory as it needs, dictated by the time bound. If there isn't enough heap available to meet the demand, the application will encounter an OutOfMemoryError and shut down (not guaranteed to be a graceful exit). Also, note that JVM processes under extreme memory pressure may exhibit poor GC behavior. This is a convenient option if you doubt that your buffer will be that large, but also don't wish to pick particular constraints, such as in testing. This buffer is "strict" in the sense that it will enforce the time bound or crash. It will never emit early.

    • shutDownWhenFull

      Suppressed.StrictBufferConfig shutDownWhenFull()
      Set the buffer to gracefully shut down the application when any of its constraints are violated This buffer is "strict" in the sense that it will enforce the time bound or shut down. It will never emit early.

    • emitEarlyWhenFull

      Suppressed.EagerBufferConfig emitEarlyWhenFull()
      Set the buffer to just emit the oldest records when any of its constraints are violated. This buffer is "not strict" in the sense that it may emit early, so it is suitable for reducing duplicate results downstream, but does not promise to eliminate them.

    • withLoggingDisabled

      BC withLoggingDisabled()
      Disable the changelog for this suppression's internal buffer. This will turn off fault-tolerance for the suppression, and will result in data loss in the event of a rebalance. By default the changelog is enabled.
      Returns:
      this

    • withLoggingEnabled

      BC withLoggingEnabled(Map<String,String> config)
      Indicates that a changelog topic should be created containing the currently suppressed records. Due to the short-lived nature of records in this topic it is likely more compactable than changelog topics for KTables.
      Parameters:
      config - Configs that should be applied to the changelog. Note: Any unrecognized configs will be ignored.
      Returns:
      this