Spring (mvc, websockets) иногда вызывает исключение при создании экземпляра - PullRequest
Новая
       6

Spring (mvc, websockets) иногда вызывает исключение при создании экземпляра

5 голосов
/ 28 мая 2020

На наших производственных серверах (tomcat, java8) время от времени мы видим следующую трассировку стека в файлах журнала: 

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)

Что может быть причиной этого исключения и как я могу отследить происхождение?

Спасибо

Ответы [ 2 ]

0 голосов
/ 04 июня 2020

Прямо сейчас у меня нет кода spring mvc, но похоже, что есть неисправная конечная точка.

ModelAttributeMethodProcessor пытается создать атрибут модели (это должно быть что-то в вашем коде, и этот класс должен иметь конструктор) и не может создать его экземпляр.

Возможно, что такие вызовы ответят статусом HTTP 500 (или, по крайней мере, не 200). Теперь, вероятно, у вас где-то есть журнал доступа (журнал со всеми статусами запросов / ответов) - это может быть шлюз, прикладной балансировщик нагрузки, возможно, ELB, это действительно зависит от того, где вы работаете. В этом случае вы можете изучить эти журналы и попытаться найти конечные точки, которые иногда возвращают коды 5XX. Может быть, будет такая же конечная точка, которая иногда не работает. Как вы говорите, это не должно вызывать проблем у вашего сервера, но клиент, который ожидает получить результат, вызвав эту конечную точку, очевидно, не получит желаемого ответа.

0 голосов
/ 01 июня 2020

На основе, например: Контроллер пользовательских ошибок загрузки Spring показывает неправильное исключение это может быть исключение, выброшенное из вашего собственного кода, поэтому, возможно, найдите в своей собственной кодовой базе места, где возникает исключение.

Чтобы немного усложнить ситуацию, все это реализовано в собственном коде, см .: класс newInstance распространяет проверенные и непроверенные исключения - это правда?

Но, возможно, это еще больше запутывается, потому что исходное исключение в вашей производственной системе уже создавалось много раз (с момента запуска) и было преобразовано в чрезвычайно оптимизированный собственный код.

В этом случае вы можете:

  • увидеть это в ведение журнала при запуске приложения; или
  • , если вы запустите Java с этим дополнительным параметром: -XX: -OmitStackTraceInFastThrow (до вашего jar приложения / имени основного класса и аргументов приложения)

Надеюсь, это поможет, Мне любопытно, так ли это, поэтому, пожалуйста, дайте мне знать (и всем другим читателям, которые могут прийти сюда позже).

...