Proposal: @NonBlocking(ordered=false) for concurrent async operations

[bensilvan]

After learning and trying writing apps with method chaining with @Incoming and @Outgoing, I notice two things:

1. when returning Uni<some-payload> after performing an async operation, by default it concat the publishers (like transformToUniAndAconcat() from mutiny) and by that keeping the order which makes sense for me for default behavior.

2. In sync operation I can set the @Blocking(ordered=false) and by that make those operations run in parallel on worker threads without blocking the i/o threads in case the order of the operation is not matter.

I was wondering why I can't do the same with async operations with something like @NonBlocking(ordered = false) which will act like the transfrormToUniAndMerge() in mutiny.

currently, I achieve that by doing this:

    @Incoming("input")
    @Outgoing("output")
    public Multi<Message<String>> asyncAndMerge(Multi<Message<String>> messages) {
        return messages.onItem()
                .transformToUniAndMerge(this::someAsyncOperation)
                .onItem().transform(this::createMessageWithNewPayloadAndPropegateMetadata)
    }

That theoretically could be:

    @NonBlocking(ordered=false)
    @Incoming("input")
    @Outgoing("output")
    public Uni<String> asyncAndMerge(String message) {
        return someAsyncOperation(message);
    } 

With good documentation, I think that it will help to easily use this potential of concurrency async calls to make the application more efficient in case the order is not matter. In addition, I'll be able to use the automatic metadata propagation feature and remove the code that creates a new message with the input message metadata in case only the payload change.

what are your thoughts about this?