Closed Emily-Jiang closed 3 months ago
It's great to see this in the pipeline. Any estimation on when it will be available? What's the recommended solution in the meantime?
We constantly revisit our features in the pipeline. For this feature, it is not high up in the pipeline as yet at the moment, due to resource constraints. Do you currently use MicroProfile reactive messaging 1.0 in the production? Unfortunately, the workaround is to stay with the older version of MicroProfile release if you want to use MicroProfile Reactive Message together with other MicroProfile features.
Thanks for your prompt answer. We are not currently using this feature in production, but rather performing an evaluation of technologies for a new project. Unfortunately, I don't think it makes sense to begin a new project using MicroProfile 3.x, being two major versions behind now. Is there any other known workaround? For example, could we modify our pom.xml
and depend directly on microprofile-reactive-messaging-api
and smallrye-reactive-messaging-provider
, or do you foresee any big issues with such an approach?
My notes from the UFO socialization that was done on September 8:
Java APIs / SPIs (page 17)
Emitter and @Channel (page 19)
Message
Emitter and Channel Usage (page 21)
toUpperCase
returns a value, but there is no @Outgoing
so it can't return String or it needs @Outgoing
added.Backpressure Strategy (page 24)
Negative Acknowledgment (Nack) (page 28)
(Liberty)
after the word implementation
.Admin / Config / Command Line (page 40)
bootstrap.servers
vs bootstrap.server
. Can provide multiple hosts/ports. I believe on the call we confirmed that it is servers
and not server
in the existing guides.Automated Testing (page 46)
Platform / cloud considerations (page 49)
Serviceability (page 52)
Slide 23 indicates a strategy of BUFFER has a limit, but the Javadoc from the screenshot indicates that all messages are buffered, which makes UNBOUNDED_BUFFER and BUFFER seem identical. This is perhaps a Javadoc bug from upstream?
How does this feature handle changes to the configuration?
In what way does the configuration processing of this feature block the possibility of InstantOn working?
@NottyCode
The upstream Javadoc short descriptions as seen on slide 23 are the issue here. When looking at the full definitions in the javadoc it does cover the differences between the two.
The feature does not support changes to its configuration once the application has started for either Reactive Messaging or our Connector. All Configuration is read on App Start.
As the configuration is read only once on App start, changes, which we do highly expect there to be, especially details for connecting to kafka. Then currently the afterApp
option currently does cause the app to fail to checkpoint. Deferring the processing of the configuration to after app restore is currently being investigated. The Smallrye implementation passes the connector config to the liberty-kafka
connector, so if the implementation startup is deferred, then the connector will be as well.
There are a couple of problems that have arisen during development which are going to require changes in the design:
<channel prefix>.fast.ack
to change this behaviourtrue
in RM 3.0 so that it works better with the rest of RMfalse
in RM 1.0 to avoid breaking existing users who may rely on the current behaviour and to maintain zero migrationManagedExecutorService
to do this but there are two problems:ManagedExecutorService
is usedconcurrent-x.x
featureconcurrent-x.x
is not enabled, use the built-in WSContextService
to transfer the appropriate thread contextconcurrent-x.x
is enabled, use the default WSContextService
(which the user can configure)<mpReactiveMessaging contextServiceRef="xyz"/>
would set the context service for all Kafka connections<channel prefix>.context.service="xyz"
would set the context service for a specific channel and would override any configuration from the server.xml because it is more specificI will update the UFO with these changes. Since it's already been reviewed once, I will mark the changed slides as NEW and keep the original side at the end of the presentation marked as OLD.
@NottyCode I've updated the UFO with the changes in the comment above. The new/updated slides are 8, 11, 12, 43-45 and 61 (going by the slide numbers in the corners which doesn't match the box preview numbering because the presentation has hidden slides)
Any updated outlook on this one? It had been targeted for 23.0.0.12, but I see that target got removed recently. Has this slipped out to 2024? I tend to only move to the LTS releases, so maybe 24.0.0.3? And I assume this will require the big package change from javax.*
to jakarta.*
?
@jwalcorn Yes, we are now targeting 24.0.0.1 and yes it will be jakarta.*
based (compatible with MP 5.0, 6.0 and 6.1).
2nd UFO review comments: Slide 40
context.service
Point 4 above is not correct. A connector will receive all the config options that the user passes to it. It's up to individual connectors to decide how to handle properties they don't understand.
Update: We discussed this and will update the slides so that it's clear that the context.service
option only applies to the liberty-kafka
connector.
@OpenLiberty/ste-approvers STE education is available at https://ibm.ent.box.com/file/1412639185359 please can you review the document and provide any feed
UFO -- does the UFO identify the most likely problems customers will see and identify how the feature will enable them to diagnose and solve those problems without resorting to raising a PMR? Have these issues been addressed in the implementation?
Test and Demo -- As part of the serviceability process we're asking feature teams to test and analyze common problem paths for serviceability and demo those problem paths to someone not involved in the development of the feature (eg. L2, test team, or another development team). a) What problem paths were tested and demonstrated?
SVT -- SVT team is often the first team to try new features and often encounters problems setting up and using them. Note that we're not expecting SVT to do full serviceability testing -- just to sign-off on the serviceability of the problem paths they encountered. a) Who conducted SVT tests for this feature?
Which L2 / L3 queues will handle PMRs for this feature? Ensure they are present in the contact reference file and in the queue contact summary, and that the respective L2/L3 teams know they are supporting it. Ask Don Bourne if you need links or more info.
Does this feature add any new metrics or emit any new JSON events? If yes, have you updated the JMX metrics reference list / Metrics reference list / JSON log events reference list in the Open Liberty docs?
@abutch3r : WASWIN L2 is good with STE slides. Thanks!
@OpenLiberty/demo-approvers Demo scheduled for EOI 24.03
Description
The current MicroProfile Reactive Messaging 1.0 does not work with MicroProfile 4.x. Customers that use RM 1.0 are stuck. Quite a few customers asked about when RM 2.0 will be supported in Open Liberty many times (I was asked at JChampion conference 2022 on Friday 21st Jan 2022).
We should directly support the recent release of RM 3.0 (Jakarta EE 9.1 alignment) to make it work with Jakarta EE 10 and MP 6.0.
Documents
When available, add links to required feature documents. Use "N/A" to mark particular documents which are not required by the feature.
Aha: Externally raised RFE (Aha)
UFO: https://ibm.box.com/s/bffbods91oeddvxgbb5gpodq6m8x4ymy
FTS: (https://github.com/OpenLiberty/open-liberty/issues/25853)
Beta Blog: (https://github.com/OpenLiberty/open-liberty/issues/26642)
GA Blog: (https://github.com/OpenLiberty/open-liberty/issues/27213)
Process Overview
Prioritization
Design
Implementation
Legal and Translation
Beta
GA
Other Deliverables
General Instructions
The process steps occur roughly in the order as presented. Process steps occasionally overlap.
Each process step has a number of tasks which must be completed or must be marked as not applicable ("N/A").
Unless otherwise indicated, the tasks are the responsibility of the Feature Owner or a Delegate of the Feature Owner.
If you need assistance, reach out to the OpenLiberty/release-architect.
Important: Labels are used to trigger particular steps and must be added as indicated.
Prioritization (Complete Before Development Starts)
The (OpenLiberty/chief-architect) and area leads are responsible for prioritizing the features and determining which features are being actively worked on.
Prioritization
[x] Feature added to the "New" column of the Open Liberty project board
[x] Priority assigned
Design (Complete Before Development Starts)
Design preliminaries determine whether a formal design, which will be provided by an Upcoming Feature Overview (UFO) document, must be created and reviewed. A formal design is required if the feature requires any of the following: UI, Serviceability, SVT, Performance testing, or non-trivial documentation/ID.
Design Preliminaries
ID Required
, if non-trivial documentation needs to be created by the ID team.ID Required - Trivial
, if no design will be performed and only trivial ID updates are needed.Design
Design Review Request
Design Approval Request
Design Approved
No Design
No Design Approval Request
No Design Approved
Product Management Approval Request
and notifies OpenLiberty/product-managementProduct Management Approved
(OpenLiberty/product-management)FAT Documentation
[x] "Feature Test Summary" child task created
Implementation
A feature must be prioritized before any implementation work may begin to be delivered (inaccessible/no-ship). However, a design focused approach should still be applied to features, and developers should think about the feature design prior to writing and delivering any code.
Besides being prioritized, a feature must also be socialized (or No Design Approved) before any beta code may be delivered. All new Liberty content must be inaccessible in our GA releases until it is Feature Complete by either marking it
kind=noship
or beta fencing it.Code may not GA until this feature has obtained the "Design Approved" or "No Design Approved" label, along with all other tasks outlined in the GA section.
Feature Development Begins
In Progress
labelLegal and Translation
In order to avoid last minute blockers and significant disruptions to the feature, the legal items need to be done as early in the feature process as possible, either in design or as early into the development as possible. Similarly, translation is to be done concurrently with development. Both MUST be completed before Beta or GA is requested.
Legal (Complete before Feature Complete Date)
Translation (Complete 1 week before Feature Complete Date)
Innovation (Complete 1 week before Feature Complete Date)
[x] Consider whether any aspects of the feature may be patentable. If any identified, disclosures have been submitted.
Beta
In order to facilitate early feedback from users, all new features and functionality should first be released as part of a beta release.
Beta Code
kind=beta
,ibm:beta
,ProductInfo.getBetaEdition()
target:beta
and the appropriatetarget:YY00X-beta
(where YY00X is the targeted beta version).release:YY00X-beta
(where YY00X is the first beta version that included the functionality).Beta Blog (Complete 1.5 weeks before beta eGA)
[x] Beta blog issue created and populated using the Open Liberty BETA blog post template.
GA
A feature is ready to GA after it is Feature Complete and has obtained all necessary Focal Point Approvals.
Feature Complete
Translation - Complete
orTranslation - Missing
labelrelease
branch, feature owner adds labelTranslation - Complete
.Translation - Missing
.Translation - Missing
label is replaced withTranslation - Complete
.Translation - Blocked
label.Translation - Blocked
may NOT proceed to GA until the label has been replaced with eitherTranslation - Missing
orTranslation - Complete
.target:ga
and the appropriatetarget:YY00X
(where YY00X is the targeted GA version).Focal Point Approvals (Complete by Feature Complete Date)
These occur only after GA of this feature is requested (by adding a
target:ga
label). GA of this feature may not occur until all approvals are obtained.All Features
focalApproved:externals
@OpenLiberty/demo-approvers Demo scheduled for EOI [Iteration Number]
to this issue.focalApproved:demo
.focalApproved:fat
.Design Approved Features
focalApproved:id
.focalApproved:instantOn
.focalApproved:performance
.focalApproved:sve
.focalApproved:ste
.focalApproved:svt
.Remove Beta Fencing (Complete by Feature Complete Date)
GA Blog (Complete by Feature Complete Date)
Post GA
[ ] Replace
target:YY00X
label with the appropriaterelease:YY00X
. (OpenLiberty/release-manager)Other Deliverables
[ ] Standalone Feature Blog Post A blog post specifically about your feature or N/A. (OpenLiberty/release-architect)
[ ] OL Guides OL Guides assessment is complete or N/A. (OpenLiberty/guide-assessment)
[ ] Dev Experience Developer Experience & Tools work is complete or N/A. (OpenLiberty/dev-experience-assessment)