Spring (mvc, websockets) sometimes raises an Exception while creating an instance

user_1163376 0
Viewed 158

On our production (tomcat, java8) servers, from time to time, we're seeing the following stacktrace in the logfiles:

java.lang.Exception
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:142)
        at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:102)
        at org.springframework.web.method.annotation.ModelAttributeMethodProcessor.createAttribute(ModelAttributeMethodProcessor.java:139)
        at org.springframework.web.servlet.mvc.method.annotation.ServletModelAttributeMethodProcessor.createAttribute(ServletModelAttributeMethodProcessor.java:82)
        at org.springframework.web.method.annotation.ModelAttributeMethodProcessor.resolveArgument(ModelAttributeMethodProcessor.java:106)
        at org.springframework.web.method.support.HandlerMethodArgumentResolverComposite.resolveArgument(HandlerMethodArgumentResolverComposite.java:121)
        at org.springframework.web.method.support.InvocableHandlerMethod.getMethodArgumentValues(InvocableHandlerMethod.java:158)
        at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:128)
        at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:97)
        at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:827)
        at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:738)
        at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
        at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:967)
        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:901)
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
        at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:861)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
        at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:728)
        at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:591)
        at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:527)
        at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:380)
        at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:323)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:166)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
        at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:660)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
        at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:798)
        at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
        at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
        at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:748)

What could be the cause of this exception and how can I trace the origin?

Thanks

tomcat spring exception websocket java
2 Answers

Based on e.g.: Spring Boot custom error controller is showing the incorrect exception this might be an Exception thrown from your own code, so maybe search your own codebase for places where Exception is thrown.

To complicate matters a bit this is all implemented in native code, see: class newInstance propagates checked and unchecked exceptions - is it true?

But maybe it is further obfuscated because the original exception on your production system has already been generated many times (since startup) and has been converted to extremely optimized native code.

In that case you can:

  • see this in the logging when the application just is started; or
  • if you start Java with this extra parameter: -XX:-OmitStackTraceInFastThrow (before your applications jar/Main class name and application arguments)

I hope that helps, I'm curious if this is the case, so please let me (and all other readers that might come here later know).

user_62506490

I don’t have spring mvc code in front of me right now, but it looks like there is a faulty end point.

ModelAttributeMethodProcessor tries to create a model attribute (that should be basically something in your code, and this class should have constructor) and fails to instantiate it.

It’s possible that calls like this will respond with 500 http status (or at least not 200). Now, probably you have an access log (log with all the requests / response statuses) somewhere - it can be a gateway, an applicative load balancer, ELB maybe, it really depends where you’re running. In this case you might be able to examine these logs and try to find the endpoints that sometimes return 5XX codes. Maybe there will be the same endpoint that sometimes doesn’t work. Now as you say, it shouldn’t really cause an issue to your server, but the client who expects to get the result by calling this endpoint obviously doesn’t get the desired response.

user_6051530
Related