object ReactivePullStrategy extends Serializable
- Alphabetic
 - By Inheritance
 
- ReactivePullStrategy
 - Serializable
 - AnyRef
 - Any
 
- Hide All
 - Show All
 
- Public
 - Protected
 
Type Members
-   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
bufferSizeof 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
-   final  def !=(arg0: Any): Boolean
- Definition Classes
 - AnyRef → Any
 
 -   final  def ##: Int
- Definition Classes
 - AnyRef → Any
 
 -   final  def ==(arg0: Any): Boolean
- Definition Classes
 - AnyRef → Any
 
 -   final  def asInstanceOf[T0]: T0
- Definition Classes
 - Any
 
 -    def clone(): AnyRef
- Attributes
 - protected[lang]
 - Definition Classes
 - AnyRef
 - Annotations
 - @throws(classOf[java.lang.CloneNotSupportedException]) @native()
 
 -   implicit  val default: ReactivePullStrategy
Default buffering strategy used when not overridden by a user-defined implicit.
 -   final  def eq(arg0: AnyRef): Boolean
- Definition Classes
 - AnyRef
 
 -    def equals(arg0: AnyRef): Boolean
- Definition Classes
 - AnyRef → Any
 
 -    def finalize(): Unit
- Attributes
 - protected[lang]
 - Definition Classes
 - AnyRef
 - Annotations
 - @throws(classOf[java.lang.Throwable])
 
 -   final  def getClass(): Class[_ <: AnyRef]
- Definition Classes
 - AnyRef → Any
 - Annotations
 - @native()
 
 -    def hashCode(): Int
- Definition Classes
 - AnyRef → Any
 - Annotations
 - @native()
 
 -   final  def isInstanceOf[T0]: Boolean
- Definition Classes
 - Any
 
 -   final  def ne(arg0: AnyRef): Boolean
- Definition Classes
 - AnyRef
 
 -   final  def notify(): Unit
- Definition Classes
 - AnyRef
 - Annotations
 - @native()
 
 -   final  def notifyAll(): Unit
- Definition Classes
 - AnyRef
 - Annotations
 - @native()
 
 -   final  def synchronized[T0](arg0: => T0): T0
- Definition Classes
 - AnyRef
 
 -    def toString(): String
- Definition Classes
 - AnyRef → Any
 
 -   final  def wait(): Unit
- Definition Classes
 - AnyRef
 - Annotations
 - @throws(classOf[java.lang.InterruptedException])
 
 -   final  def wait(arg0: Long, arg1: Int): Unit
- Definition Classes
 - AnyRef
 - Annotations
 - @throws(classOf[java.lang.InterruptedException])
 
 -   final  def wait(arg0: Long): Unit
- Definition Classes
 - AnyRef
 - Annotations
 - @throws(classOf[java.lang.InterruptedException]) @native()
 
 -    case object StopAndWait extends ReactivePullStrategy with Product with Serializable
This strategy consumes the elements from a
Publisherone by one, with acknowledgement required for each event.This strategy consumes the elements from a
Publisherone 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
 
 

This is the API documentation for the Monix library.
Package Overview
monix.execution exposes lower level primitives for dealing with asynchronous execution:
Atomictypes, as alternative tojava.util.concurrent.atomicmonix.catnap exposes pure abstractions built on top of the Cats-Effect type classes:
monix.eval is for dealing with evaluation of results, thus exposing Task and Coeval.
monix.reactive exposes the
Observablepattern:Observableimplementationsmonix.tail exposes Iterant for purely functional pull based streaming:
BatchandBatchCursor, the alternatives to Scala'sIterableandIteratorrespectively that we are using within Iterant's encodingYou can control evaluation with type you choose - be it Task, Coeval, cats.effect.IO or your own as long as you provide correct cats-effect or cats typeclass instance.