Packages

object ReactivePullStrategy extends Serializable

Source
ReactivePullStrategy.scala
Linear Supertypes
Serializable, AnyRef, Any
Ordering
  1. Alphabetic
  2. By Inheritance
Inherited
  1. ReactivePullStrategy
  2. Serializable
  3. AnyRef
  4. Any
  1. Hide All
  2. Show All
Visibility
  1. Public
  2. Protected

Type Members

  1. final case class FixedWindow(bufferSize: Int) extends ReactivePullStrategy with Product with Serializable

    This strategy pre-allocates a buffer of the given size and waits for it to fill up before emitting it downstream.

    This strategy pre-allocates a buffer of the given size and waits for it to fill up before emitting it downstream.

    Additional events are requested only after the buffer is emitted.

    This strategy is more efficient than StopAndWait, but less fair. For example if you have a producer that emits a tick every second, with a bufferSize of 10 the consumer will only see events every 10 seconds. Therefore it should be used with a busy source, but for slow producers StopAndWait is a better strategy.

Value Members

  1. final def !=(arg0: Any): Boolean
    Definition Classes
    AnyRef → Any
  2. final def ##(): Int
    Definition Classes
    AnyRef → Any
  3. final def ==(arg0: Any): Boolean
    Definition Classes
    AnyRef → Any
  4. final def asInstanceOf[T0]: T0
    Definition Classes
    Any
  5. def clone(): AnyRef
    Attributes
    protected[lang]
    Definition Classes
    AnyRef
    Annotations
    @throws(classOf[java.lang.CloneNotSupportedException]) @native()
  6. implicit val default: ReactivePullStrategy

    Default buffering strategy used when not overridden by a user-defined implicit.

  7. final def eq(arg0: AnyRef): Boolean
    Definition Classes
    AnyRef
  8. def equals(arg0: AnyRef): Boolean
    Definition Classes
    AnyRef → Any
  9. def finalize(): Unit
    Attributes
    protected[lang]
    Definition Classes
    AnyRef
    Annotations
    @throws(classOf[java.lang.Throwable])
  10. final def getClass(): Class[_ <: AnyRef]
    Definition Classes
    AnyRef → Any
    Annotations
    @native()
  11. def hashCode(): Int
    Definition Classes
    AnyRef → Any
    Annotations
    @native()
  12. final def isInstanceOf[T0]: Boolean
    Definition Classes
    Any
  13. final def ne(arg0: AnyRef): Boolean
    Definition Classes
    AnyRef
  14. final def notify(): Unit
    Definition Classes
    AnyRef
    Annotations
    @native()
  15. final def notifyAll(): Unit
    Definition Classes
    AnyRef
    Annotations
    @native()
  16. final def synchronized[T0](arg0: => T0): T0
    Definition Classes
    AnyRef
  17. def toString(): String
    Definition Classes
    AnyRef → Any
  18. final def wait(): Unit
    Definition Classes
    AnyRef
    Annotations
    @throws(classOf[java.lang.InterruptedException])
  19. final def wait(arg0: Long, arg1: Int): Unit
    Definition Classes
    AnyRef
    Annotations
    @throws(classOf[java.lang.InterruptedException])
  20. final def wait(arg0: Long): Unit
    Definition Classes
    AnyRef
    Annotations
    @throws(classOf[java.lang.InterruptedException]) @native()
  21. object StopAndWait extends ReactivePullStrategy with Product with Serializable

    This strategy consumes the elements from a Publisher one by one, with acknowledgement required for each event.

    This strategy consumes the elements from a Publisher one by one, with acknowledgement required for each event.

    In this mode the consumer must indicate its readiness to receive data after every event and the consumer must wait on that acknowledgement. Technically what this means is that for each element the consumer needs to do a request(1) call.

    This could be the same as FixedWindow(1) (see FixedWindow), however internally implementations can optimize for stop-and-wait flow control. For example a buffer is not necessarily required.

    Pros and Cons of stop-and-wait strategy:

    • the implementation can be simpler
    • versus FixedWindow it doesn't have to wait for the buffer to fill up, so it's more fair
    • the producer needs to wait for acknowledgement on each event and this is a source of inefficiency

Inherited from Serializable

Inherited from AnyRef

Inherited from Any

Ungrouped