Re: [PROPOSAL] Abandon PR checks in Jenkins

Hi Jan, Although not strictly related with Jenkins removal, I do not think the format check (or other "quality" checks, like coverage, sonar...) should be different per repo, but global to Kie. I'm of course in favour of removing Jenkins (which is slow and error prompt) but since the only place

Re: [PROPOSAL] Abandon PR checks in Jenkins

Hi Jan, I have seen Jenkins check failing while GHA worked. The Jenkins failure that was not reported by GHA (at least the one I can recall right none, but others cannot be excluded) was a format issue (I forgot to format one of the modified classes) So maybe worth to include a format check to

Re: [PROPOSAL] - Moving CLI and SonataFlow images back to SonataFlow operator's repo

; > > > not just "fix as soon as happen" because, in the meantime, there are > > > other > > > > things/priorities to be after. > > > > To be fair, the tooling guys are already after a big task, and I see > > > their > > > > need

Re: [PROPOSAL] - Moving CLI and SonataFlow images back to SonataFlow operator's repo

ork on tooling side. > > I hope my POV could make sense... > > Il giorno ven 10 mag 2024 alle ore 17:06 Francisco Javier Tirado Sarti < > ftira...@redhat.com> ha scritto: > > > HI Gabrielle, > > This is an interesting philosophical discussion. I agree that being

Re: [PROPOSAL] - Moving CLI and SonataFlow images back to SonataFlow operator's repo

ise man used to say, " A house > divided > > cannot stand" ;) > > > > On Fri, May 10, 2024 at 2:50 PM Alex Porcelli wrote: > > > > > Francisco, > > > > > > You're minimizing the disruption in others' planned workload

Re: [PROPOSAL] - Moving CLI and SonataFlow images back to SonataFlow operator's repo

ter.. if > others have to fix, it's up to others define when to fix. > > On Fri, May 10, 2024 at 8:48 AM Francisco Javier Tirado Sarti > wrote: > > > > Gabrielle, > > I think a real use case example where a change in the backend breaks > > tooling work in a way the

Re: [PROPOSAL] - Moving CLI and SonataFlow images back to SonataFlow operator's repo

; > > Tiago already provided a in-depth explanation of the issue in this ML, > > > that is summarized in the circular dependency thread [1] > > > > > > > > > TL;DR: **Today** KIE-Tools is not part of any PR checks in the runtime > > > re

Re: [PROPOSAL] - Moving CLI and SonataFlow images back to SonataFlow operator's repo

Hi Tiago, I would argue that, being all the repos part of the same release, mutable snapshot is perfectly acceptable. As it currently happens between Runtimes repo and Drools repo (which have the Kie api) and Apps repo and Runtimes repo. I, as I believe Enrique (at least if what I understood from

[PROPOSAL] Add shared context

Please feel free to complete the skecht of the proposal here https://github.com/apache/incubator-kie-issues/issues/1181 Thanks

Re: [DISCUSS] Output of one workflow as input of another

upport this in the > future. It is not possible to implement this with the current > connection types and activity input/output calculations. So that would > need to be changed somehow. but that is some other discussion > > > > > El mié, 8 may 2024 a las 15:26, Francisco Javier Tirad

Re: [DISCUSS] Output of one workflow as input of another

ss need to know how to compose that context. > > > In the case of BPMN we have the data store for this. Dont know if therecis > something different for swf. > > That would be an initial idea. > > El mar, 7 may 2024, 17:57, Francisco Javier Tirado Sarti < > ftira...@re

Re: [DISCUSS] Output of one workflow as input of another

; In this case there are several options and does not affect the engine at > the very core. > > Wdyt Francisco ? > > PS: the downside of using globals is making things a bit slower as u need > to access extra storage for executing process instances. > > El mar, 7 may 2024

Re: [DISCUSS] Output of one workflow as input of another

and leverage best practices to > best decouple workflows into smaller event based flows that Apache KIE > already support out of the box. > > -1 for me. > > On Tue, May 7, 2024 at 5:53 AM Francisco Javier Tirado Sarti > wrote: > > > > Hi Enrique, > > Thanks for

Re: [DISCUSS] Output of one workflow as input of another

e a very simple > process that reads from a stream, allows you to modify the input and sends > the outcome to another stream. > > Cheers > > > > El lun, 6 may 2024, 17:16, Francisco Javier Tirado Sarti < > ftira...@redhat.com> escribió: > > > Alex, I might be m

Re: [DISCUSS] Output of one workflow as input of another

ent topics? > > - > Alex > > > On Mon, May 6, 2024 at 11:02 AM Francisco Javier Tirado Sarti < > ftira...@redhat.com> wrote: > > > Hi, > > This is related with issue > > https://github.com/apache/incubator-kie-kogito-runtimes/issues/3495 > > We

[DISCUSS] Output of one workflow as input of another

Hi, This is related with issue https://github.com/apache/incubator-kie-kogito-runtimes/issues/3495 We have one user which would like to reuse the result of one workflow execution (let's call this workflow of type A) as input of several workflows (lets call them workflows of type B) Workflow A

Re: [PROPOSAL] Process in error state

should be more than enough to get rid of > the info in storage. but I am open to discuss a new state as > BAD_CREATION os something that represents a top level instance not > being able to create. > 4. what to do with the rest endpoint http code. > > Cheers :) > > El lu

Re: [PROPOSAL] Process in error state

bpm/jbpm-flow/src/main/java/org/jbpm/workflow/instance/impl/NodeInstanceImpl.java#L261 > and hot to implement those policies to avoid process instance creation > if it fails in new process. > > El lun, 6 may 2024 a las 10:39, Francisco Javier Tirado Sarti > () escribió: > > > &

Re: [PROPOSAL] Process in error state

am open to discuss re triggering mechanism but not for aborting process > instance automatically. It does not cover a real use scenario. > I am also open to discuss certain abort policies if certain criterias are > met. > > -1 to the proposal. > > > El vie, 3 may 2024, 13:

[PROPOSAL] Process in error state

Hi all, According to my interpretation of the engine code [1], all unexpected and unhandled errors during node execution are currently intercepted and the process state is set to Error, but the process instance remains active to allow users to update the model and retrigger process instance

Re: [PROPOSAL] Adding more counters to existing metric

yet because it is not clear the extra data of a > node > > El mar, 23 abr 2024, 13:20, Francisco Javier Tirado Sarti < > ftira...@redhat.com> escribió: > > > Yes, I agree. which is the status of the audit component? > > > > On Tue, Apr 23, 2024 at 1:18 PM E

Re: [PROPOSAL] Adding more counters to existing metric

23 abr 2024, 13:11, Francisco Javier Tirado Sarti < > ftira...@redhat.com> escribió: > > > And now a pretty questionable metric that was requested and that I feel > it > > belongs to the audit domain, but let's discuss it ;) > > There is a user that wants to know the

Re: [PROPOSAL] Adding more counters to existing metric

n in here. > +1 > > El mar, 23 abr 2024, 13:02, Francisco Javier Tirado Sarti < > ftira...@redhat.com> escribió: > > > Yes, I was thinking something like that. > > In the parser, add a metadata key ("Metric"?) to the node you want to > &g

Re: [PROPOSAL] Adding more counters to existing metric

be to add a counter with three tags (process-id, parameter name and parameter value). The issue here is what we understood as a parameter. Any idea is welcome (even to rule out the possibility and defer to custom metrics extensions) On Tue, Apr 23, 2024 at 12:59 PM Francisco Javier Tirado Sarti

Re: [PROPOSAL] Adding more counters to existing metric

adata on the node for signaling you want to meassure time > Metrics per process id - node maybe min, max, average ? > > Wdyt ? > > > El mar, 23 abr 2024, 11:17, Francisco Javier Tirado Sarti < > ftira...@redhat.com> escribió: > > > Hi Enrique, I was wond

Re: [PROPOSAL] Adding more counters to existing metric

and can be > completed in other. This should be kept in mind. > > El lun, 22 abr 2024 a las 14:56, Francisco Javier Tirado Sarti > () escribió: > > > > While implementing the proposal, I faced an issue that forced me to amend > > it https://github.com/apache/incubato

Re: [PROPOSAL] Adding more counters to existing metric

> +1 > > On Fri, Apr 19, 2024 at 8:46 PM ricardo zanini fernandes < > ricardozan...@gmail.com> wrote: > > > +1 > > > > On Fri, Apr 19, 2024 at 2:56 PM Pere Fernandez > > > wrote: > > > > > +1 > > > > > > El dv

[PROPOSAL] Adding more counters to existing metric

Hi all, Let me know if there is any problem with the proposal in this issue description. Thanks

Re: DMN with Sonataflow

ne. Maybe add a disclaimer to sonataflow docs about this and a readme file > would also help. > > - > Alex > > On Thu, Apr 18, 2024 at 6:43 AM Francisco Javier Tirado Sarti < > ftira...@redhat.com> wrote: > > > Hi, > > I agree with the constraints mentioned

Re: DMN with Sonataflow

s an experimental feature and > likely to be replaced in the future with a more suitable format, such > as yaml-based decision tables (if I recall correctly, such a format > was mentioned). > > - > Alex > > On Tue, Apr 16, 2024 at 2:34 PM Francisco Javier Tirado Sarti > wr

[HEADS UP] Add GraphQL support to SWF

I'm going to start working on this issue https://github.com/apache/incubator-kie-issues/issues/1093

Re: DMN with Sonataflow

linked modules in order to have the feature available in quarkus. On Tue, Apr 16, 2024 at 8:29 PM Francisco Javier Tirado Sarti < ftira...@redhat.com> wrote: > Hi Mark, > Yes, the new SWF DMN module is optional (this can be easily checked in the > PR > <https://github.com/

Re: DMN with Sonataflow

Hi Mark, Yes, the new SWF DMN module is optional (this can be easily checked in the PR ). Besides that, we are going to work, as part of a proposal from

Re: DMN with Sonataflow

nes) specification. All things you mentioned, > > that can be executed, are pure infrastructure functions, highly technical > > ones. However, with the clarifications, I will not block this. It is just > > my opinion. I always thought of Sonataflow as a low level orchestrat

Re: DMN with Sonataflow

a low level orchestration > platform and not a business automation workflow engine. I would be very > interested in the opinion of others about this. > > Best regards, > Tibor > > On Tue, Apr 16, 2024 at 12:04 PM Francisco Javier Tirado Sarti < > ftira...@redhat.com>

Re: DMN with Sonataflow

m/apache/incubator-kie-kogito-examples/tree/stable/serverless-workflow-examples/serverless-workflow-camel-routes > > > > The idea would be the same. Drop the DMN file in your project, declare a > > function for it, and call it in an operation state [1]. > > > > Cheers! > > &g

Re: DMN with Sonataflow

Hi Tibor, Thanks for opening the topic. This PR adds support for invoking a DMN file from SonataFlow. This PR takes advantage of the fact that DMN file invocation is already supported by jbpm engine and code generator and that the jbpm engine is already being used both by SonataFlow and BPMN

Re: [VOTE] - SonataFlow initial logo

I cannot believe me being with the majority in an "art taste" thing ;) On Wed, Apr 10, 2024 at 7:10 PM ricardo zanini fernandes < ricardozan...@gmail.com> wrote: > Folks, here's the results: > > >

Re: [PROPOSAL] Extension mechanism for additional workflow process definitions elements

to move the things that are not primitives to bpmn module. > Included dmn. > > Why do you want to create a new module ? Shared concern ? > > El mié, 10 abr 2024, 11:46, Francisco Javier Tirado Sarti < > ftira...@redhat.com> escribió: > > > Hi, > > A minor

Re: [PROPOSAL] Extension mechanism for additional workflow process definitions elements

Hi, A minor detail I just realized is, can we include in the proposal the target module for RuleSetNode (the one used for drl/dmn execution)?. I'm assuming it will no longer be jbpm-flow. I propose a module named jbpm-flow-dmn-extension or similar. On Tue, Apr 9, 2024 at 10:31 PM Jason Porter

Re: [PROPOSAL] Extension mechanism for additional workflow process definitions elements

Hi Enrique, Thanks for writing down the proposal +10 ;) On Tue, Apr 9, 2024 at 9:50 AM Tibor Zimányi wrote: > Hi Enrique, > > thank you, sounds good, +1. > > Best regards, > Tibor > > Dňa ut 9. 4. 2024, 9:21 Enrique Gonzalez Martinez > napísal(a): > > > At present, it is very difficult adding

Re: Friendly reminder about agreed procedures and communication etiquette

Have a nice weekend On Fri, Apr 5, 2024 at 5:25 PM Alex Porcelli wrote: > Check the wiki link and you can find the following: > > “[HEADS-UP] - Non-small changes to the code base are underway, and the list > should take note” > > - > Alex > > On Fri, Apr 5, 2024 at 1

Re: Friendly reminder about agreed procedures and communication etiquette

recommend using ML for > that. > > This is valid for everyone in the community, individuals should not be > single out for any reason. > > On Fri, Apr 5, 2024 at 10:10 AM Francisco Javier Tirado Sarti > wrote: > > > > Yes, that was the idea, to mention the need for a

Re: Friendly reminder about agreed procedures and communication etiquette

apache.org/confluence/display/KIE/Communication+within+Apache > > On Fri, Apr 5, 2024 at 9:54 AM Francisco Javier Tirado Sarti > wrote: > > > > Hi Alex, > > > > Of course, we will be delighted to continue maintaining our high > standards > > of coll

Re: Friendly reminder about agreed procedures and communication etiquette

Hi Alex, Of course, we will be delighted to continue maintaining our high standards of collaboration that define our community. However, it is unclear to me if for any community issue that arises as a consequence of a bug (or perceived bug) in our code base, there is a need to write a proposal. I

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

Thanks a lot for amending the proposal. Although I agree with almost the whole proposal, as pointed out in my previous e-mails, I did not understand, out of ignorance probably, the need for a cutting point of Category A before Category B. If the criteria is the existence of a dependency,

Re: [VOTE] Accept Amended Proposal to unblock Apache KIE 10.0.0 Release

Thanks a lot for amending the proposal. Although I agree with almost the whole proposal, as pointed out in my previous e-mails, I did not understand, out of ignorance probably, the need for a cutting point of Category A before Category B. If the criteria is the existence of a dependency,

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

nals > of all, to be able to provide a reliable estimate of efforts involved in > bigger refactoring. > > Summary: > I don't see an easy way how a simple change in CI would help to unblock the > current situation. Considering Tiago's proposal, timestamped SNAPSHOTs > already in place,

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

riting material to smooth out those edges can > > work pretty well. People do not contribute because a codebase is > > "pure". People contribute because they care about the project. And I'm > > always surprised by the lengths people go to when they want to get &g

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

he release process > itself. Otherwise, we risk having gaps that each person will fill in a > different way, and IMHO, that's where problems happen. +1 for examples > unification, btw :) > > 2) Ok, and +1 for no categorization. > > On Wed, Mar 13, 2024 at 10:42 AM Franc

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

from scratch, and that includes all the ones that are involved > by it, we could break this deadlock. > WDYT ? > > Il giorno mer 13 mar 2024 alle ore 15:41 Francisco Javier Tirado Sarti < > ftira...@redhat.com> ha scritto: > > > 1) Ok, if that is the case, I do not ge

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

if what you're asking is why Category B repos refer to > Category A repos via timestamped SNAPSHOTs, the answer is in my first > email. See the paragraph starting with "An important note here is that > Category B repositories...". > > On Wed, Mar 13, 2024 at 10:07 AM Francisco

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

the image build step from it should > not be > > > too difficult (since it is an issue we already faced and solved). > > > If, with "detailed proposal", you mean a complete list of all modules > to be > > > moved and dependency refactoring, of course I c

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

 PM Alex Porcelli wrote: > The guestimate of the plan discussed in this thread is around 2-3 weeks. > > On Wed, Mar 13, 2024 at 9:47 AM Francisco Javier Tirado Sarti > wrote: > > > > Ok, thanks Alex for the clarification. > > So two months for changing the order o

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

oned that if Tristan was around and could dedicate his > time on this, he believes that Tristan could make the same changes > potentially in about 2 weeks. > > > On Wed, Mar 13, 2024 at 9:26 AM Francisco Javier Tirado Sarti > wrote: > > > > @Ricardo Zanini The main

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

gt; > > Please let’s keep this thread focused on the detailed proposal shared. > > > > In case of multiple proposals we can start an official vote. > > > > > > On Wed, Mar 13, 2024 at 9:05 AM Francisco Javier Tirado Sarti < > > ftira...@redhat.com> wrote:

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

for the kie-tools repo, removing the image build step from it should > not > > be > > > too difficult (since it is an issue we already faced and solved). > > > If, with "detailed proposal", you mean a complete list of all modules > to > > be > > &g

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

e > > too difficult (since it is an issue we already faced and solved). > > If, with "detailed proposal", you mean a complete list of all modules to > be > > moved and dependency refactoring, of course I can not provide it right > now. > > > > Anyway, I s

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

> a more detailed plan… so we - as community- can evaluate the size of the > effort. In the conceptual level you shared it’s near impossible to estimate > the size of the effort and compare with the current proposal. > > On Wed, Mar 13, 2024 at 7:23 AM Francisco Javier Tirado Sarti < &

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

undisputable needs while they > > are, actually, just technical choices. > > Anyway, this latter point is for longer, following, discussion.) > > > > > > > > > > Il giorno mer 13 mar 2024 alle ore 11:23 Francisco Javier Tirado Sarti < > > ftira..

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

> Alex Porcelli > http://porcelli.me > > > On Wed, Mar 13, 2024 at 6:09 AM Francisco Javier Tirado Sarti < > ftira...@redhat.com> wrote: > > > After kie-tools, sorry. I think we are not embracing the fact that > > kogito-images depend on kie-tools, because we want

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

After kie-tools, sorry. I think we are not embracing the fact that kogito-images depend on kie-tools, because we want those images to include tools. On Wed, Mar 13, 2024 at 11:08 AM Francisco Javier Tirado Sarti < ftira...@redhat.com> wrote: > Hi Tiago, > It can be an alternat

Re: [PROPOSAL] Unblocking and releasing Apache KIE 10

Hi Tiago, It can be an alternative solution to move kn-plugin-workflow to kogito-images (so there is not longer dependency from tools to images) and then build kogito-images after kogito-tools? On Wed, Mar 13, 2024 at 11:01 AM Enrique Gonzalez Martinez < egonza...@apache.org> wrote: > +1 to

Re: [ANNOUNCEMENT] Removing the circular dependency between `kogito-apps` and `kie-tools`

etail, please ? > > Thanks! > > > Il giorno gio 7 mar 2024 alle ore 11:38 Francisco Javier Tirado Sarti < > ftira...@redhat.com> ha scritto: > > > What I'm trying to say is that changing the streams is probably better > than > > doing again what we did with t

Re: [ANNOUNCEMENT] Removing the circular dependency between `kogito-apps` and `kie-tools`

Sarti < ftira...@redhat.com> wrote: > So, is it possible to have the following build order (regardless of kie or > kogito prefix)? > 1) drools 2) runtimes 3) tools 4) images > > > > On Thu, Mar 7, 2024 at 10:51 AM Francisco Javier Tirado Sarti < > ftira...@redhat.co

Re: [ANNOUNCEMENT] Removing the circular dependency between `kogito-apps` and `kie-tools`

So, is it possible to have the following build order (regardless of kie or kogito prefix)? 1) drools 2) runtimes 3) tools 4) images On Thu, Mar 7, 2024 at 10:51 AM Francisco Javier Tirado Sarti < ftira...@redhat.com> wrote: > Hi Tiago, > Let's rewind a bit, if we ignore the kie and

Re: [ANNOUNCEMENT] Removing the circular dependency between `kogito-apps` and `kie-tools`

gt; > > Thanks for moving this forward. > > > > > > > > > > > > > > > > > > I have one thing to highlight with > > > > > > > > > https://github.com/apache/incubator-kie-kogito-images > > > > > > &g

Re: [HEADS UP] Renaming Kogito SW artifacts to KIE/SonataFlow starting

er to > > publish artifacts in maven and fullfil legal and tech stuff. > > > > For any other issue like package naming conventions issue a proposal > > please. Lets try to not mix things up here. > > > > El mié, 6 mar 2024, 10:53, Francisco Javier Tirado Sart

Re: [HEADS UP] Renaming Kogito SW artifacts to KIE/SonataFlow starting

Hi, Some side doubts after reading the issue comments. Which are exactly project component names? Where are they reflected? Are they the name in org.apache.kie.? Which is the plan for package name migration? Does the word should (Mark did not use must) give us certain freedom to keep the current

Re: [HEADS UP] Renaming Kogito SW artifacts to KIE/SonataFlow starting

Hi, Do we need to align modules names with Java package names? On Tue, Feb 27, 2024 at 1:29 PM ricardo zanini fernandes < ricardozan...@gmail.com> wrote: > Hi! > > I'd vote for "org.apache.sonataflow" if we must keep apache in the > namespace. Adding more levels will have huge classnames in the

Re: [ANNOUNCEMENT] Removing the circular dependency between `kogito-apps` and `kie-tools`

Hi Tiago, It was a nice morning reading ;) Thanks for all the time invested on such detailed writing. @Ricardo Zanini @Walter Medvedeo I guess dev ui can be removed from current examples, at least from the ones I'm familiar with, since their README files do not really require any graphical tool.

Re: [DISCUSSION] Performance issues with data-index persistence addon

idual instances deletion should be handled differently. > > On Thu, Feb 22, 2024 at 6:03 AM Francisco Javier Tirado Sarti < > ftira...@redhat.com> wrote: > > > Ok, so we have two flavours, clean up on demand through REST user call > > (that's fine, the only issue is th

Re: [DISCUSSION] Performance issues with data-index persistence addon

for more than X days > > or something like that). > > > > The use of cron is that an external cron could call the cleaning REST > > endpoint from time to time (once a month, on every sunday night, etc). > > > > > > On Wed, Feb 21, 2024 at 10:50 AM Francis

Re: [DISCUSSION] Performance issues with data-index persistence addon

the platform today is heavily invested in such > interface, so it might make sense. BUT I’d consider it in a second moment. > > > On Wed, Feb 21, 2024 at 6:52 AM Francisco Javier Tirado Sarti < > ftira...@redhat.com> wrote: > > > Hi Enrique, > > If we configure

Re: [DISCUSSION] Performance issues with data-index persistence addon

igned offering one simple responsibility but I > would be against mixing for instance job service with data index. > > El mié, 21 feb 2024 a las 12:13, Francisco Javier Tirado Sarti (< > ftira...@redhat.com>) escribió: > > > Hi Enrique, > > In the case of data index I

Re: [DISCUSSION] Performance issues with data-index persistence addon

ng event publishing is a different configuration than disabling > the data audit, correct? > If yes, are they both done in pom.xml + application.properties? > > Le mer. 21 févr. 2024, 06:03, Francisco Javier Tirado Sarti < > ftira...@redhat.com> a écrit : > > > Richard,

Re: [DISCUSSION] Performance issues with data-index persistence addon

it did in v7 > > with > > > > the emitters. The only difference between two impl is that in here > the > > > > storage is pgsql instead elastic search. You are right regarding is > a > > > > snapshot of the last state of the process but we did never define h

Re: [DISCUSSION] Performance issues with data-index persistence addon

NAL] Re: [DISCUSSION] Performance issues with > data-index > > > > persistence addon > > > > > > > > Hi Francisco, > > > > To give you more context about this. > > > > > > > > STP is a concept, a process with certain constraint

Re: [DISCUSSION] Performance issues with data-index persistence addon

; index or the audit. > > El lun, 19 feb 2024, 14:13, Francisco Javier Tirado Sarti < > ftira...@redhat.com> escribió: > > > Hi Alex, > > There has been some confusion about the purpose of DataIndex. To be > honest > > I believe they were already sorted out,

Re: [DISCUSSION] Performance issues with data-index persistence addon

a function that cannot be removed right now On Mon, Feb 19, 2024 at 1:33 PM Alex Porcelli wrote: > if data index was supposed to provide snapshot view of the process > instance… why do we keep it after the process instance is finished? > > > On Mon, Feb 19, 2024 at 7:12 AM Fran

Re: [DISCUSSION] Performance issues with data-index persistence addon

it will grow over time. What we need is some configurable purge mechanism for DataIndex, so it eventually removes older completed process instances. On Tue, Feb 13, 2024 at 12:59 PM Francisco Javier Tirado Sarti < ftira...@redhat.com> wrote: > Hi Martin, > Good catch!. Looks like

Re: [PROPOSAL] Renaming Kogito SW artifacts to KIE/SonataFlow

-addons-quarkus-microprofile-config-service-catalog > Python support for serverless workflow > org.kie.kogito:kogito-addons-quarkus-serverless-workflow-python > > > Thank you! > Pere > > On Wed, 14 Feb 2024 at 12:58, Francisco Javier Tirado Sarti < > ftira...@redhat.com&

Re: [PROPOSAL] Renaming Kogito SW artifacts to KIE/SonataFlow

: > Francisco, > > By Kris email, he stated that this is a blocker for release. But scoped to > only artifact name changes. > > > On Wed, Feb 14, 2024 at 6:38 AM Francisco Javier Tirado Sarti < > ftira...@redhat.com> wrote: > > > Sorry if this was mentioned previousl

Re: [PROPOSAL] Renaming Kogito SW artifacts to KIE/SonataFlow

gt; > The org.kie.kogito:kogito-quarkus I suggest to preserve and rename > to > >> > > org.jbpm:jbpm-with-drools - and not remove. > >> > > > >> > > And, for now I'd prefer to preserve all extensions, so not removing > >> > > the

Re: [DISCUSSION] Performance issues with data-index persistence addon

nce issues with data-index > persistence addon > > Great work Francisco, > Martin, take a look at this link with some related tips (in case you find > it useful): https://www.cybertec-postgresql.com/en/index-your-foreign-key/ > > El vie, 9 feb 2024 a las 17:20, Francisco Javier T

Re: [DISCUSSION] Performance issues with data-index persistence addon

ng :) So I would not -1 that myself. > > Tibor > > Dňa pi 9. 2. 2024, 17:00 Francisco Javier Tirado Sarti < > ftira...@redhat.com> > napísal(a): > > > Hi, > > Usually I do not want to talk about work in progress because preliminary > > conclusion

Re: [DISCUSSION] Performance issues with data-index persistence addon

inweiler/job-service-refactor-test/tree/mongodb > > [2] > > > https://drive.google.com/file/d/1NfacXaxJlgRMw4OQ5S20cvkzvaUKUVFj/view?usp=sharing > > > > > > From: Francisco Javier Tirado Sarti > > Sent: Wednesd

Re: [DISCUSSION] Performance issues with data-index persistence addon

would highly recommend to check indexes and how the updates work in data > index to avoid full scan table and lock the full table. Some db are very > sensitive to that. > > El mié, 7 feb 2024, 18:41, Francisco Javier Tirado Sarti < > ftira...@redhat.com> escribió: > > > Hi Ma

Re: [DISCUSSION] Performance issues with data-index persistence addon

r-test/ > [2] > https://drive.google.com/file/d/1Gqn-ixE05kXv2jdssAUlnMuUVcHxIYZ0/view?usp=sharing > [3] > https://drive.google.com/file/d/10gVNyb4JYg_bA18bNhY9dEDbPn3TOxL7/view?usp=sharing > [4] > https://drive.google.com/file/d/1jVrtsO49gCvUlnaC9AUAtkVKTm4PbdUv/view?usp=sharing >

Re: [PROPOSAL] Renaming Kogito SW artifacts to KIE/SonataFlow

eb 6, 2024 at 4:30 PM Alex Porcelli wrote: > > > I think the spreadsheet shared by Kris is missing quite some information, > > I’ll double check it and get back to this thread. > > > > Hopefully with the updates that are missing, we can clarify Francisco > > concer

Re: [PROPOSAL] Renaming Kogito SW artifacts to KIE/SonataFlow

nen I think we need some more concrete guidelines here. On Tue, Feb 6, 2024 at 12:37 PM Enrique Gonzalez Martinez < elguard...@gmail.com> wrote: > Hi, > > El mar, 6 feb 2024 a las 12:01, Francisco Javier Tirado Sarti > () escribió: > > > > Hi, > > I agree w

Re: [PROPOSAL] Renaming Kogito SW artifacts to KIE/SonataFlow

and try to refine it to > your best of your abilities so we can see exactly where the > disagreement lies and Kris (and other people) can engage in the > differences and how to reach a middleground. > > > El lun, 5 feb 2024 a las 20:15, Francisco Javier Tirado Sarti > (

Re: [PROPOSAL] Renaming Kogito SW artifacts to KIE/SonataFlow

o get the fully > functional workflow engine. > > El lun, 5 feb 2024, 18:11, ricardo zanini fernandes < > ricardozan...@gmail.com> > escribió: > > > +1, Javi > > > > On Mon, Feb 5, 2024 at 12:58 PM Francisco Javier Tirado Sarti < > > ftira...@redhat.com>

Re: [PROPOSAL] Renaming Kogito SW artifacts to KIE/SonataFlow

that are not mandatory but heavily recommended to have all functionality (job service and data index service) On Mon, Feb 5, 2024 at 4:54 PM Francisco Javier Tirado Sarti < ftira...@redhat.com> wrote: > Hi Kris, sounds good, but I have a question why is persistence considered > a suppor

Re: [PROPOSAL] Renaming Kogito SW artifacts to KIE/SonataFlow

Hi Kris, sounds good, but I have a question why is persistence considered a supporting service and messaging is not?. On Mon, Feb 5, 2024 at 4:44 PM Kris Verlaenen wrote: > All, > > Here's a slightly modified proposal to take the feedback so far into > account: the suggestion is to use Drools

Re: [HEADS UP] Legal issue with Oracle driver

> Hi Francisco: > > Answer inline: > > El mié, 31 ene 2024 a las 11:38, Francisco Javier Tirado Sarti > () escribió: > > > > Hi Brian > > If the code was not functional, I would agree. But the code is fully > > functional and we are planning to remove i

Re: [HEADS UP] Legal issue with Oracle driver

Hi Brian If the code was not functional, I would agree. But the code is fully functional and we are planning to remove it because of a controversial potential legal issue that, even with the more restricted view on that, only affects a dependency and its associated test. That's why my PR is

Re: [HEADS UP] Legal issue with Oracle driver

inally proposed. > > The original point to keep it was supposed that you could just drop in > classpath the jdbc driver and it would work, the current PR is far > from it. > > On Mon, Jan 29, 2024 at 11:03 AM Francisco Javier Tirado Sarti > wrote: > > > > And in an

Re: [HEADS UP] Legal issue with Oracle driver

And in any case the PR achieves what we intended, removing the driver and disabling the test. We already knew the final situation will be a code that is not tested. On Mon, Jan 29, 2024 at 4:58 PM Francisco Javier Tirado Sarti < ftira...@redhat.com> wrote: > Hi Alex, > I agree t

Re: [HEADS UP] Legal issue with Oracle driver

ts and code around, please? Are there any volunteers, who will > maintain > > those disabled tests and code around those and make sure it works? > > > > Best regards, > > Tibor > > > > Dňa po 29. 1. 2024, 15:43 Francisco Javier Tirado Sarti < >

  1   2   >