Improved the documentation in rev. 1735441 Jacopo
On Thu, Mar 17, 2016 at 11:17 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > +1, thanks Scott for the idea and explanation! > > Jacques > > > Le 17/03/2016 10:51, Jacopo Cappellato a écrit : > >> Thanks to all of you for your valuable feedback. >> >> For now we could, as recommended by Scott, improve the documentation to >> make it clear when and how the auth and in-validate events can safely be >> used(i.e. to call services that don't change the status of any system). >> >> Regards, >> >> Jacopo >> >> On Tue, Feb 23, 2016 at 11:41 PM, Scott Gray < >> scott.g...@hotwaxsystems.com> >> wrote: >> >> I've been aware of this for a while and always assumed that the intention >>> was for the auth and in-validate events to only use idempotent services >>> that exist to validate the service call. I don't mind if we remove them >>> for async calls but we do lose the feature that the caller is immediately >>> notified that the job they've executed isn't valid. >>> >>> The other option is to improve the documentation for these events so devs >>> aren't taken by surprise. >>> >>> Regards >>> Scott >>> >>> On 23 February 2016 at 22:59, Jacopo Cappellato < >>> jacopo.cappell...@hotwaxsystems.com> wrote: >>> >>> Taher, >>>> >>>> yours are all valid questions and I don't have a precise answer for >>>> them: >>>> it may be that it was done by design (as Gil said for example to allow >>>> >>> the >>> >>>> creation in the queue of "valid" jobs only) or just for a copy/paste >>>> pattern... >>>> >>>> Jacopo >>>> >>>> On Tue, Feb 23, 2016 at 10:35 AM, gil portenseigne < >>>> gil.portensei...@nereide.fr> wrote: >>>> >>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>>
