ibmmqmet
commented
4 years ago I think you're probably asking in the wrong place. The MQ code is correctly throwing an exception when it can't connect. That's not something that can or should be changed. Apart from anything else, it's likely part of the JMS specification that such an exception is thrown.
Your real issue is how that exception is being handled by higher-level code. In this case the first consideration looks to be the HealthIndicator class that's part of the Spring actuator. A quick search on how that might be configured showed up https://stackoverflow.com/questions/30762906/is-it-possible-to-deactivate-mongohealthindicator-in-the-springboot-spring-actua for a different component; perhaps there's a similar property to disable JMS healthchecks. I don't know if disabling that will actually solve things, as the first line of your output shows "WARN" rather than "FAIL" in the healthchecker, but it might be taking that result as a fatal problem when continuing. And of course, once the JMS functions are really needed for regular processing, then they can't work if the connection still fails.
Christophe06410
Hi,
I have a strange issue that took me several days to narrow down. Basically, I have a Jhipster project based on Spring boot Version 2.1.10.RELEASE, which contains 4 microservices. We are interested here in 2 of them: Gateway and Corehub. In the gateway, I have an angular app that performs a POST to /services/corehub/api/someendpoint which used to be working and that is failing now with different error messages, but the one I have more regularly is
I ended up looking at the traces of the Registry that keeps track of the microservices for internal communication and I found out that when this error occurs, I cannot find the corehub in the traces anymore. So it looks like the corehub micro service is not registered.
An other GIT branch of this service does not have this problem, so I performed a diff between these two branches and I removed the changes until I could narrow down the problem. So, in the corehub, I have a JMS listener based on this mq-jms-spring implementation. The maven dependency is as follows:
I commented out my JmsListener class and its associated JmsContext (to get access to a topic), and kept only the configuration properties defining access to the server, along with the port, channel, topic name, etc.
If I comment the above maven dependency, my service works again. If I keep the maven dependency, with the configuration only, my corehub microservice is not registered in the Registry and becomes not accessible anymore from the gateway and thus the Angular UI.
What is important to note, is that I have currently some network issue which prevent me from accessing the JMS Server. So I believe the exception that is raised by this IBM library because the JMS server is not reachable, breaks the registration of the microservice towards the spring boot registry.
Here are the traces that come over and over in the corehub console:
Here are the requested version numbers:
Here is my configuration in application.yml:
Would it be possible to catch this exception to avoid breaking regular Spring Boot registration mechanism? I cannot afford having my cluster down because I cannot access the JMS server.
Any help would be greatly appreciated. Thank you Christophe