btrace с веб-контейнером Glassfish

Недавно я использую BTrace для проверки исключений, возникающих внутри виртуальной машины Glassfish. Я использую скрипт:

@BTrace public class OnThrow {    
    // store current exception in a thread local
    // variable (@TLS annotation). Note that we can't
    // store it in a global variable!
    @TLS static Throwable currentException;

    // introduce probe into every constructor of java.lang.Throwable
    // class and store "this" in the thread local variable.
    @OnMethod(
        clazz="java.lang.Throwable",
        method="<init>"
    )
    public static void onthrow(@Self Throwable self) {
        currentException = self;
    }

    @OnMethod(
        clazz="java.lang.Throwable",
        method="<init>"
    )
    public static void onthrow1(@Self Throwable self, String s) {
        currentException = self;
    }

    @OnMethod(
        clazz="java.lang.Throwable",
        method="<init>"
    )
    public static void onthrow1(@Self Throwable self, String s, Throwable cause) {
        currentException = self;
    }

    @OnMethod(
        clazz="+java.lang.Throwable",
        method="<init>"
    )
    public static void onthrow2(@Self Throwable self, Throwable cause) {
        currentException = self;
    }

    // when any constructor of java.lang.Throwable returns
    // print the currentException's stack trace.
    @OnMethod(
        clazz="java.lang.Throwable",
        method="<init>",
        location=@Location(Kind.RETURN)
    )
    public static void onthrowreturn() {
        if (currentException != null) {
            Threads.jstack(currentException);
            println("=====================");
            currentException = null;
        }
    }
}

Когда я подключаюсь к GF 4.1.1 (сборка 1) с BTrace v.1.3.10.2 (20180129) с помощью флага «-v», GF генерирует следующую трассировку, и я не вижу вывода консоли, выдаваемого BTrace:

btrace DEBUG: parsed command line arguments]]  
btrace DEBUG: Bootstrap ClassPath: .]]
btrace DEBUG: ignoring boot classpath element '.' - only jar files allowed]]
btrace DEBUG: System ClassPath: /usr/lib/jvm/java-8-oracle/jre/../lib/tools.jar]]
btrace DEBUG: debugMode is true]]
btrace DEBUG: probe descriptor path is .]]
btrace DEBUG: stdout is false]]
btrace DEBUG: starting agent thread]]
btrace DEBUG: Agent init took: 10482105ns]]
btrace DEBUG: starting server at 2020]]
btrace DEBUG: waiting for clients]]
btrace DEBUG: client accepted    Socket[addr=/127.0.0.1,port=43496,localport=2020]]]
btrace DEBUG: got instrument command]]
btrace DEBUG: loading BTrace class]]
btrace DEBUG: verifying BTrace class ...]]
btrace DEBUG: BTrace class com.sun.btrace.samples.OnThrow  verified]]
btrace DEBUG: preprocessing BTrace class com.sun.btrace.samples.OnThrow ...]]
btrace DEBUG: ... preprocessed]]  
btrace DEBUG: loaded 'com.sun.btrace.samples.OnThrow' successfully]]
btrace DEBUG: creating BTraceRuntime instance for com.sun.btrace.samples.OnThrow]]
btrace DEBUG: created BTraceRuntime instance for com.sun.btrace.samples.OnThrow]]
btrace DEBUG: sending Okay command]]
btrace DEBUG: client com.sun.btrace.samples.OnThrow: got com.sun.btrace.comm.OkayCommand@26cab401]]
btrace DEBUG: about to defineClass com/sun/btrace/samples/OnThrow]]
btrace DEBUG: defineClass succeeded for com.sun.btrace.samples.OnThrow]]
btrace DEBUG: skipping transform for BTrace class com/sun/btrace/agent/RemoteClient$1]]
btrace DEBUG: starting client command handler thread]]
btrace DEBUG: skipping transform for BTrace class com/sun/btrace/agent/Main$3]]
btrace DEBUG: new Client created com.sun.btrace.agent.RemoteClient@44c6c5b2]]
btrace DEBUG: retransforming loaded classes]]
btrace DEBUG: filtering loaded classes]]
btrace DEBUG: skipping transform for BTrace class com/sun/btrace/runtime/ClassCache$Singleton]]
btrace DEBUG: skipping transform for BTrace class com/sun/btrace/runtime/ClassInfo$ClassName]]
btrace DEBUG: skipping transform for BTrace class com/sun/btrace/runtime/ClassInfo$JavaClassName]]
btrace DEBUG: skipping transform for BTrace class com/sun/btrace/runtime/ClassInfo$BaseClassName]]
btrace DEBUG: skipping transform for BTrace class com/sun/btrace/runtime/ClassInfo$InternalClassName]]
btrace DEBUG: skipping transform for BTrace class com/sun/btrace/runtime/BTraceClassReader$BailoutExceptio]]
btrace DEBUG: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: This web container has not yet been started]]

java.util.concurrent.ExecutionException: java.lang.IllegalStateException:    This web container has not yet been started
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at com.sun.btrace.agent.Main.startServer(Main.java:674)
at com.sun.btrace.agent.Main.access$000(Main.java:60)
at com.sun.btrace.agent.Main$2.run(Main.java:125)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException: This web container has not yet been started
at org.glassfish.web.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:2827)
at org.glassfish.web.loader.WebappClassLoader.findResource(WebappClassLoader.java:1320)
at org.glassfish.web.loader.WebappClassLoader.getResourceAsStream(WebappClassLoader.java:1528)
at com.sun.btrace.runtime.ClassInfo.loadExternalClass(ClassInfo.java:262)
at com.sun.btrace.runtime.ClassInfo.<init>(ClassInfo.java:215)
at com.sun.btrace.runtime.ClassCache.get(ClassCache.java:70)
at com.sun.btrace.runtime.ClassCache.get(ClassCache.java:62)
at com.sun.btrace.runtime.ClassCache.get(ClassCache.java:51)
at com.sun.btrace.agent.Client.retransformLoaded(Client.java:451)
at com.sun.btrace.agent.Main$3.run(Main.java:693)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

btrace DEBUG: waiting for clients]]
btrace DEBUG: skipping transform for BTrace class sun/security/ssl/ServerNameExtension]]
btrace DEBUG: skipping transform for BTrace class sun/security/ssl/UnknownExtension]]  
btrace DEBUG: skipping transform for BTrace class sun/security/provider/PolicyFile$6]]

Меня смущает исключение стеклянной рыбы. Когда btrace подключается, на GF уже развернуто приложение, которое обслуживает HTTP-запросы.

Если развернуто веб-приложение (CDI/REST/JPA), использующее веб-контейнер, почему возникает сообщение «контейнер не запущен»?


web containers glassfish btrace
person maciek    schedule 31.01.2018    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Наконец-то я узнал, что происходит - снова взглянув на этот Ex:

org.glassfish.web.loader.WebappClassLoader.getResourceAsStream(WebappClassLoader.java:1528)
at com.sun.btrace.runtime.ClassInfo.loadExternalClass(ClassInfo.java:262)
at com.sun.btrace.runtime.ClassInfo.<init>(ClassInfo.java:215)
at com.sun.btrace.runtime.ClassCache.get(ClassCache.java:70)
at com.sun.btrace.runtime.ClassCache.get(ClassCache.java:62)
at com.sun.btrace.runtime.ClassCache.get(ClassCache.java:51)
at com.sun.btrace.agent.Client.retransformLoaded(Client.java:451)

Один из методов, которые я проанализировал в коде BTrace:

com.sun.btrace.agent.Client.retransformLoaded

который выглядит так:

void retransformLoaded() throws UnmodifiableClassException {
        if (runtime != null) {
            if (probe.isTransforming() && settings.isRetransformStartup()) {
                ArrayList<Class> list = new ArrayList<>();
                debugPrint("retransforming loaded classes");
                debugPrint("filtering loaded classes");
                ClassCache cc = ClassCache.getInstance();
                for (Class c : inst.getAllLoadedClasses()) {
                    if (c != null) {                                
451                     cc.get(c);
                        }
                        if (inst.isModifiableClass(c) &&  isCandidate(c)) 
                            debugPrint("candidate " + c + " added");
                            list.add(c);
                        }
...other stuff

cc.get(c) выдает это исключение. Он использует метод из ClassCache:

 ClassInfo get(ClassLoader cl, ClassName className) {
        Map<ClassName, ClassInfo> infos = getInfos(cl);

        ClassInfo ci = infos.get(className);
        if (ci == null) {
70          ci = new ClassInfo(this, cl, className);
            infos.put(className, ci);
        }
        return ci;
    }

И конструктор ClassInfo:

  ClassInfo(ClassCache cache, ClassLoader cl, ClassName cName) {
        this.cache = cache;
        cLoaderId = (cl != null ? cl.toString() : "<null>");
        classId = cName;
215     loadExternalClass(cl, cName);
    }

и, наконец, метод конструктора loadExternalClass:

 private void loadExternalClass(final ClassLoader cl, final ClassName className) {
        String resourcePath = className.getResourcePath();

262 InputStream typeIs = cl == null ? SYS_CL.getResourceAsStream(resourcePath) : cl.getResourceAsStream(resourcePath);
        if (typeIs != null) {
            try {
            BTraceClassReader cr = new BTraceClassReader(cl, typeIs);
            ...

SYS_CL берется с помощью ClassLoader.getSystemClassLoader(). На самом деле это WebappClassLoader, который является основным действующим лицом в исключении. Я заметил, что классы CDI/JPA выдают исключение (после перехвата и печати классов, которые выдают EX):

  btrace DEBUG: Class class some.package.EntityManagerWrapper -> EX thrown: This web container has not yet been started]]
  btrace DEBUG: Class class some.package.AsyncAuditFacade -> EX thrown: This web container has not yet been started]]
  btrace DEBUG: Class class some.package.OperationAuditFacade -> EX thrown: This web container has not yet been started]]
  btrace DEBUG: Class class some.package.FacadeConfigFactory -> EX thrown: This web container has not yet been started

Может ли кто-нибудь сказать мне, почему только эти классы выбрасывают EX при их инструментировании?

Мой скрипт BTrace взят из примеров и выглядит так:

  @TLS static Throwable currentException;
  @OnMethod(
        clazz="+java.lang.Throwable",
        method="<init>"
    )
    public static void onthrow2(@Self Throwable self, Throwable cause) {
        currentException = self;
    }
      @OnMethod(
            clazz="java.lang.Throwable",
            method="<init>",
            location=@Location(Kind.RETURN)
        )
    public static void onthrowreturn() {
        if (currentException != null) {
            Threads.jstack(currentException);
            println("=====================");
            currentException = null;
        }
    }

Чтобы решить эту проблему и получить вывод от BTrace, я могу просто обернуть строку 451 в com.sun.btrace.agent.Client.retransformLoaded блоком try-catch, и все работает нормально, и вывод генерируется.

Интересно, почему это исключение выбрасывается? SYS_CL — это загрузчик классов по умолчанию (CL), и я читал, что в Glassfish каждое веб-приложение имеет свой собственный недавно созданный CL. Эти классы CDI/JPA загружаются с помощью WebappClassLoader (переменная cl не равна нулю — 262 в ClassInfo.class, и я действительно проверил, что cl='WebappClassLoader (delegate=true)'), так почему же они не желают быть инструментированными?

Мораль в том, что вы просто не можете использовать BTrace с каждым скриптом, который вам нужен, потому что фреймворки среды могут помешать зондированию.

person maciek    schedule 31.01.2018