Skip to end of banner
Go to start of banner

IS advanced

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

This page discusses the requirements of an advanced invocation sequence sensor to be integrated with inspectIT.

Features

The following list contains that necessary features of the advanced invocation sequence tracer.

  • Continuous sending of invocation sequence data
  • Invocation sequences that span over multiple threads
  • Invocation sequences that span over multiple JVMs
  • Storage of the invocation sequences in memory and as files (if requested by the user)

Overview

Each invocation in Java always occur within one Thread. Within this thread an invocation may use methods of multiple classes. Inner Thread calls are all synchronous (read blocking) calls, thus the sequence is very strictly defined.

It is also possible that one thread calls another thread. This call is most likely an asynchronous call, in which the caller will not wait for the result. There is nearly no application that does not use multiple JVM instances and use communication between these JVMs.

The invocation sequence should provide the concrete user transaction over these boundaries. It thus provides the exact information necessary to understand why and where a concrete invocation is slow.

Analysis

In order to achieve the necessary functionality different topics needs to be addressed.

Unique identification of invocations

There are four different levels that affect the identification of invocations. These are (sequence starting from bottom to top):

Level

Section

Description

Link to the discussion of unique identification

1

Platform

The platform the agent is running on.

IS platform identification

2

JVM

On each platform can be multiple JVMs

IS JVM identification

3

"Thread"

Within each JVM different threads are run

IS thread identification

4

method

Within one thread a method can be invoked multiple times

 

Continuous Sending

  • Each invocation of a method checks if an invocation sequence is currently active
  • The staging area builds up a stack of all methods that are invoked within one "thread"
  • The data is sent to the CMR. Based on the JVM identification, the platform identification and the thread identification, the CMR can extend its stack of the methods of one invocation by adding the received stack to it. If no information is currently available, the CMR must assume that this was a new invocation.

Inner-Thread

Invocations within one thread are saved as a stack that is unique per thread identification. The invocation of an instrumented method within an invocation sequence will create two different information objects:

  • one at the start of the method and (method start)
  • one at the end of the method (method end)

Additional identification of the methods are not necessary as the invocations within the thread are always synchronous and thus the stack of the invocations will easily allow to reconstruct the invocation sequence.

Example

The following structure shows how the stack may look like (notice that in order to save space, the stack is created from left to right). This structure allows to reconstruct, that M1 called M2 and afterwards called M3.

M1 start

M2 start

M2 end

M3 start

M3 end

M1 end

Inter-Thread

Braindump

  • Each thread has a unique number (per JVM) automatically assigned
    • But threads can and - in fact are - reused. For example thread pools do not instantiate new threads, but instead pass different Runnable instances to the existing threads. Each different runnable is itself a different functionality. Thus the thread ID cannot be safely used for identification
  • To build up an invocation sequence, each invoked method must know the method that was invoked before it
    • Innerthread communication can simply make use of the ThreadLocal pattern and build a stack of the concrete methods being called
    • Interthread and inter JVM communication has to connect the stacks of the involved threads. This can be done by an invocation identifier that is passed from the caller to the callee.
      • Invocation identifier must also include the method identification that invoked this call
  • Continuous sending of information
    • Each method needs to have a thread-wide identification (stored within the stack)
    • Each invocation of a method must refer to the parent invocation
    • CMR server can match its current call tree with the information sent by the agent. Based on the invocation identification it will find the correct sequence. it will use the method identification to complete the tree

ID

unique across

Buildup

method invocation identification

  • at least within one invocation sequence
  • within on thread on one jvm
  • two calls to the same method must result in different ids

static counter
(within the same classloader static is safe -> is there a possibility that objects/classes within one thread are loaded by a different branch of a classloader hierarchy)

invocation sequence identification

  • everything (JVM, thread)

JVM_ID + Thread ID
thread id is not unique (thread pools!)
  • Active pushing of invocation sequence id from one thread to another
    • hard to realize: how do we know that the next method instrumented will be invoked in a new thread
    • at this point in time threadlocal information of the caller is no longer available
    • It would be necessary to extend the method signature of all methods of all classes that inherit Thread / Runnable with an additional information (the invocation sequence) ... still very unclear
  • Alternative would be to use JVM wide identification of the invocation sequence id with the respective thread

Questions

  • Aktuell spielt gaukelt der invocation sequence hook einem timer usw vor, dass er ein Coreservice ist, korrekt?
  • Wieso misst die invocation sequence selbst zusätzlich die Zeit? (oder tut sie das nur beim initialen Call gegen sich selbst?)

Jira tagging

  • No labels