1

My Jersey Application container is shutdown with below exception message.

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

Whenever the above error is coming the application is not able to process the request. It repeatedly showing the same message and also my spring application container also down.Below is the error message i am getting repatedly.

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

My Glassfish Jersey Version is 2.22.2.

The above thing happens only in heavy load.

We analyzed the issue and found that this issue happen in multiple scenarios.

  1. Load Balancer Time Out High
  2. Jersey Hk2 conflict

We corrected those two points, but still we are getting the same error in heavy load.

Is there any way to prevent or fix issue?

Paul Samsotha
  • 205,037
  • 37
  • 486
  • 720
Selva
  • 1,620
  • 3
  • 33
  • 63

1 Answers1

1

You should upgrade to latest 2.28 latest version, or at least 2.26 version which fixes HK2 issues

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>
Ori Marko
  • 56,308
  • 23
  • 131
  • 233
  • Thanks for the detailed explanation. I will upgrade and let you know the result – Selva Jun 12 '19 at 11:49
  • This has nothing to do with the OP's issue. The "issues" mentioned in the migration docs refer to conflicts with other DI containers. Changing versions is not a solution to _all_ issues related to HK2. And switching to 2.28, you still have to use HK2, as even your answer mentions. So, I don't get the logic in this answer. The docs mentions noting about fixing issues in HK2. It only says that HK2 is no longer a "hard" dependency. But you still have to use it, unless you switch to CDI. – Paul Samsotha Jun 12 '19 at 11:59
  • @PaulSamsotha you may be correct, but it's also suggested in similar jersey issue https://github.com/eclipse-ee4j/jersey/issues/3889 – Ori Marko Jun 12 '19 at 12:06
  • @Madhesh Did upgrading the version fix the issue? – Paul Samsotha Jun 12 '19 at 12:09
  • @user7294900 even the maintainers are just guessing. There was no real answer posted. And in the OP's case, there is also a problem related to Spring. – Paul Samsotha Jun 12 '19 at 12:10
  • @PaulSamsotha i have upgraded. But the issue will simulate only in peak hours. I have to check the peak hour whether the issue solved or not. – Selva Jun 12 '19 at 12:59
  • @PaulSamsotha The problem is shutdown method destory the spring application container also. In my logs I confirmed that destory method is called after getting this error. So only spring related error is occurring. So the issue with HK2 only. – Selva Jun 12 '19 at 13:29
  • this isn't particularly an hk2 issue though, it sounds more like a jersey shutdown/error case condition. Not hk2 in that hk2 has been shutdown by someone (it doesn't shut itself down) – jwells131313 Jun 13 '19 at 01:54
  • @jwells131313, hope you are trying to say that due to some other library issue hk2 also getting shutdown – Selva Jun 13 '19 at 06:30