hutchig
commented
4 years ago Topics that need to be researched for WAD:
Use Case
To be able to have a cluster of Microservices with non-blocking back-pressure between them.
Testing
How do we test with remote Vert.x and Quarkus services
Developer Experience
How do we make Liberty a great environment for running business logic that can communicate on the Vert.x Eventbus? How do we make it easy for users to get going, debug and monitor there Vert.x Eventing Reactive Messaging beans?
Communications
How do we integrate with the two communities (Vert.x and Liberty)
Cross Server Clustering/Point-to-Point
We want to communicate with a remote Liberty but have inter-process back pressure - this we want in a Liberty idiomatic way - i.e. Vert.x is just a means to an end in this story - the user experience needs to be 100% liberty. We are not an new environment for running verticles (in this feature's scope anyway).
We also want to be able to communicate with back pressure to remote Vert.x and Quarkus processes. At the moment Quarkus is not supported in production as a member of a Vert.x cluster (due to Graal supportting Vert.x cluster-managers no there yet)
Network Security
We need this work just like other Liberty remote comms.
Threads
We need Vert.x threads to come from the Liberty ManagedExecutor (Discuss with that team (Nathan etc.) at least briefly). See also https://github.com/eclipse-vertx/vert.x/pull/3182
Lifecycle
Grace Shutdown on inbound and outbound work
We need to do a hard or soft shutdown (quiesce work)
- aligning with the user's Liberty shutdown request.
User can switch a reactive messaging annotated bean to Vert.x channels with a simple environment property update. So we need to 'auto-start' the Vert.x runtime dependant on the deployment scenario indicating that a Vert.x RM channel is being used.
Would we want to take account of property changes after startup? If so how?
Port Opening on Channel Config Discovery
Comms Stack
We will get some functionality for 'free' by utilising the existing Liberty comms stack (sometimes called the "channel framework") rather than bundlise and use netty. We need to tabularize the functionlity we are expected to link up with (monitoring, security etc) and understand at what 'level' this is plumbed in to the Liberty comms stack. For example, some services, metrics etc, may be working at the Servlet container level and we won't get these for free regardless of whether we use netty of the channel-framework.
Ports
How do we determine which ports to use. Can we use 'additional' ports or should we multiplex on existing ports - if we do, how do we recognise and split off Vert.x event traffic.
User Experience of Comms Config
How do they configure the whole end-to-end scenario?
What effect does using native Vert.x configuration gestures have?
Metrics
What Metric's can we get from the MP Reactive Messaging Implementation?
What does the Liberty MP RM implementation 'expect' a Connector to supply
to add to this?
Tracing
See note from Chris Bailey: "OpenTracing with Jaeger"
Health
We should be able to 'see' that a Vert.x EventBus Event sink is open for business.
CDI
Injection Into
Reactive Messaging uses annotations that are scanned and noticed at deployment time. We also need to be able to use 100% of CDI function in our messaging methods.
'Request' Scope or Custom Scope
We should have a scope, either 'the' RequestScope (better?) or a VertxEventScope. Usign 'standard' Request scope will enable lots of existing beans to work - we need to investigate if it is valid for RequestScope beans to 'assume' that they are in a HttpRequest and get hold of things that may be null/invalid for us.
API
We are using MP.RM no more no less.
Transitive Back-Pressure
We want to be able to set up an inter-process stream where, as well as the data, the request(N)
backpressure can cascade (with appropriate windowing and batching)
across multiple servers.
Transitive 'Ack'
For MP ReactiveMessaging, for example of the Kafka Connectors, we make use of the transport's 'ack' to drive the RM ack - which can then drive the user's Message.ack() method. We need to map this to Vert.x semantics to acheive a similar result.
User Debug
Think Reactor.Blockhound, Rust asynch-await diagnostics etc. How can we help users debug their inter-process async problems?
Messages and User Actions (and their translation)
RAAS
FFDC
How do we capture and make use of Vert.x FFDC info? What does it do natively.
Tracing
How do we trace what Vert.x code is doing?
(Open)Tracing (MP tracing, Jaeger etc)
Security
All this needs to be in place up to existing Liberty functionality and standards and not 'surface' Vert.x idioms? (Which are probably OK for beta).
Understand the capabilities of vertx, backpressure and the event bus to help design #8962 (backpressure across OpenLiberty and vertx processes).