Проблема с отключением сервиса servicelocator в Джерси 2.22
Контейнер My Jersey Application закрыт с приведенным ниже сообщением об исключении.
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
Всякий раз, когда возникает вышеуказанная ошибка, приложение не может обработать запрос. Он неоднократно показывает одно и то же сообщение, а также мой контейнер весеннего приложения также не работает. Ниже приведено сообщение об ошибке, которое я постоянно получаю.
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.
Вышеописанное происходит только при большой нагрузке.
Мы проанализировали проблему и обнаружили, что эта проблема возникает в нескольких сценариях.
- Высокий тайм-аут балансировщика нагрузки
- Конфликт Джерси Hk2
Мы исправили эти два момента, но все равно получаем ту же ошибку при большой нагрузке.
Есть ли способ предотвратить или исправить проблему?
@ user7294900, спасибо. нет, у меня возникают конфликты зависимостей, поэтому я перешел с 2.19 на 2.22. Исправлена ли эта проблема в версии 2.28?
Ответы 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>
Спасибо за подробное объяснение. Я обновлю и сообщу вам результат
Это не имеет ничего общего с проблемой ОП. «Проблемы», упомянутые в документации по миграции, относятся к конфликтам с другими контейнерами внедрения зависимостей. Изменение версий не является решением проблем все, связанных с HK2. И переходя на 2.28, вам все равно придется использовать HK2, как упоминается даже в вашем ответе. Так что я не понимаю логики в этом ответе. В документах упоминается об устранении проблем в HK2. Это только говорит о том, что HK2 больше не является «жесткой» зависимостью. Но вам все равно придется его использовать, если только вы не перейдете на CDI.
@PaulSamsotha, возможно, вы правы, но это также предлагается в аналогичной проблеме с майкой github.com/eclipse-ee4j/джерси/issues/3889
@Madhesh Обновление версии решило проблему?
@user7294900 user7294900 даже сопровождающие только догадываются. Реального ответа не было. А в случае с OP также есть проблема, связанная с Spring.
@PaulSamsotha, я обновился. Но проблема будет имитироваться только в часы пик. Я должен проверить час пик, решена ли проблема или нет.
@PaulSamsotha Проблема заключается в том, что метод выключения также уничтожает контейнер приложения Spring. В своих журналах я подтвердил, что метод destory вызывается после получения этой ошибки. Таким образом, возникает только ошибка, связанная с пружиной. Так что проблема только с HK2.
это не особенно проблема hk2, это больше похоже на состояние отключения/ошибки трикотажа. Не hk2 в том, что hk2 был кем-то выключен (сам не выключается)
@ jwells131313, надеюсь, вы пытаетесь сказать, что из-за какой-то другой проблемы с библиотекой hk2 также отключается
Вы пробовали с последней версией 2.28?