Jacques, the code that runs pre-invoke in runSync is quite different from the code in runAsync; on the other hand the first parts of the two methods in very similar.
Jacopo On Tue, Feb 23, 2016 at 11:13 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Yes, but then why only those cases? And why not pre-invoke for instance? > > Jacques > > > Le 23/02/2016 10:35, gil portenseigne a écrit : > >> Hi Taher, >> >> The only thing i can see around this matter is if the seca fail during >> invoke, no job is created ? >> >> My 0,02 cts >> >> Gil >> >> On 23/02/2016 10:27, Taher Alkhateeb wrote: >> >>> Hi Jacopo, >>> >>> So to understand correctly, you want to disable all SECA executions >>> (triggered by evalRules) when the call happens to runAsync. >>> >>> Any idea why it was there in the first place? It seems strange to have >>> such >>> a flaw in the design deep in the service engine. If an async service >>> eventually triggers all ECAs, why did anyone go through the effort of >>> putting that code in runAsync! BTW I'm not objecting to your proposal, >>> merely commenting on the oddness of having that piece of code in there in >>> the first place. >>> >>> Taher Alkhateeb >>> >>> On Tue, Feb 23, 2016 at 10:51 AM, Jacopo Cappellato < >>> jacopo.cappell...@hotwaxsystems.com> wrote: >>> >>> Hi Taher, >>>> >>>> yes you are in the right place: the proposal is to remove, from the >>>> ServiceDispatcher.runAsync method, the code following the two comments: >>>> >>>> // pre-auth ECA >>>> >>>> and >>>> >>>> // pre-validate ECA >>>> >>>> Jacopo >>>> >>>> On Tue, Feb 23, 2016 at 7:10 AM, Taher Alkhateeb < >>>> slidingfilame...@gmail.com >>>> >>>>> wrote: >>>>> Hi Jacopo, >>>>> >>>>> I'm trying to find where the logic described above is happening, am I >>>>> in >>>>> the right place at ServiceDispatcher on the runAsync method right next >>>>> to >>>>> the checking of pre-auth ECA rules? >>>>> >>>>> Taher Alkhateeb >>>>> >>>>> On Mon, Feb 22, 2016 at 5:45 PM, Jacopo Cappellato < >>>>> jacopo.cappell...@hotwaxsystems.com> wrote: >>>>> >>>>> Hi all, >>>>>> >>>>>> I am sharing here the result of an analysis that Nameet Jain and I did >>>>>> >>>>> to >>>> >>>>> figure out why, under some circumstances the same seca service was >>>>>> >>>>> executed >>>>> >>>>>> twice. >>>>>> >>>>>> The problem is that, when a service is executed as "async" the secas >>>>>> attached to the "auth" and "in-validate" events are executed two >>>>>> times: >>>>>> >>>>> at >>>>> >>>>>> the time of the call and later at the time of execution. >>>>>> >>>>>> Here are the details: >>>>>> >>>>>> when you call a service using the async method the following events >>>>>> >>>>> occur >>>> >>>>> immediately (i.e. synchronously at the time of the call): >>>>>> >>>>>> 1) all SECAs with event="auth" are executed >>>>>> 2) the user authorization to call the service is checked >>>>>> 3) all SECAs with event="in-validate" are executed >>>>>> 4) the service input parameters are validated >>>>>> 5) the service is submitted for later execution (e.g. added to the >>>>>> JobSandbox) >>>>>> >>>>>> After some time, the job scheduler picks the job from the queue and >>>>>> >>>>> then >>>> >>>>> executes it with a *sync* call; at this point all the events that you >>>>>> >>>>> would >>>>> >>>>>> expect to be executed during a sync call occur: >>>>>> >>>>>> 1) all SECAs with event="auth" are executed >>>>>> 2) the user authorization to call the service is checked >>>>>> 3) all SECAs with event="in-validate" are executed >>>>>> 4) the service input parameters are validated >>>>>> 5) all SECAs with event="invoke" are executed >>>>>> 6) the service is executed >>>>>> 7) all SECAs with event="out-validate" are executed >>>>>> 8) the service output parameters are validated >>>>>> 9) all SECAs with event="return" are executed >>>>>> 10) there are also other SECAs that are scheduled for execution at >>>>>> transaction level; the ones with events: "commit", "global-commit", >>>>>> "global-commit-post-run", "global-rollback" >>>>>> >>>>>> As you can see the steps #1, #2, #3 and #4 are executed twice when the >>>>>> service is called with the runAsync method and specifically all the >>>>>> >>>>> SECAs >>>> >>>>> of events "auth" and "in-validate" are executed twice. >>>>>> >>>>>> Proposed fix: we could simply remove the execution of "auth" and >>>>>> "in-validate" secas when the async service is invoked, and defer their >>>>>> execution at the time the service is actually executed (i.e. picked >>>>>> >>>>> from >>>> >>>>> the queue and run). >>>>>> >>>>>> Any comments? >>>>>> >>>>>> Jacopo >>>>>> >>>>>> >> >