Issue with in-validate secas executed twice when a service is invoked as async

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue with in-validate secas executed twice when a service is invoked as async

Jacopo Cappellato-5
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
Reply | Threaded
Open this post in threaded view
|

Re: Issue with in-validate secas executed twice when a service is invoked as async

Gil Portenseigne


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
>

Reply | Threaded
Open this post in threaded view
|

Re: Issue with in-validate secas executed twice when a service is invoked as async

taher
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
>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with in-validate secas executed twice when a service is invoked as async

Jacopo Cappellato-5
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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with in-validate secas executed twice when a service is invoked as async

taher
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
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with in-validate secas executed twice when a service is invoked as async

Gil Portenseigne
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


        

      

    

Reply | Threaded
Open this post in threaded view
|

Re: Issue with in-validate secas executed twice when a service is invoked as async

Jacopo Cappellato-5
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
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with in-validate secas executed twice when a service is invoked as async

Jacques Le Roux
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
>>>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Issue with in-validate secas executed twice when a service is invoked as async

Jacopo Cappellato-5
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
>>>>>>
>>>>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with in-validate secas executed twice when a service is invoked as async

Jacques Le Roux
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
>>>>>>>
>>>>>>>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with in-validate secas executed twice when a service is invoked as async

taher
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
>>>>>>>>
>>>>>>>>
>>>>>>>>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with in-validate secas executed twice when a service is invoked as async

Scott Gray-3
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
> >
> >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with in-validate secas executed twice when a service is invoked as async

Jacopo Cappellato-5
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
> > >
> > >
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with in-validate secas executed twice when a service is invoked as async

Jacques Le Roux
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
>>>>
>>>>
>>>>
>>>>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with in-validate secas executed twice when a service is invoked as async

Jacopo Cappellato-5
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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>