wildfly-proposals
wildfly-proposals copied to clipboard
wildfly
[WFLY-14869] galleon feature pack to support MicroProfile LRA
@mmusgrov @xstefank @jmfinelli I started the design doc for creating of the galleon feature pack for the MicroProfile LRA. Please share your opinions (or provide a PR on top of this :-) about the topic.
With the general agreement I think I can move it to standard PR. I hope to work on some PoC next week and then comment more. As well I need to find somebody from QE to look at this but they are overhelmed with work for the EAP 7.4.0 release and will be available only after it's done.
@ochaloup This is meant to be shipped in WF itself, yes? If so it goes in the 'wildfly' feature pack. A separate feature pack is used for things that have a distinct software lifecycle.
@bstansberry We want LRA is be available in standard WilfFly so we will want an entry for it under the microprofile directory. We also want it to be a standard galleon layer so that users can include LRA when they provision their servers. Is that what you mean by "wildfly feature pack"?
I updated the text with information that this is a 'wildfly' feature pack which will go to WildFly GitHub repository as a other microprofile specifications - https://github.com/wildfly/wildfly/tree/master/microprofile. This is what @bstansberry asked about.
The second update is that we specify to split the functionality to two separate Galleon layers - one with functionality of the LRA client the other with functionality of the LRA coordinator.
@ochaloup shouldn't we be consistent with Quarkus and just do the participant? Just thinking aloud.
@xstefank I see I was not thinking this way so far. In fact until now I thought that the Quarkus extension will be coupling the coordinator and the client. I do understand that the approach changed.
From your perspective, do you think we should not permit to run the coordinator and the client coupled in one JVM and having only one option for deployment which will be client in WildFly and the coordinator somewhere in a separate service which will be delivered as probably "a Quarkus based jar"/"docker image on top of jar"?
Personally, I don't have a strong preference. I would like the decoupled approach when the coordinator is a standalone microservice and thus standalone problem but I can understand that if the drive comes from distributed JTA-like transactions then you want to have a coordinator in the service itself. Still, the LRA participants and LRA coordinator are a decoupled concepts in my mind so I would suggest having a requirement to run coordinator externally like Jaeger, Prometheus, or Kafka.
We don't need to be consistent with quarkus and we definitely do need a subsystem that includes the coordinator.
I added the QE contact and added a paragraph that we need a way how to list unfinished LRA records.
I've taken over this RFE from Ondra. I will create a new analysis document.