java - Jersey 2.22 中的 servicelocator impl 关闭问题

Question

我的 Jersey 应用程序容器已关闭，并显示以下异常消息。

java.lang.IllegalStateException: ServiceLocatorImpl(__HK2_Generated_0,0,1879131528) has been shut down
    at org.jvnet.hk2.internal.ServiceLocatorImpl.checkState(ServiceLocatorImpl.java:2288)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.getServiceHandleImpl(ServiceLocatorImpl.java:629)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.getServiceHandle(ServiceLocatorImpl.java:622)
    at org.jvnet.hk2.internal.ServiceLocatorImpl.getServiceHandle(ServiceLocatorImpl.java:640)
    at org.jvnet.hk2.internal.FactoryCreator.getFactoryHandle(FactoryCreator.java:103)
    ... 59 common frames omitted
Wrapped by: org.glassfish.hk2.api.MultiException: A MultiException has 1 exceptions.  They are:
1. java.lang.IllegalStateException: ServiceLocatorImpl(__HK2_Generated_0,0,1879131528) has been shut down

每当出现上述错误时，应用程序都无法处理请求。它重复显示相同的消息并且还 我的 spring 应用程序容器也关闭了。下面是我重复收到的错误消息。

org.springframework.beans.factory.BeanCreationNotAllowedException: Error creating bean with name 'daoQuery': Singleton bean creation not allowed while the singletons of this factory are in destruction (Do not request a bean from a BeanFactory in a destroy method implementation!)

java.lang.IllegalStateException: BeanFactory not initialized or already closed - call 'refresh' before accessing beans via the ApplicationContext

我的 Glassfish Jersey 版本是 2.22.2。

上述情况仅在重负载时发生。

我们分析了该问题，发现该问题在多种场景下都会发生。

1. 负载均衡器超时高
2. Jersey HK2 冲突

我们纠正了这两点，但在重负载下我们仍然遇到相同的错误。

有什么方法可以预防或解决问题吗？

Answer 1

您应该升级到最新的2.28最新版本，或至少2.26修复 HK2 问题的版本

Another bigger change in Jersey code is attempt to make Jersey core independent of any specific injection framework. As you might now, Jersey 2.x is (was!) pretty tightly dependent on HK2, which sometimes causes issues (esp. when running on other injection containers. Jersey now defines it's own injection facade, which, when implemented properly, replaces all internal Jersey injection.

Don't be mistaken - Jersey still runs on hk2. But it should be possible to get rid off that dependency when other container provides same functionality. As already mentioned, the motivation is to be able to integrate seamlessly with other frameworks, like cdi, guice, etc. This is still work in progress and there is one consequence: user has to provide Jersey injection implementation. The only one which is 100% ready right now is based on hk2:

   <groupId>org.glassfish.jersey.inject</groupId>
    <artifactId>jersey-hk2</artifactId>
    <version>2.26</version>