Details
Improvement
Resolved
Blocker
Description
Reconsider the API for dataflow channels, especially with respect to querying the size and unification with the Queue interface.
Operators may need error handling to be revisited.
Reconsider the API for dataflow channels, especially with respect to querying the size and unification with the Queue interface.
Operators may need error handling to be revisited.
In the current implementation the bind() method is an equivalent to <<, while the whenBound() is the same as >>. I typically use these methods when manipulating dataflow channels from Java.
To visualize the situation so as we could make decisions here, we should probably match the Queue interface methods with what we currently have in DataflowReadChannel:
boolean add(E e); - equivalent with bind()
boolean offer(E e); - no equivalent, since DataflowQueue is unbouded, our bind() always succeeds
E remove(); - equivalent to getVal(), although we block (optionally with a timeout), if no message is in the queue. asynchronous variants getValAsync() are also available
E poll(); - equivalent to poll()
E element(); - no equivalent, we do not support reading a value off the queue without actually taking it
E peek(); - no equivalent, we do not support reading a value off the queue without actually taking it