You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ja...@hotwaxsystems.com> on 2016/03/17 10:51:03 UTC
Re: Issue with in-validate secas executed twice when a service is
invoked as async
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 <sc...@hotwaxsystems.com>
wrote:
> I've been aware of this for a while and always assumed that the intention
> was for the auth and in-validate events to only use idempotent services
> that exist to validate the service call. I don't mind if we remove them
> for async calls but we do lose the feature that the caller is immediately
> notified that the job they've executed isn't valid.
>
> The other option is to improve the documentation for these events so devs
> aren't taken by surprise.
>
> Regards
> Scott
>
> On 23 February 2016 at 22:59, Jacopo Cappellato <
> jacopo.cappellato@hotwaxsystems.com> wrote:
>
> > Taher,
> >
> > yours are all valid questions and I don't have a precise answer for them:
> > it may be that it was done by design (as Gil said for example to allow
> the
> > creation in the queue of "valid" jobs only) or just for a copy/paste
> > pattern...
> >
> > Jacopo
> >
> > On Tue, Feb 23, 2016 at 10:35 AM, gil portenseigne <
> > gil.portenseigne@nereide.fr> wrote:
> >
> > > Hi Taher,
> > >
> > > The only thing i can see around this matter is if the seca fail during
> > > invoke, no job is created ?
> > >
> > > My 0,02 cts
> > >
> > > Gil
> > >
> > > On 23/02/2016 10:27, Taher Alkhateeb wrote:
> > >
> > > Hi Jacopo,
> > >
> > > So to understand correctly, you want to disable all SECA executions
> > > (triggered by evalRules) when the call happens to runAsync.
> > >
> > > Any idea why it was there in the first place? It seems strange to have
> > such
> > > a flaw in the design deep in the service engine. If an async service
> > > eventually triggers all ECAs, why did anyone go through the effort of
> > > putting that code in runAsync! BTW I'm not objecting to your proposal,
> > > merely commenting on the oddness of having that piece of code in there
> in
> > > the first place.
> > >
> > > Taher Alkhateeb
> > >
> > > On Tue, Feb 23, 2016 at 10:51 AM, Jacopo Cappellato <
> > jacopo.cappellato@hotwaxsystems.com> wrote:
> > >
> > >
> > > Hi Taher,
> > >
> > > yes you are in the right place: the proposal is to remove, from the
> > > ServiceDispatcher.runAsync method, the code following the two comments:
> > >
> > > // pre-auth ECA
> > >
> > > and
> > >
> > > // pre-validate ECA
> > >
> > > Jacopo
> > >
> > > On Tue, Feb 23, 2016 at 7:10 AM, Taher Alkhateeb <
> > slidingfilaments@gmail.com
> > >
> > > wrote:
> > >
> > > Hi Jacopo,
> > >
> > > I'm trying to find where the logic described above is happening, am I
> in
> > > the right place at ServiceDispatcher on the runAsync method right next
> to
> > > the checking of pre-auth ECA rules?
> > >
> > > Taher Alkhateeb
> > >
> > > On Mon, Feb 22, 2016 at 5:45 PM, Jacopo Cappellato <
> > jacopo.cappellato@hotwaxsystems.com> wrote:
> > >
> > >
> > > Hi all,
> > >
> > > I am sharing here the result of an analysis that Nameet Jain and I did
> > >
> > > to
> > >
> > > figure out why, under some circumstances the same seca service was
> > >
> > > executed
> > >
> > > twice.
> > >
> > > The problem is that, when a service is executed as "async" the secas
> > > attached to the "auth" and "in-validate" events are executed two times:
> > >
> > > at
> > >
> > > the time of the call and later at the time of execution.
> > >
> > > Here are the details:
> > >
> > > when you call a service using the async method the following events
> > >
> > > occur
> > >
> > > immediately (i.e. synchronously at the time of the call):
> > >
> > > 1) all SECAs with event="auth" are executed
> > > 2) the user authorization to call the service is checked
> > > 3) all SECAs with event="in-validate" are executed
> > > 4) the service input parameters are validated
> > > 5) the service is submitted for later execution (e.g. added to the
> > > JobSandbox)
> > >
> > > After some time, the job scheduler picks the job from the queue and
> > >
> > > then
> > >
> > > executes it with a *sync* call; at this point all the events that you
> > >
> > > would
> > >
> > > expect to be executed during a sync call occur:
> > >
> > > 1) all SECAs with event="auth" are executed
> > > 2) the user authorization to call the service is checked
> > > 3) all SECAs with event="in-validate" are executed
> > > 4) the service input parameters are validated
> > > 5) all SECAs with event="invoke" are executed
> > > 6) the service is executed
> > > 7) all SECAs with event="out-validate" are executed
> > > 8) the service output parameters are validated
> > > 9) all SECAs with event="return" are executed
> > > 10) there are also other SECAs that are scheduled for execution at
> > > transaction level; the ones with events: "commit", "global-commit",
> > > "global-commit-post-run", "global-rollback"
> > >
> > > As you can see the steps #1, #2, #3 and #4 are executed twice when the
> > > service is called with the runAsync method and specifically all the
> > >
> > > SECAs
> > >
> > > of events "auth" and "in-validate" are executed twice.
> > >
> > > Proposed fix: we could simply remove the execution of "auth" and
> > > "in-validate" secas when the async service is invoked, and defer their
> > > execution at the time the service is actually executed (i.e. picked
> > >
> > > from
> > >
> > > the queue and run).
> > >
> > > Any comments?
> > >
> > > Jacopo
> > >
> > >
> > >
> > >
> >
>
Re: Issue with in-validate secas executed twice when a service is
invoked as async
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
Improved the documentation in rev. 1735441
Jacopo
On Thu, Mar 17, 2016 at 11:17 AM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> +1, thanks Scott for the idea and explanation!
>
> Jacques
>
>
> Le 17/03/2016 10:51, Jacopo Cappellato a écrit :
>
>> Thanks to all of you for your valuable feedback.
>>
>> For now we could, as recommended by Scott, improve the documentation to
>> make it clear when and how the auth and in-validate events can safely be
>> used(i.e. to call services that don't change the status of any system).
>>
>> Regards,
>>
>> Jacopo
>>
>> On Tue, Feb 23, 2016 at 11:41 PM, Scott Gray <
>> scott.gray@hotwaxsystems.com>
>> wrote:
>>
>> I've been aware of this for a while and always assumed that the intention
>>> was for the auth and in-validate events to only use idempotent services
>>> that exist to validate the service call. I don't mind if we remove them
>>> for async calls but we do lose the feature that the caller is immediately
>>> notified that the job they've executed isn't valid.
>>>
>>> The other option is to improve the documentation for these events so devs
>>> aren't taken by surprise.
>>>
>>> Regards
>>> Scott
>>>
>>> On 23 February 2016 at 22:59, Jacopo Cappellato <
>>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>>
>>> Taher,
>>>>
>>>> yours are all valid questions and I don't have a precise answer for
>>>> them:
>>>> it may be that it was done by design (as Gil said for example to allow
>>>>
>>> the
>>>
>>>> creation in the queue of "valid" jobs only) or just for a copy/paste
>>>> pattern...
>>>>
>>>> Jacopo
>>>>
>>>> On Tue, Feb 23, 2016 at 10:35 AM, gil portenseigne <
>>>> gil.portenseigne@nereide.fr> wrote:
>>>>
>>>> Hi Taher,
>>>>>
>>>>> The only thing i can see around this matter is if the seca fail during
>>>>> invoke, no job is created ?
>>>>>
>>>>> My 0,02 cts
>>>>>
>>>>> Gil
>>>>>
>>>>> On 23/02/2016 10:27, Taher Alkhateeb wrote:
>>>>>
>>>>> Hi Jacopo,
>>>>>
>>>>> So to understand correctly, you want to disable all SECA executions
>>>>> (triggered by evalRules) when the call happens to runAsync.
>>>>>
>>>>> Any idea why it was there in the first place? It seems strange to have
>>>>>
>>>> such
>>>>
>>>>> a flaw in the design deep in the service engine. If an async service
>>>>> eventually triggers all ECAs, why did anyone go through the effort of
>>>>> putting that code in runAsync! BTW I'm not objecting to your proposal,
>>>>> merely commenting on the oddness of having that piece of code in there
>>>>>
>>>> in
>>>
>>>> the first place.
>>>>>
>>>>> Taher Alkhateeb
>>>>>
>>>>> On Tue, Feb 23, 2016 at 10:51 AM, Jacopo Cappellato <
>>>>>
>>>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>>>
>>>>>
>>>>> Hi Taher,
>>>>>
>>>>> yes you are in the right place: the proposal is to remove, from the
>>>>> ServiceDispatcher.runAsync method, the code following the two comments:
>>>>>
>>>>> // pre-auth ECA
>>>>>
>>>>> and
>>>>>
>>>>> // pre-validate ECA
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Tue, Feb 23, 2016 at 7:10 AM, Taher Alkhateeb <
>>>>>
>>>> slidingfilaments@gmail.com
>>>>
>>>>> wrote:
>>>>>
>>>>> Hi Jacopo,
>>>>>
>>>>> I'm trying to find where the logic described above is happening, am I
>>>>>
>>>> in
>>>
>>>> the right place at ServiceDispatcher on the runAsync method right next
>>>>>
>>>> to
>>>
>>>> the checking of pre-auth ECA rules?
>>>>>
>>>>> Taher Alkhateeb
>>>>>
>>>>> On Mon, Feb 22, 2016 at 5:45 PM, Jacopo Cappellato <
>>>>>
>>>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I am sharing here the result of an analysis that Nameet Jain and I did
>>>>>
>>>>> to
>>>>>
>>>>> figure out why, under some circumstances the same seca service was
>>>>>
>>>>> executed
>>>>>
>>>>> twice.
>>>>>
>>>>> The problem is that, when a service is executed as "async" the secas
>>>>> attached to the "auth" and "in-validate" events are executed two times:
>>>>>
>>>>> at
>>>>>
>>>>> the time of the call and later at the time of execution.
>>>>>
>>>>> Here are the details:
>>>>>
>>>>> when you call a service using the async method the following events
>>>>>
>>>>> occur
>>>>>
>>>>> immediately (i.e. synchronously at the time of the call):
>>>>>
>>>>> 1) all SECAs with event="auth" are executed
>>>>> 2) the user authorization to call the service is checked
>>>>> 3) all SECAs with event="in-validate" are executed
>>>>> 4) the service input parameters are validated
>>>>> 5) the service is submitted for later execution (e.g. added to the
>>>>> JobSandbox)
>>>>>
>>>>> After some time, the job scheduler picks the job from the queue and
>>>>>
>>>>> then
>>>>>
>>>>> executes it with a *sync* call; at this point all the events that you
>>>>>
>>>>> would
>>>>>
>>>>> expect to be executed during a sync call occur:
>>>>>
>>>>> 1) all SECAs with event="auth" are executed
>>>>> 2) the user authorization to call the service is checked
>>>>> 3) all SECAs with event="in-validate" are executed
>>>>> 4) the service input parameters are validated
>>>>> 5) all SECAs with event="invoke" are executed
>>>>> 6) the service is executed
>>>>> 7) all SECAs with event="out-validate" are executed
>>>>> 8) the service output parameters are validated
>>>>> 9) all SECAs with event="return" are executed
>>>>> 10) there are also other SECAs that are scheduled for execution at
>>>>> transaction level; the ones with events: "commit", "global-commit",
>>>>> "global-commit-post-run", "global-rollback"
>>>>>
>>>>> As you can see the steps #1, #2, #3 and #4 are executed twice when the
>>>>> service is called with the runAsync method and specifically all the
>>>>>
>>>>> SECAs
>>>>>
>>>>> of events "auth" and "in-validate" are executed twice.
>>>>>
>>>>> Proposed fix: we could simply remove the execution of "auth" and
>>>>> "in-validate" secas when the async service is invoked, and defer their
>>>>> execution at the time the service is actually executed (i.e. picked
>>>>>
>>>>> from
>>>>>
>>>>> the queue and run).
>>>>>
>>>>> Any comments?
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
Re: Issue with in-validate secas executed twice when a service is
invoked as async
Posted by Jacques Le Roux <ja...@les7arts.com>.
+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 <sc...@hotwaxsystems.com>
> wrote:
>
>> I've been aware of this for a while and always assumed that the intention
>> was for the auth and in-validate events to only use idempotent services
>> that exist to validate the service call. I don't mind if we remove them
>> for async calls but we do lose the feature that the caller is immediately
>> notified that the job they've executed isn't valid.
>>
>> The other option is to improve the documentation for these events so devs
>> aren't taken by surprise.
>>
>> Regards
>> Scott
>>
>> On 23 February 2016 at 22:59, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>
>>> Taher,
>>>
>>> yours are all valid questions and I don't have a precise answer for them:
>>> it may be that it was done by design (as Gil said for example to allow
>> the
>>> creation in the queue of "valid" jobs only) or just for a copy/paste
>>> pattern...
>>>
>>> Jacopo
>>>
>>> On Tue, Feb 23, 2016 at 10:35 AM, gil portenseigne <
>>> gil.portenseigne@nereide.fr> wrote:
>>>
>>>> Hi Taher,
>>>>
>>>> The only thing i can see around this matter is if the seca fail during
>>>> invoke, no job is created ?
>>>>
>>>> My 0,02 cts
>>>>
>>>> Gil
>>>>
>>>> On 23/02/2016 10:27, Taher Alkhateeb wrote:
>>>>
>>>> Hi Jacopo,
>>>>
>>>> So to understand correctly, you want to disable all SECA executions
>>>> (triggered by evalRules) when the call happens to runAsync.
>>>>
>>>> Any idea why it was there in the first place? It seems strange to have
>>> such
>>>> a flaw in the design deep in the service engine. If an async service
>>>> eventually triggers all ECAs, why did anyone go through the effort of
>>>> putting that code in runAsync! BTW I'm not objecting to your proposal,
>>>> merely commenting on the oddness of having that piece of code in there
>> in
>>>> the first place.
>>>>
>>>> Taher Alkhateeb
>>>>
>>>> On Tue, Feb 23, 2016 at 10:51 AM, Jacopo Cappellato <
>>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>>>
>>>> Hi Taher,
>>>>
>>>> yes you are in the right place: the proposal is to remove, from the
>>>> ServiceDispatcher.runAsync method, the code following the two comments:
>>>>
>>>> // pre-auth ECA
>>>>
>>>> and
>>>>
>>>> // pre-validate ECA
>>>>
>>>> Jacopo
>>>>
>>>> On Tue, Feb 23, 2016 at 7:10 AM, Taher Alkhateeb <
>>> slidingfilaments@gmail.com
>>>> wrote:
>>>>
>>>> Hi Jacopo,
>>>>
>>>> I'm trying to find where the logic described above is happening, am I
>> in
>>>> the right place at ServiceDispatcher on the runAsync method right next
>> to
>>>> the checking of pre-auth ECA rules?
>>>>
>>>> Taher Alkhateeb
>>>>
>>>> On Mon, Feb 22, 2016 at 5:45 PM, Jacopo Cappellato <
>>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I am sharing here the result of an analysis that Nameet Jain and I did
>>>>
>>>> to
>>>>
>>>> figure out why, under some circumstances the same seca service was
>>>>
>>>> executed
>>>>
>>>> twice.
>>>>
>>>> The problem is that, when a service is executed as "async" the secas
>>>> attached to the "auth" and "in-validate" events are executed two times:
>>>>
>>>> at
>>>>
>>>> the time of the call and later at the time of execution.
>>>>
>>>> Here are the details:
>>>>
>>>> when you call a service using the async method the following events
>>>>
>>>> occur
>>>>
>>>> immediately (i.e. synchronously at the time of the call):
>>>>
>>>> 1) all SECAs with event="auth" are executed
>>>> 2) the user authorization to call the service is checked
>>>> 3) all SECAs with event="in-validate" are executed
>>>> 4) the service input parameters are validated
>>>> 5) the service is submitted for later execution (e.g. added to the
>>>> JobSandbox)
>>>>
>>>> After some time, the job scheduler picks the job from the queue and
>>>>
>>>> then
>>>>
>>>> executes it with a *sync* call; at this point all the events that you
>>>>
>>>> would
>>>>
>>>> expect to be executed during a sync call occur:
>>>>
>>>> 1) all SECAs with event="auth" are executed
>>>> 2) the user authorization to call the service is checked
>>>> 3) all SECAs with event="in-validate" are executed
>>>> 4) the service input parameters are validated
>>>> 5) all SECAs with event="invoke" are executed
>>>> 6) the service is executed
>>>> 7) all SECAs with event="out-validate" are executed
>>>> 8) the service output parameters are validated
>>>> 9) all SECAs with event="return" are executed
>>>> 10) there are also other SECAs that are scheduled for execution at
>>>> transaction level; the ones with events: "commit", "global-commit",
>>>> "global-commit-post-run", "global-rollback"
>>>>
>>>> As you can see the steps #1, #2, #3 and #4 are executed twice when the
>>>> service is called with the runAsync method and specifically all the
>>>>
>>>> SECAs
>>>>
>>>> of events "auth" and "in-validate" are executed twice.
>>>>
>>>> Proposed fix: we could simply remove the execution of "auth" and
>>>> "in-validate" secas when the async service is invoked, and defer their
>>>> execution at the time the service is actually executed (i.e. picked
>>>>
>>>> from
>>>>
>>>> the queue and run).
>>>>
>>>> Any comments?
>>>>
>>>> Jacopo
>>>>
>>>>
>>>>
>>>>