Petals ESB Container

PetalsExecutionContext eats too much resources

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 5.0.1
  • Fix Version/s: 5.0.2
  • Component/s: None
  • Security Level: Public
  • Description:
    Hide

    ExecutionContext is used in PetalsExecutionContext, the main entry point to store flow-related information for logs.

    It is a MDC-like implementation using Properties objects.

    The problem with it is that it relies on a recursive Properties objects: every time a thread is created, a new Properties object is created (this is ok) using the previous thread as a parent (this is not ok).

    When used in Thread pools, often threads of the pool are responsible of creating new threads, and thus after a long time, we can find ourselves with a very long chain of inheriting Properties object, and after a very very long time, this can result in StackOverflowError when trying to resolve properties in them.

    Hence, we should switch from the use of ExecutionContext to a better MDC implementation, such as the one provided by default by SLF4J, since it is a future plan to switch to SLF4J (PETALSDISTRIB-135).

    Show
    ExecutionContext is used in PetalsExecutionContext, the main entry point to store flow-related information for logs. It is a MDC-like implementation using Properties objects. The problem with it is that it relies on a recursive Properties objects: every time a thread is created, a new Properties object is created (this is ok) using the previous thread as a parent (this is not ok). When used in Thread pools, often threads of the pool are responsible of creating new threads, and thus after a long time, we can find ourselves with a very long chain of inheriting Properties object, and after a very very long time, this can result in StackOverflowError when trying to resolve properties in them. Hence, we should switch from the use of ExecutionContext to a better MDC implementation, such as the one provided by default by SLF4J, since it is a future plan to switch to SLF4J (PETALSDISTRIB-135).
  • Environment:
    -

Issue Links

Activity

Hide
Victor NOËL added a comment - Tue, 31 May 2016 - 13:17:32 +0200

Solution is thus to to include slf4j-jdk14 in the system classloader: it is an implementation for slf4j that redirects all slf4j logs to JUL and that provides a basic but mature MDC implementation.

Note that we only need the MDC implementation for this issue, but since there is potentially dependencies in the kernel and in the components that relies on slf4j, slf4j-jdk14 will be already present in the system classloader and this will remove the need to include it in each components or the kernel (see PETALSDISTRIB-256 for more about that).

Show
Victor NOËL added a comment - Tue, 31 May 2016 - 13:17:32 +0200 Solution is thus to to include slf4j-jdk14 in the system classloader: it is an implementation for slf4j that redirects all slf4j logs to JUL and that provides a basic but mature MDC implementation. Note that we only need the MDC implementation for this issue, but since there is potentially dependencies in the kernel and in the components that relies on slf4j, slf4j-jdk14 will be already present in the system classloader and this will remove the need to include it in each components or the kernel (see PETALSDISTRIB-256 for more about that).

People

Dates

  • Created:
    Tue, 31 May 2016 - 13:14:09 +0200
    Updated:
    Wed, 1 Jun 2016 - 11:21:08 +0200
    Resolved:
    Wed, 1 Jun 2016 - 11:21:08 +0200