Hi Walter: 1) you can still be reactive if you like if you build a transport layer being reactive. so moving that to the transport layer you will have the same benefits not blocking the IO at the endpoint level IMO. In any case using this sort of approach. 2) that should not invalidate the logic. It is to say. The job service will the the create - schedule - fire execution in place.
Ideally this should be like as colocated service runtime -> job service API -> embedded job service proxy (in vm transport) -> job service as distributed runtime -> job service API -> rest job service proxy (rest client) || wire || -> endpoint (reactive or not) -> job service El jue, 16 nov 2023 a las 10:15, Walter Medvedeo (<[email protected]>) escribió: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
