JDBC Next questions regarding j.u.c.Flow integration

[Dávid Karnok]

Hi. I have a couple of questions/suggestions about how the proposal uses
j.u.c.Flow.

As I understand, the proposed underlying non-blocking IO uses
CompletableFutures, which are one shot async sources unlike Flow. Is this
due to async NIO being based around CompletableFutures?

I haven't delved too deeply into NIO but I'd think a Flow-based NIO could
be possible (and perhaps lower overhead) - I understand such thing is out
of scope here but from an API perspective, would it be possible to have as
less ties to CompletableFutures as possible? For example, have most API
Flow-based and the underlying implementation can use CompletableFutures as
sources of notifications?

The OperationGroup.operationPublisher(Flow.Publisher<Operation>
publisher) Javadoc has this statement:

* Any {@link Operation} passed to {@link Flow.Subscriber#onNext} must
be created by

* this {@link OperationGroup}. If it is not {@link
Flow.Subscriber#onNext} throws
* {@link IllegalArgumentException}


The Reactive-Streams spec forbids throwing from onNext. The only option, in
general, for "invalid" onNext is to cancel the Subscription. I don't know
how such error could be propagated back to the user other than adding
failure state/signal to the returned OperationGroup.

I think Row.isLast shouldn't return Future because one can only block or
spin on an non-completed future. On the conceptional level, why would the
row's consumer want to know this information asynchronously? In the Flow
API, onComplete will be eventually called which indicates there are no more
data coming. On the practical level, isLast poses a concurrency problem
because if the consumer may call isLast for multiple items, it will have
multiple outstanding CompletableFutures one of which may signal true while
the processing of the last row is in progress. Now the consumer's
implementor has to work out the concurrency implications of that.

-- 
Best regards,
David Karnok