How to get a service call stack?

[Danny Trunk]

Hello,

let's imagine Service A is calling Service B directly through dispatcher.runSync and Service C is running as an SECA action of Service B. The call stack would be: Service A -> Service B -> Service C (through SECA)

Or let's imagine Service D is running as an EECA action of entity Product. The call stack would be: Product Entity -> Service D (through EECA)

Is it possible to get that information somehow?
I can't find anything helpful in DispatchContext or GenericDispatcher.

Output into a log file would be great.

Kind regards
Danny.

[Deepak Dixit-4]

Hi Danny Trunk,

Could you please share the use case why you need a service call stack?

If you share the use case it may be possible you will get a better answer.

Kind Regards,
Deepak Dixit
DIRECTOR OF PRODUCT ENGINEERING
mobile: [phone]
email: [hidden email]
*www.hotwax.co <http://www.hotwax.co/>*


On Thu, Feb 4, 2021 at 8:40 PM Danny Trunk <[hidden email]> wrote:

> Hello,
>
> let's imagine Service A is calling Service B directly through
> dispatcher.runSync and Service C is running as an SECA action of Service B.
> The call stack would be: Service A -> Service B -> Service C (through SECA)
>
> Or let's imagine Service D is running as an EECA action of entity Product.
> The call stack would be: Product Entity -> Service D (through EECA)
>
> Is it possible to get that information somehow?
> I can't find anything helpful in DispatchContext or GenericDispatcher.
>
> Output into a log file would be great.
>
> Kind regards
> Danny.
>

[Danny Trunk]

Hi Deepak Dixit,

the use case is debugging. There's a service getting called a lot and I can't find the origin while checking all the servicedef/entitydef XMLs. And I think it's quite useful to have such a feature.

Kind regards
Danny.

> Deepak Dixit <[hidden email]> hat am 04.02.2021 18:19 geschrieben:
>
>  
> Hi Danny Trunk,
>
> Could you please share the use case why you need a service call stack?
>
> If you share the use case it may be possible you will get a better answer.
>
> Kind Regards,
> Deepak Dixit
> DIRECTOR OF PRODUCT ENGINEERING
> mobile: [phone]
> email: [hidden email]
> *www.hotwax.co <http://www.hotwax.co/>*
>
>
> On Thu, Feb 4, 2021 at 8:40 PM Danny Trunk <[hidden email]> wrote:
>
> > Hello,
> >
> > let's imagine Service A is calling Service B directly through
> > dispatcher.runSync and Service C is running as an SECA action of Service B.
> > The call stack would be: Service A -> Service B -> Service C (through SECA)
> >
> > Or let's imagine Service D is running as an EECA action of entity Product.
> > The call stack would be: Product Entity -> Service D (through EECA)
> >
> > Is it possible to get that information somehow?
> > I can't find anything helpful in DispatchContext or GenericDispatcher.
> >
> > Output into a log file would be great.
> >
> > Kind regards
> > Danny.
> >

<pre>ZYRES digital media systems GmbH
Stuttgarter Straße 25 60329 Frankfurt am Main Phone [phone] - 0
Fax [phone] - 11

Firmensitz: Stuttgarter Straße 25 60329 Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
Geschäftsführer: Sebastian Schirmer

http://www.zyres.com/</pre>

[Nicolas Malin-2]

Hello Danny,

Currently you haven't solution instead analyze the timeline logs to
follow different service calls.

if an error raise, we haven't information on any java stack trace, so
you idea to implement a possibility to display a service call trace is a
nice idea.

Don't hesitate to open an issue if you have an idea to implement this.

Cheers

Nicolas

On 05/02/2021 08:38, Danny Trunk wrote:

> Hi Deepak Dixit,
>
> the use case is debugging. There's a service getting called a lot and I can't find the origin while checking all the servicedef/entitydef XMLs. And I think it's quite useful to have such a feature.
>
> Kind regards
> Danny.
>
>> Deepak Dixit <[hidden email]> hat am 04.02.2021 18:19 geschrieben:
>>
>>  
>> Hi Danny Trunk,
>>
>> Could you please share the use case why you need a service call stack?
>>
>> If you share the use case it may be possible you will get a better answer.
>>
>> Kind Regards,
>> Deepak Dixit
>> DIRECTOR OF PRODUCT ENGINEERING
>> mobile: [phone]
>> email: [hidden email]
>> *www.hotwax.co <http://www.hotwax.co/>*
>>
>>
>> On Thu, Feb 4, 2021 at 8:40 PM Danny Trunk <[hidden email]> wrote:
>>
>>> Hello,
>>>
>>> let's imagine Service A is calling Service B directly through
>>> dispatcher.runSync and Service C is running as an SECA action of Service B.
>>> The call stack would be: Service A -> Service B -> Service C (through SECA)
>>>
>>> Or let's imagine Service D is running as an EECA action of entity Product.
>>> The call stack would be: Product Entity -> Service D (through EECA)
>>>
>>> Is it possible to get that information somehow?
>>> I can't find anything helpful in DispatchContext or GenericDispatcher.
>>>
>>> Output into a log file would be great.
>>>
>>> Kind regards
>>> Danny.
>>>
> <pre>ZYRES digital media systems GmbH
> Stuttgarter Straße 25 60329 Frankfurt am Main Phone [phone] - 0
> Fax [phone] - 11
>
> Firmensitz: Stuttgarter Straße 25 60329 Frankfurt am Main
> Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
> Geschäftsführer: Sebastian Schirmer
>
> http://www.zyres.com/</pre>

[grv]

Hi Danny,

While this feature isn't available, you can just put a try catch (in the
service you think is getting called too much). In the try block, throw an
exception and in the catch just do printStackTrace(), you will get to know
where that service is getting called from.

This is of course an ugly solution but works especially if you're in the
development phase. That said, it would be a nice feature to have the
DispatchContext have information about current execution context.

Best Regards,
Girish





On Fri, Feb 5, 2021 at 1:08 PM Danny Trunk <[hidden email]> wrote:

> Hi Deepak Dixit,
>
> the use case is debugging. There's a service getting called a lot and I
> can't find the origin while checking all the servicedef/entitydef XMLs. And
> I think it's quite useful to have such a feature.
>
> Kind regards
> Danny.
>
> > Deepak Dixit <[hidden email]> hat am 04.02.2021 18:19
> geschrieben:
> >
> >
> > Hi Danny Trunk,
> >
> > Could you please share the use case why you need a service call stack?
> >
> > If you share the use case it may be possible you will get a better
> answer.
> >
> > Kind Regards,
> > Deepak Dixit
> > DIRECTOR OF PRODUCT ENGINEERING
> > mobile: [phone]
> > email: [hidden email]
> > *www.hotwax.co <http://www.hotwax.co/>*
> >
> >
> > On Thu, Feb 4, 2021 at 8:40 PM Danny Trunk <[hidden email]> wrote:
> >
> > > Hello,
> > >
> > > let's imagine Service A is calling Service B directly through
> > > dispatcher.runSync and Service C is running as an SECA action of
> Service B.
> > > The call stack would be: Service A -> Service B -> Service C (through
> SECA)
> > >
> > > Or let's imagine Service D is running as an EECA action of entity
> Product.
> > > The call stack would be: Product Entity -> Service D (through EECA)
> > >
> > > Is it possible to get that information somehow?
> > > I can't find anything helpful in DispatchContext or GenericDispatcher.
> > >
> > > Output into a log file would be great.
> > >
> > > Kind regards
> > > Danny.
> > >
>
> <pre>ZYRES digital media systems GmbH
> Stuttgarter Straße 25 60329 Frankfurt am Main Phone [phone] - 0
> Fax [phone] - 11
>
> Firmensitz: Stuttgarter Straße 25 60329 Frankfurt am Main
> Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
> Geschäftsführer: Sebastian Schirmer
>
> http://www.zyres.com/</pre>
>

[Danny Trunk]

Hi Girish,

I already put this into the service wrapper method right before the runSync call (dumpedStack is a static AtomicBoolean):

if (!dumpedStack.getAndSet(true)) {
        log.warn("Stack trace:\n{}", Arrays.stream(Thread.currentThread().getStackTrace()).map(StackTraceElement::toString).collect(Collectors.joining("\\n")));
}

But that's not really helpful because the information included doesn't contain service names and I don't think async service calls will be respected with that approach.

> Girish Vasmatkar <[hidden email]> hat am 05.02.2021 11:08 geschrieben:
>
>  
> Hi Danny,
>
> While this feature isn't available, you can just put a try catch (in the
> service you think is getting called too much). In the try block, throw an
> exception and in the catch just do printStackTrace(), you will get to know
> where that service is getting called from.
>
> This is of course an ugly solution but works especially if you're in the
> development phase. That said, it would be a nice feature to have the
> DispatchContext have information about current execution context.
>
> Best Regards,
> Girish
>
>
>
>
>
> On Fri, Feb 5, 2021 at 1:08 PM Danny Trunk <[hidden email]> wrote:
>
> > Hi Deepak Dixit,
> >
> > the use case is debugging. There's a service getting called a lot and I
> > can't find the origin while checking all the servicedef/entitydef XMLs. And
> > I think it's quite useful to have such a feature.
> >
> > Kind regards
> > Danny.
> >
> > > Deepak Dixit <[hidden email]> hat am 04.02.2021 18:19
> > geschrieben:
> > >
> > >
> > > Hi Danny Trunk,
> > >
> > > Could you please share the use case why you need a service call stack?
> > >
> > > If you share the use case it may be possible you will get a better
> > answer.
> > >
> > > Kind Regards,
> > > Deepak Dixit
> > > DIRECTOR OF PRODUCT ENGINEERING
> > > mobile: [phone]
> > > email: [hidden email]
> > > *www.hotwax.co <http://www.hotwax.co/>*
> > >
> > >
> > > On Thu, Feb 4, 2021 at 8:40 PM Danny Trunk <[hidden email]> wrote:
> > >
> > > > Hello,
> > > >
> > > > let's imagine Service A is calling Service B directly through
> > > > dispatcher.runSync and Service C is running as an SECA action of
> > Service B.
> > > > The call stack would be: Service A -> Service B -> Service C (through
> > SECA)
> > > >
> > > > Or let's imagine Service D is running as an EECA action of entity
> > Product.
> > > > The call stack would be: Product Entity -> Service D (through EECA)
> > > >
> > > > Is it possible to get that information somehow?
> > > > I can't find anything helpful in DispatchContext or GenericDispatcher.
> > > >
> > > > Output into a log file would be great.
> > > >
> > > > Kind regards
> > > > Danny.
> > > >
> >
> > <pre>ZYRES digital media systems GmbH
> > Stuttgarter Straße 25 60329 Frankfurt am Main Phone [phone] - 0
> > Fax [phone] - 11
> >
> > Firmensitz: Stuttgarter Straße 25 60329 Frankfurt am Main
> > Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
> > Geschäftsführer: Sebastian Schirmer
> >
> > http://www.zyres.com/</pre>
> >

<pre>ZYRES digital media systems GmbH
Stuttgarter Straße 25 60329 Frankfurt am Main Phone [phone] - 0
Fax [phone] - 11

Firmensitz: Stuttgarter Straße 25 60329 Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
Geschäftsführer: Sebastian Schirmer

http://www.zyres.com/</pre>

[Danny Trunk]

Hi Nicolas,

i will think about it and open an issue when i have an idea on how to implement it.

> Nicolas Malin <[hidden email]> hat am 05.02.2021 09:33 geschrieben:
>
>  
> Hello Danny,
>
> Currently you haven't solution instead analyze the timeline logs to
> follow different service calls.
>
> if an error raise, we haven't information on any java stack trace, so
> you idea to implement a possibility to display a service call trace is a
> nice idea.
>
> Don't hesitate to open an issue if you have an idea to implement this.
>
> Cheers
>
> Nicolas
>
> On 05/02/2021 08:38, Danny Trunk wrote:
> > Hi Deepak Dixit,
> >
> > the use case is debugging. There's a service getting called a lot and I can't find the origin while checking all the servicedef/entitydef XMLs. And I think it's quite useful to have such a feature.
> >
> > Kind regards
> > Danny.
> >
> >> Deepak Dixit <[hidden email]> hat am 04.02.2021 18:19 geschrieben:
> >>
> >>  
> >> Hi Danny Trunk,
> >>
> >> Could you please share the use case why you need a service call stack?
> >>
> >> If you share the use case it may be possible you will get a better answer.
> >>
> >> Kind Regards,
> >> Deepak Dixit
> >> DIRECTOR OF PRODUCT ENGINEERING
> >> mobile: [phone]
> >> email: [hidden email]
> >> *www.hotwax.co <http://www.hotwax.co/>*
> >>
> >>
> >> On Thu, Feb 4, 2021 at 8:40 PM Danny Trunk <[hidden email]> wrote:
> >>
> >>> Hello,
> >>>
> >>> let's imagine Service A is calling Service B directly through
> >>> dispatcher.runSync and Service C is running as an SECA action of Service B.
> >>> The call stack would be: Service A -> Service B -> Service C (through SECA)
> >>>
> >>> Or let's imagine Service D is running as an EECA action of entity Product.
> >>> The call stack would be: Product Entity -> Service D (through EECA)
> >>>
> >>> Is it possible to get that information somehow?
> >>> I can't find anything helpful in DispatchContext or GenericDispatcher.
> >>>
> >>> Output into a log file would be great.
> >>>
> >>> Kind regards
> >>> Danny.
> >>>
> > <pre>ZYRES digital media systems GmbH
> > Stuttgarter Straße 25 60329 Frankfurt am Main Phone [phone] - 0
> > Fax [phone] - 11
> >
> > Firmensitz: Stuttgarter Straße 25 60329 Frankfurt am Main
> > Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
> > Geschäftsführer: Sebastian Schirmer
> >
> > http://www.zyres.com/</pre>

<pre>ZYRES digital media systems GmbH
Stuttgarter Straße 25 60329 Frankfurt am Main Phone [phone] - 0
Fax [phone] - 11

Firmensitz: Stuttgarter Straße 25 60329 Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
Geschäftsführer: Sebastian Schirmer

http://www.zyres.com/</pre>

[Michael Brohl-3]

Hi Danny,

in such a case, I would simply search the codebase for the service name
to see where it is referenced.

In most cases, an eeca or seca is the cause for unexpected high
frequency service calls.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 05.02.21 um 11:58 schrieb Danny Trunk:

> Hi Girish,
>
> I already put this into the service wrapper method right before the runSync call (dumpedStack is a static AtomicBoolean):
>
> if (!dumpedStack.getAndSet(true)) {
> log.warn("Stack trace:\n{}", Arrays.stream(Thread.currentThread().getStackTrace()).map(StackTraceElement::toString).collect(Collectors.joining("\\n")));
> }
>
> But that's not really helpful because the information included doesn't contain service names and I don't think async service calls will be respected with that approach.
>
>> Girish Vasmatkar <[hidden email]> hat am 05.02.2021 11:08 geschrieben:
>>
>>  
>> Hi Danny,
>>
>> While this feature isn't available, you can just put a try catch (in the
>> service you think is getting called too much). In the try block, throw an
>> exception and in the catch just do printStackTrace(), you will get to know
>> where that service is getting called from.
>>
>> This is of course an ugly solution but works especially if you're in the
>> development phase. That said, it would be a nice feature to have the
>> DispatchContext have information about current execution context.
>>
>> Best Regards,
>> Girish
>>
>>
>>
>>
>>
>> On Fri, Feb 5, 2021 at 1:08 PM Danny Trunk <[hidden email]> wrote:
>>
>>> Hi Deepak Dixit,
>>>
>>> the use case is debugging. There's a service getting called a lot and I
>>> can't find the origin while checking all the servicedef/entitydef XMLs. And
>>> I think it's quite useful to have such a feature.
>>>
>>> Kind regards
>>> Danny.
>>>
>>>> Deepak Dixit <[hidden email]> hat am 04.02.2021 18:19
>>> geschrieben:
>>>>
>>>> Hi Danny Trunk,
>>>>
>>>> Could you please share the use case why you need a service call stack?
>>>>
>>>> If you share the use case it may be possible you will get a better
>>> answer.
>>>> Kind Regards,
>>>> Deepak Dixit
>>>> DIRECTOR OF PRODUCT ENGINEERING
>>>> mobile: [phone]
>>>> email: [hidden email]
>>>> *www.hotwax.co <http://www.hotwax.co/>*
>>>>
>>>>
>>>> On Thu, Feb 4, 2021 at 8:40 PM Danny Trunk <[hidden email]> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> let's imagine Service A is calling Service B directly through
>>>>> dispatcher.runSync and Service C is running as an SECA action of
>>> Service B.
>>>>> The call stack would be: Service A -> Service B -> Service C (through
>>> SECA)
>>>>> Or let's imagine Service D is running as an EECA action of entity
>>> Product.
>>>>> The call stack would be: Product Entity -> Service D (through EECA)
>>>>>
>>>>> Is it possible to get that information somehow?
>>>>> I can't find anything helpful in DispatchContext or GenericDispatcher.
>>>>>
>>>>> Output into a log file would be great.
>>>>>
>>>>> Kind regards
>>>>> Danny.
>>>>>
>>> <pre>ZYRES digital media systems GmbH
>>> Stuttgarter Straße 25 60329 Frankfurt am Main Phone [phone] - 0
>>> Fax [phone] - 11
>>>
>>> Firmensitz: Stuttgarter Straße 25 60329 Frankfurt am Main
>>> Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
>>> Geschäftsführer: Sebastian Schirmer
>>>
>>> http://www.zyres.com/</pre>
>>>
> <pre>ZYRES digital media systems GmbH
> Stuttgarter Straße 25 60329 Frankfurt am Main Phone [phone] - 0
> Fax [phone] - 11
>
> Firmensitz: Stuttgarter Straße 25 60329 Frankfurt am Main
> Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
> Geschäftsführer: Sebastian Schirmer
>
> http://www.zyres.com/</pre>

[Danny Trunk]

Hi Michael,

unfortunately i can't find the cause this way. That's why I asked for a service call stack. But it turned out that's a useful but not implemented feature.

> Michael Brohl <[hidden email]> hat am 05.02.2021 12:01 geschrieben:
>
>  
> Hi Danny,
>
> in such a case, I would simply search the codebase for the service name
> to see where it is referenced.
>
> In most cases, an eeca or seca is the cause for unexpected high
> frequency service calls.
>
> Best regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 05.02.21 um 11:58 schrieb Danny Trunk:
> > Hi Girish,
> >
> > I already put this into the service wrapper method right before the runSync call (dumpedStack is a static AtomicBoolean):
> >
> > if (!dumpedStack.getAndSet(true)) {
> > log.warn("Stack trace:\n{}", Arrays.stream(Thread.currentThread().getStackTrace()).map(StackTraceElement::toString).collect(Collectors.joining("\\n")));
> > }
> >
> > But that's not really helpful because the information included doesn't contain service names and I don't think async service calls will be respected with that approach.
> >
> >> Girish Vasmatkar <[hidden email]> hat am 05.02.2021 11:08 geschrieben:
> >>
> >>  
> >> Hi Danny,
> >>
> >> While this feature isn't available, you can just put a try catch (in the
> >> service you think is getting called too much). In the try block, throw an
> >> exception and in the catch just do printStackTrace(), you will get to know
> >> where that service is getting called from.
> >>
> >> This is of course an ugly solution but works especially if you're in the
> >> development phase. That said, it would be a nice feature to have the
> >> DispatchContext have information about current execution context.
> >>
> >> Best Regards,
> >> Girish
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Feb 5, 2021 at 1:08 PM Danny Trunk <[hidden email]> wrote:
> >>
> >>> Hi Deepak Dixit,
> >>>
> >>> the use case is debugging. There's a service getting called a lot and I
> >>> can't find the origin while checking all the servicedef/entitydef XMLs. And
> >>> I think it's quite useful to have such a feature.
> >>>
> >>> Kind regards
> >>> Danny.
> >>>
> >>>> Deepak Dixit <[hidden email]> hat am 04.02.2021 18:19
> >>> geschrieben:
> >>>>
> >>>> Hi Danny Trunk,
> >>>>
> >>>> Could you please share the use case why you need a service call stack?
> >>>>
> >>>> If you share the use case it may be possible you will get a better
> >>> answer.
> >>>> Kind Regards,
> >>>> Deepak Dixit
> >>>> DIRECTOR OF PRODUCT ENGINEERING
> >>>> mobile: [phone]
> >>>> email: [hidden email]
> >>>> *www.hotwax.co <http://www.hotwax.co/>*
> >>>>
> >>>>
> >>>> On Thu, Feb 4, 2021 at 8:40 PM Danny Trunk <[hidden email]> wrote:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> let's imagine Service A is calling Service B directly through
> >>>>> dispatcher.runSync and Service C is running as an SECA action of
> >>> Service B.
> >>>>> The call stack would be: Service A -> Service B -> Service C (through
> >>> SECA)
> >>>>> Or let's imagine Service D is running as an EECA action of entity
> >>> Product.
> >>>>> The call stack would be: Product Entity -> Service D (through EECA)
> >>>>>
> >>>>> Is it possible to get that information somehow?
> >>>>> I can't find anything helpful in DispatchContext or GenericDispatcher.
> >>>>>
> >>>>> Output into a log file would be great.
> >>>>>
> >>>>> Kind regards
> >>>>> Danny.
> >>>>>
> >>> <pre>ZYRES digital media systems GmbH
> >>> Stuttgarter Straße 25 60329 Frankfurt am Main Phone [phone] - 0
> >>> Fax [phone] - 11
> >>>
> >>> Firmensitz: Stuttgarter Straße 25 60329 Frankfurt am Main
> >>> Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
> >>> Geschäftsführer: Sebastian Schirmer
> >>>
> >>> http://www.zyres.com/</pre>
> >>>
> > <pre>ZYRES digital media systems GmbH
> > Stuttgarter Straße 25 60329 Frankfurt am Main Phone [phone] - 0
> > Fax [phone] - 11
> >
> > Firmensitz: Stuttgarter Straße 25 60329 Frankfurt am Main
> > Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
> > Geschäftsführer: Sebastian Schirmer
> >
> > http://www.zyres.com/</pre>

<pre>ZYRES digital media systems GmbH
Stuttgarter Straße 25 60329 Frankfurt am Main Phone [phone] - 0
Fax [phone] - 11

Firmensitz: Stuttgarter Straße 25 60329 Frankfurt am Main
Registergericht: Amtsgericht Frankfurt am Main, HRB 76374
Geschäftsführer: Sebastian Schirmer

http://www.zyres.com/</pre>

[James Yong-2]

Hi Danny,

This jira issue may be useful for you:
https://issues.apache.org/jira/browse/OFBIZ-10351

Regards,
James

On 2021/02/04 15:10:37, Danny Trunk <[hidden email]> wrote:

> Hello,
>
> let's imagine Service A is calling Service B directly through dispatcher.runSync and Service C is running as an SECA action of Service B. The call stack would be: Service A -> Service B -> Service C (through SECA)
>
> Or let's imagine Service D is running as an EECA action of entity Product. The call stack would be: Product Entity -> Service D (through EECA)
>
> Is it possible to get that information somehow?
> I can't find anything helpful in DispatchContext or GenericDispatcher.
>
> Output into a log file would be great.
>
> Kind regards
> Danny.
>