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 < [email protected]> 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 > <[email protected]> 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 <[email protected] > > 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 > <[email protected]> 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 > > > >
