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 |
On 22/02/2016 15:45, Jacopo Cappellato wrote: [...] > 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? It seems the good way to fix it, seca should only be run during the real execution of the service. I don't see any interest in executing seca during invoke. Gil > > Jacopo > |
In reply to this post by Jacopo Cappellato-5
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 < [hidden email]> 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 > |
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 <[hidden email] > 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 < > [hidden email]> 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 > > > |
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 < [hidden email]> 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 < > [hidden email] > > 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 < > > [hidden email]> 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 > > > > > > |
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 < [hidden email]> 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 < [hidden email]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 < [hidden email]> wrote:Hi all, I am sharing here the result of an analysis that Nameet Jain and I didtofigure out why, under some circumstances the same seca service wasexecutedtwice. 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:atthe 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 eventsoccurimmediately (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 andthenexecutes it with a *sync* call; at this point all the events that youwouldexpect 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 theSECAsof 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. pickedfromthe queue and run). Any comments? Jacopo |
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 < [hidden email]> 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 <[hidden email]> 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 <[hidden email] > > 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 <[hidden email]> 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 > > > > |
Administrator
|
In reply to this post by Gil Portenseigne
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 < >> [hidden email]> 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 < >>> [hidden email] >>>> 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 < >>>> [hidden email]> 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 >>>>> > |
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 < [hidden email]> 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 < >>> [hidden email]> 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 < >>>> [hidden email] >>>> >>>>> 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 < >>>>> [hidden email]> 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 >>>>>> >>>>>> >> > |
Administrator
|
Yes exactly my thoughts: it could be a C/P error, but it's still weird. Maybe a refactoring was done at some point and this was forgotten.
Note: this code is pre Apache era Jacques Le 23/02/2016 11:46, Jacopo Cappellato a écrit : > 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 < > [hidden email]> 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 < >>>> [hidden email]> 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 < >>>>> [hidden email] >>>>> >>>>>> 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 < >>>>>> [hidden email]> 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 >>>>>>> >>>>>>> |
This issue is exactly the reason why the refactoring thread issued by
Sharan is important. Quite honestly looking at that code gave me sore eyes and the whole thing needs refactoring. Sorry to deviate. Anyway I think we all sort of agree on the solution. Taher Alkhateeb On Feb 23, 2016 2:02 PM, "Jacques Le Roux" <[hidden email]> wrote: > Yes exactly my thoughts: it could be a C/P error, but it's still weird. > Maybe a refactoring was done at some point and this was forgotten. > > Note: this code is pre Apache era > > Jacques > > Le 23/02/2016 11:46, Jacopo Cappellato a écrit : > >> 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 < >> [hidden email]> 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 < >>>>> [hidden email]> 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 < >>>>>> [hidden email] >>>>>> >>>>>> 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 < >>>>>>> [hidden email]> 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 >>>>>>>> >>>>>>>> >>>>>>>> |
In reply to this post by Jacopo Cappellato-5
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 < [hidden email]> 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 < > [hidden email]> 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 < > [hidden email]> 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 < > [hidden email] > > > > 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 < > [hidden email]> 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 > > > > > > > > > |
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 <[hidden email]> 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 < > [hidden email]> 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 < > > [hidden email]> 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 < > > [hidden email]> 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 < > > [hidden email] > > > > > > 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 < > > [hidden email]> 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 > > > > > > > > > > > > > > > |
Administrator
|
+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 <[hidden email]> > 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 < >> [hidden email]> 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 < >>> [hidden email]> 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 < >>> [hidden email]> 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 < >>> [hidden email] >>>> 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 < >>> [hidden email]> 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 >>>> >>>> >>>> >>>> |
Improved the documentation in rev. 1735441
Jacopo On Thu, Mar 17, 2016 at 11:17 AM, Jacques Le Roux < [hidden email]> 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 < >> [hidden email]> >> 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 < >>> [hidden email]> 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 < >>>> [hidden email]> 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 < >>>>> >>>> [hidden email]> 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 < >>>>> >>>> [hidden email] >>>> >>>>> 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 < >>>>> >>>> [hidden email]> 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 >>>>> >>>>> >>>>> >>>>> >>>>> |
Free forum by Nabble | Edit this page |