Continuing the discussion, regarding the reactive to non-reactive it is a fair point, but with a wrapper in the addon that does the adapter, blocking the operations things should work, the point I'm concerned is about extracting the business logic of the scheduler into an addon to be run in the runtimes and with this we would have schedulers running in runtimes instances not in job-service (external service), which is different from the data-index that just persist the information into the database with no business logic not keeping anything in memory. That's why I believe an integration in the persistence layer would be simpler. But anyway, as far as we have things modularized and we are aware of this, the change will be self-contained in this addon, and the current behavior of job-service will be kept.
Best regards, _____________________________________ *Tiago Marchetti Dolphine* <[email protected]> On Thu, Nov 16, 2023 at 6:15 AM Walter Medvedeo <[email protected]> wrote: > Hi Alex, and guys, thanks for starting discussion. > > Let me add some comments that I think might be useful to consider for the > evaluation/implementation. > > Regarding option 2) we must keep in mind that right now, the jobs service > DB writes are reactive, as well as the scheduling process, etc. If we keep > this approach, I think we have a potential challenge here on how to > integrate the non reactive kogito-runtime DB writes (and it's synchronous > execution model in general) with the subsequent reactive schedule of the > job. Since in the end, we want all this to happen in the same transaction. > What are the plan in that regard? > > > Another thing to keep in mind is the treatment of overdue jobs. There are > situations where the job being created has already overpassed the execution > time, in these cases, it's automatically fired, and the corresponding > associated action is executed immediatelly. If I don't recall wrong, this > is decided as part of the scheduling process. I think we must be sure that > we can keep the possibility to fire ouverdue jobs (something that is > optional configurable) at the same time we don't want the execution of the > job is produced in the kogito-runtimes side but in the jobs-service. > > Regards, > Walter. > > > On 2023/11/15 20:58:11 Alex Porcelli wrote: > > Similar to Enrique, I'd +1 the second option.. as it aligns better > > with the current data-index approach. It would allow, for sake of > > simplicity. > > > > Are we ok if we move forward with the second option as a proposal to > > be implemented? > > > > > > On Tue, Nov 14, 2023 at 4:40 AM Enrique Gonzalez Martinez > > <[email protected]> wrote: > > > > > > That case is fixed as it uses the EventPublisher interface. > > > > > > El mar, 14 nov 2023, 10:25, Pere Fernandez (apache) < > [email protected]> > > > escribió: > > > > > > > Something we may also need to think about is the communication > between the > > > > Job-Service and the Data-Index. Currently it Job-Service needs to > message > > > > the Data-Index when a Job status changes. I think that for the > purpose of > > > > the Simplified Architecture it should be able to write directly into > the > > > > Data-Index DB, in a similar manner as the runtime does when the > > > > `kogito-addons-quarkus-data-index-persistence` addons are present. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
