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 wrote:
> Hello,
>
> let's imagine Service A is calling Service B directly through
> dispatcher.runSync and Service C is running as an SECA
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 hat am 05.02.2021 12:01 geschrieben:
>
>
> Hi Danny,
>
> in such a case, I would simply search the codebase
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
Hi Nicolas,
i will think about it and open an issue when i have an idea on how to implement
it.
> Nicolas Malin 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
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{}",
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
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
