wmedvede commented on PR #2214: URL: https://github.com/apache/incubator-kie-kogito-apps/pull/2214#issuecomment-2859607424
Hello Guys @ricardozanini , @krisv , @elguardian, here goes my comments about this interesting topic: **Regarding Vertx Timers:** Vertx timers are reactive/IO, and executes in the Vertx event loop threads. More information on Vertx threads can be found in: - https://waytoeasylearn.com/learn/vert-x-event-loops - https://waytoeasylearn.com/learn/vert-x-worker-threads But, basically, everything that executes on a vertex event loop thread, is reactive/IO, and so do the Vertx Timers. **Jobs Service, is reactive?** Yes, in general all the Jobs Service code executes in vertx event loop threads, is based on Multi/Unit + still some old ReactiveStreams, but reactive. Even though, we still have "a left-over / bug (really not a bug, but yeah)" with a very simple solution to make the only part that still works in a mixed worker threads + verx event loop thread mode, to fully run on vertx event loop threads. And the “bug/left-over” is basically this line: https://github.com/apache/incubator-kie-kogito-apps/blob/32e38d2a97d86dfd09d4c1416e5794c94fc510fe/jobs-service/jobs-service-common/src/main/java/org/kie/kogito/jobs/service/job/DelegateJob.java#L78 That programs the job execution in the Infrastructure.getDefaultWorkerPool(), and which can easily fixed. **Solution:**: Just add a configuration parameter, naive example -> "job-executor-mode = "reactive" or "standard", and based on this config. Execute that Uni in the worker pool thread or not. **If "standard":** we keep this line as is, and thus, the jobs will basically NOT work on the vertex event loop thread, but in the standard worker threads. **Who benefits from the “standard” mode?** The currently existing jobs-service-embeeded-executor + the compact architecture. That internally executes for example standard blocking no reactive DB operations when using persistence. **If "reactive":** we basically don't add that line (well done, for course), and basically, everything is executed in the vertx event loop thread. And thus, we have a fully reactive Jobs Service. **Who benefits from the "reactive" mode?** Basically the SonataFlow installations that are not using the compact architecture. **Conclusion:** By adding a that simple "configuration", we can have a Jobs Service fully reactive or not depending on convenience. If it's still needed/desired to fully remove the reactiveness for other reasons, it is a different discussion. **Was the removal of reactive as a whole clearly indicated in the original proposal?** I think that no. However, I am not going to enter in the loop, or the level of the responses I have seen in the mailing list, etc. Doesn’t pay the price. So, guys, this is what I can say to try to clarify a bit more on how the Jobs Service works, and how it can be fully reactive even by using Vertx Timers. According to my understanding of this technology. From my side, I won't be the stick in the wheel, so from now I'm basically out of this particular discussion. I prefer to leave whatever additional consideration from the SontaFlow point of view to @krisv / @ricardozanini, and the rest. As well what's the best solution for our project. **Things that for me are a must whatever selected path is:** - The features we have right now must be preserved. - If a particular feature is selected to be dropped for any reason, it must be clearly clarified in the mailing list. - Current test coverage must be preserved. If you look, it has been spent a lot of time and effort to have a good test suite, not perfect, but good. So, the potential new Quarkus version MUST keep all these tests working, otherwise, we are not only not verifying that the jobs service still works, but also sending to the trash all these effort that we invested on so far. I'd love to see the SpringBoot version kind of replicate these tests too, maybe that part will have to be done incrementally, IDK, but the Quarkus ones must be there from day one. I hope this helps! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
