sun.nio.fs.UnixException没有这样的文件或目录

我在Wildfly 15linux服务器上部署了SOAPweb服务，并且我正在使用Dynatrace来监控此web服务。用于日志记录的Log4j2。我正在记录代码中的每一个细节，并且我有每个private和public方法执行的持续时间。乍一看一切都很好，但我有一个奇怪的案例。例如，当我在日志中查看时，web方法的一个请求的持续时间为80ms，但在Dynatrace中有780。

在Dynatrace中，当我查看此请求的详细信息时，会出现这样的情况：仅在Dynatrace中出现的一些sun.nio.fs.UnixException需要700ms，而在web方法和

web方法以下是此sun.nio.fs.UnixException:的详细信息

Exception: sun.nio.fs.UnixException Message: No such file or directory Stacktrace: sun.nio.fs.UnixNativeDispatcher.access0(UnixNativeDispatcher.java) sun.nio.fs.UnixNativeDispatcher.access(UnixNativeDispatcher.java:449) sun.nio.fs.UnixFileSystemProvider.checkAccess(UnixFileSystemProvider.java:306) java.nio.file.Files.exists(Files.java:2385) org.jboss.modules.PathResourceLoader.lambda$ org.jboss.modules.PathResourceLoader$$Lambda$.run org.jboss.modules.PathResourceLoader.doPrivilegedIfNeeded(PathResourceLoader.java:248) org.jboss.modules.PathResourceLoader.getResource(PathResourceLoader.java:155) org.jboss.modules.ModuleClassLoader.loadResourceLocal(ModuleClassLoader.java:410) org.jboss.modules.ModuleClassLoader$1.loadResourceLocal(ModuleClassLoader.java:144) org.jboss.modules.Module.getResource(Module.java:764) org.jboss.modules.ModuleClassLoader.findResource(ModuleClassLoader.java:616) org.jboss.modules.ConcurrentClassLoader.getResource(ConcurrentClassLoader.java:255) java.lang.Class.getResource(Class.java:2267) ge.my.package.ws.security.ConfigManager.getConfigManager(ConfigManager.java:44) ge.my.package.ws.Ccs.handleUserRequest(Ccs.java:610) ge.my.package.ws.Ccs.getAuthorizationsByCardSerno(Ccs.java:466) sun.reflect.GeneratedMethodAccessor.invoke sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:498) com.sun.xml.ws.util.Trampoline.invoke(MethodUtil.java:82) sun.reflect.GeneratedMethodAccessor.invoke sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:498) com.sun.xml.ws.util.MethodUtil.invoke(MethodUtil.java:107) com.sun.xml.ws.api.server.MethodUtil.invoke(MethodUtil.java:64) com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:250) com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:149) com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:88) com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1136) com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1050) com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:1019) com.sun.xml.ws.api.pipe.Fiber.run(Fiber.java:813) com.sun.xml.ws.api.pipe.Fiber.start(Fiber.java:420) com.sun.xml.ws.server.WSEndpointImpl.processAsync(WSEndpointImpl.java:368) com.sun.xml.ws.server.WSEndpointImpl.process(WSEndpointImpl.java:398) com.sun.xml.ws.transport.http.HttpAdapter.invokeAsync(HttpAdapter.java:734) com.sun.xml.ws.transport.http.servlet.ServletAdapter.invokeAsync(ServletAdapter.java:212) com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:161)
这是我的ge.my.package.ws.security.ConfigManager.geConfigManager(ConfigManager.java:44)线路代码：
URL url = CcsConfigManager.class.getResource("/config.properties");
看起来，它甚至在请求真正进入web方法并开始日志记录之前就试图获取配置文件(我在请求进入web方法就有日志记录(，我甚至在日志中没有任何关于此尝试和错误消息的信息。当它进入web方法并开始日志记录时，它会获取并读取config.properties文件，一切都很好。
我使用Dynatrace只是为了监控生产服务器，正如我所说，我在日志中没有关于这个错误的任何信息，因此我无法对这个问题进行任何深入研究，我真的不知道这是我的代码、环境的问题，还是Dynatrace显示出了问题。
如果它真的进入我的服务并以fail调用我的方法，为什么我的日志中没有任何内容？如果服务中发生了什么事情，我会记录任何类型的RuntimeException
它会影响响应时间吗？我怎么知道它是真的80毫秒还是780毫秒
如果可能的话，我该怎么做才能将此错误写入日志

抛出的sun.nio.fs.UnixException在java.nio.io.Files#exists中捕获(有关代码，请参阅此处(。这就是您在日志中看不到异常的原因。
由于触发异常的代码是在输入方法之前执行的，这当然会增加整个请求的响应时间。Files.exists方法在JDK8中的性能明显较差，并且在用于检查实际不存在的文件时会显著降低应用程序的速度。像Sonar这样的源代码分析工具甚至会对此发出警告(例如，请参阅此处(。性能差的根本原因是Dynatrace显示的异常，或者更准确地说，是其代价高昂的fillInStackTrace((方法。
不能记录JRE内部类或第三方库捕获的异常。跟踪所有抛出异常的唯一方法是使用Dynatrace之类的监控工具，或者开发自己的监控工具来使用JavaInstrumentation/Agent API。

相关内容

最新更新

热门标签：