Project

General

Profile

Bug #933

Cannot list Java events

Added by Philippe Proulx about 2 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Normal
Target version:
Start date:
09/05/2015
Due date:
% Done:

100%

Estimated time:

Description

I don't know if the bug is in LTTng-UST or LTTng-tools, but at least using the master version of both projects, and when running the two Java examples (lttng-ust/doc/examples/java-jul and lttng-ust/doc/examples/java-log4j), lttng list -j and lttng list -l list no events.

However, events are properly recorded.

Associated revisions

Revision 68a1ef73 (diff)
Added by Alexandre Montplaisir about 2 years ago

Fix: Return the correct list of available Java events

The "lttng list -j/-l" command should list the events that are currently
offered by Java application and available to be enabled.

Due to some confusion in the implementation of the corresponding agent
command response, it was actually returning the list of events that were
enabled in the tracing session.

Rectify this by sending the list of loggers of the corresponding domain
that have one or more LTTng log handlers attached. The interface method
was also renamed from listEnabledEvents() to listAvailableEvents() to
make it more representative.

Fixes: #933

Signed-off-by: Alexandre Montplaisir <>
Signed-off-by: Mathieu Desnoyers <>

History

#1 Updated by Alexandre Montplaisir about 2 years ago

There is an agent protocol message to list events, however I realize now that all it does on the Java side is list the event names that are enabled in the session. I'm pretty sure it was always like that. But it doesn't seem very useful, this information is already present in the session daemon, isn't it?

Java domains don't have the notion of event names like C applications do, they use logger names instead of event names. Loggers are usually organized in a hierarchy, such as "com", "com.mycompany", "com.mycomponent.mycomponent", etc. and typically correspond to package or class names.

It would be possible to iterate through all loggers currently active in the JVM, and for each of them go through all their attached handlers, and report the names of those that have a least one LTTng-JUL (or -logj4) handler attached. Is this what we would want to do?

#2 Updated by Philippe Proulx about 2 years ago

Is this what we would want to do?

Yes, this is what the Python agent does, and IIRC this is what JUL/log4j did in 2.6.

See https://github.com/lttng/lttng-ust/blob/stable-2.6/liblttng-ust-java-agent/java/org/lttng/ust/agent/jul/LTTngJUL.java, for example:

    public Iterator<String> listLoggers() {
        Vector<String> logs = new Vector<String>();
        for (Enumeration<String> loggers = LogManager.getLogManager().getLoggerNames(); loggers.hasMoreElements(); ) {
            String name = loggers.nextElement();
            /* Skip the root logger */
            if (name.equals("")) {
                continue;
            }

            logs.add(name);
        }

        return logs.iterator();
    }

#3 Updated by Alexandre Montplaisir about 2 years ago

  • Target version set to 2.8
  • Assignee set to Alexandre Montplaisir
  • Status changed from New to In Progress

Oh, you're correct. Alright then, it's a regression, and it's my fault. I'll take care of it ;)

The code excerpt will list all the loggers that are currently active. Do we want to keep this behaviour, or restrict the list to only those that have a LTTng handler attached at the time of the query?

#4 Updated by Alexandre Montplaisir about 2 years ago

  • Project changed from LTTng to LTTng-UST

#5 Updated by Alexandre Montplaisir about 2 years ago

Here's patch to fix the problem. It's based on top of https://github.com/lttng/lttng-ust/pull/11 though, I will wait until that PR is merged to submit it.

#6 Updated by Anonymous about 2 years ago

  • % Done changed from 0 to 100
  • Status changed from In Progress to Resolved

Applied in changeset ust|commit:68a1ef7391fb6103eba95fd350ccc61e73855d95.

Also available in: Atom PDF