Project

General

Profile

Bug #773

LTTng JUL JNI handler does not distinguish between sessions

Added by Mathieu Desnoyers about 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
Start date:
03/25/2014
Due date:
% Done:

100%

Estimated time:

Description

If, for a given e.g. root session daemon, we start 2 sessions (sessions A and B), each with JUL events (targeting different loggers), those events will be logged into both sessions, rather than having the events enabled for session A into session A, and likewise for B.

We should filter by logger name at the JUL JNI interface at UST level to fix this issue. This fix should not require changes to UST, only changes to session daemon.

#1

Updated by Mathieu Desnoyers about 6 years ago

  • Project changed from LTTng-UST to LTTng-tools
#2

Updated by David Goulet about 6 years ago

  • Status changed from New to Confirmed
#3

Updated by David Goulet about 6 years ago

  • Priority changed from Normal to High
#4

Updated by David Goulet almost 6 years ago

Thinking about this bug here, not sure we can make it work without having UST accept multiple filters for a single event. Consider this case here:

$ lttng create test1
$ lttng enable-event -j event1
$ lttng enable-event -j event2

So for JUL, we enable a UST tracepoint wildcard which is "lttng_jul:user*" and "lttng_jul:sys*" for root sessiond. Fixing this issue would mean having a way to "add" filters to an already enabled event in UST. Pseudo code here:

enable UST event "lttng_jul:user*" with filter "name == event1" 
[random wait period]
add filter to "lttng_jul:user*" for "name == event2" 

Hope I'm clear here but the problem in a nutshell is to apply multiple filters to the same UST event. Is UST ready for that or am I failing to understand what we are trying to do here?

#5

Updated by Mathieu Desnoyers almost 6 years ago

I just looked at the UST code and enabling the same event twice should work.

#6

Updated by Mathieu Desnoyers almost 6 years ago

By the way, there is another aspect to this issue: enabling different loglevels for different sessions.

Let's suppose we have events:

event1 -> prio high
event2 -> prio low

In SessionA, we enable high prio JUL events only. In SessionB, we enable low (and high) prio loglevel events.

I'm pretty sure the result currently is that SessionA will be polluted by low prio events, because there is no filtering on a per-session basis based on the JUL loglevel within lttng-ust. We should use the lttng-ust filters to filter by JUL loglevel too, in addition to filtering by JUL logger name.

#7

Updated by David Goulet almost 6 years ago

  • Status changed from Confirmed to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF