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 <
jacques.le.r...@les7arts.com> 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 <
jacopo.cappell...@hotwaxsystems.com> wrote:
Hi Taher,
yes you are in the right place: the proposal is to remove, from the
ServiceDispatcher.runAsync method, the code following the two comments:
// pre-auth ECA
and
// pre-validate ECA
Jacopo
On Tue, Feb 23, 2016 at 7:10 AM, Taher Alkhateeb <
slidingfilame...@gmail.com
wrote:
Hi Jacopo,
I'm trying to find where the logic described above is happening, am I
in
the right place at ServiceDispatcher on the runAsync method right next
to
the checking of pre-auth ECA rules?
Taher Alkhateeb
On Mon, Feb 22, 2016 at 5:45 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:
Hi all,
I am sharing here the result of an analysis that Nameet Jain and I did
to
figure out why, under some circumstances the same seca service was
executed
twice.
The problem is that, when a service is executed as "async" the secas
attached to the "auth" and "in-validate" events are executed two
times:
at
the time of the call and later at the time of execution.
Here are the details:
when you call a service using the async method the following events
occur
immediately (i.e. synchronously at the time of the call):
1) all SECAs with event="auth" are executed
2) the user authorization to call the service is checked
3) all SECAs with event="in-validate" are executed
4) the service input parameters are validated
5) the service is submitted for later execution (e.g. added to the
JobSandbox)
After some time, the job scheduler picks the job from the queue and
then
executes it with a *sync* call; at this point all the events that you
would
expect to be executed during a sync call occur:
1) all SECAs with event="auth" are executed
2) the user authorization to call the service is checked
3) all SECAs with event="in-validate" are executed
4) the service input parameters are validated
5) all SECAs with event="invoke" are executed
6) the service is executed
7) all SECAs with event="out-validate" are executed
8) the service output parameters are validated
9) all SECAs with event="return" are executed
10) there are also other SECAs that are scheduled for execution at
transaction level; the ones with events: "commit", "global-commit",
"global-commit-post-run", "global-rollback"
As you can see the steps #1, #2, #3 and #4 are executed twice when the
service is called with the runAsync method and specifically all the
SECAs
of events "auth" and "in-validate" are executed twice.
Proposed fix: we could simply remove the execution of "auth" and
"in-validate" secas when the async service is invoked, and defer their
execution at the time the service is actually executed (i.e. picked
from
the queue and run).
Any comments?
Jacopo
