1

I am developing a Java application that reads data from a Redis Database, I use Lettuce library to connect to Redis which in turn uses 'Netty' library to communicate with Redis I suspect that the execution time of my application is greater than expected, so a conducted a profiling experiment using JProfiler, I was surprised that a FastThreadLocalRunnable takes a significant portion of the execution time with no justification as the tree shows no function calls taking time:

Screenshot from JProfiler after some long time of execution

So, is it a bug in Lettuce library?, or is it a problem in the profiler measuring the execution time?

Any help is appreciated

Edit:

Thanks to Ingo's answer I can now expand the tree but it turns out that the java NIO is consuming my processor:

Java NIO is taking the processing power

Any idea?

ammcom
  • 992
  • 1
  • 7
  • 24

1 Answers1

2

The call tree in JProfiler only shows classes that are included in the call tree filters that you define in the profiling settings:

enter image description here

By default, this excludes a lot of common frameworks and libraries so that you can get started without configuring anything. It is better if you delete these filters and add your own profiled packages here.

In addition to the profiled classes, JProfiler shows the thread entry point even it is not a profiled class, such as io.netty.util.concurrent.FastThreadLocalRunnable. Also, the first call into non-profiled classes is always shown at any level in the call tree.

In your case there are call chains to non-profiled classes below io.netty.util.concurrent.FastThreadLocalRunnable that never call a profiled class. They could belong to some framework or to some part of your code that is not included in the profiled classes. This time has to go somewhere, so it is attributed to the io.netty.util.concurrent.FastThreadLocalRunnable node.

An easy way to check is to disable filtering in the profiling settings, then you see all classes.

enter image description here

More information about call tree filters can be found at

https://www.ej-technologies.com/resources/jprofiler/help/doc/main/methodCallRecording.html

Ingo Kegel
  • 46,523
  • 10
  • 71
  • 102
  • Thank you for your answer, deleting the filter reveals the real cause that is the NIO selector which is really weird, should Java NIO consume that much CPU power? – ammcom Jun 13 '22 at 14:32
  • The JVM does not reports these methods as non-blocking, so JProfiler builds it own Net I/O thread state for that. Since JProfiler 11 this method is part of the Net I/O thread state and should not show in the "Runnable" thread state in this way. Can you try it with the current version of JProfiler? – Ingo Kegel Jun 13 '22 at 15:05