After switching from quarkus-rest-client to quarkus-rest-client-reactive
A warning started appearing.
WARN [io.net.res.dns.DefaultDnsServerAddressStreamProvider] (Quarkus Main Thread) Default DNS servers: [/8.8.8.8:53, /8.8.4.4:53] (Google Public DNS as a fallback)
What I've found so far is that it's related to a change on Quarkus 2.7 that disables JNDI by default due to security reasons.
What's the proper way to handle the warning? I don't want it to appear (or at least not as warning) but to keep the security meassures. Does it mean the app will fail if it is deployed to a cluster without access to internet?
Java: 11
Quarkus: 2.12.3.Final
Related
I recently upgraded CAS to 6.4.6.x and noticed that the liveness/readiness probes will intermittently throw 403 error codes. It appears to be a threading issue in the Spring Security Filter Chain. I have validated with the barebone CAS images that this does not happen in the 6.3.x version but can repeat it rather easily with the 6.4.x version. My configuration has not changed after the upgrade and I'm following the documentation.
Endpoint Configuration:
# allow all by default
cas.monitor.endpoints.endpoint.defaults.access[0]=PERMIT
# enable the health endpoint
management.endpoints.enabled-by-default=true
management.endpoints.web.base-path=/actuator
management.endpoints.web.exposure.include=health
management.endpoint.health.enabled=true
Running load tests against the instance if I send 1 request at a time I get 200 responses. If I bump up the concurrency to 2 or more I'm able to reproduce the threading issue and some of the responses return with a 403 after getting picked up by the Spring Default Error Controller.
Setting a breakpoint on the Error Controller, I'm able to see the same thread in the logs essentially jump to two different points in the code path.
I've gone through the Pull Requests from 6.3.x to 6.4.x and nothing jumped out to me that might be causing this issue. I haven't seen any issues raised up in Spring Boot around the Actuator Health Points failing. I've bumped up Spring and Tomcat to the latest patch versions. Any thoughts on what could be causing this or other things I could try to determine how to fix it?
My spring-boot (version 2.4.1) application was successfully connected to an ElasticSearch(v7.9.3) instance using the autowired org.elasticsearch.client.RestHighLevelClient (I just had to specify the application properties and it worked).
In a new phase of the project a dependency with spring-boot-starter-webflux was added to use some reactive logic to call an external webservice. (which has nothing to do with my elasticsearch connection)
But now suddenly the elasticsearch client also tries to connect using reactor and I got errors like:
reactor.core.Exceptions$ErrorCallbackNotImplemented: org.springframework.data.elasticsearch.client.NoReachableHostException:
Host 'https://elastic-dev.company.intra:9200:9200' not reachable. Cluster state is offline.
Caused by: org.springframework.data.elasticsearch.client.NoReachableHostException:
Host 'https://elastic-dev.company.intra:9200:9200' not reachable. Cluster state is offline.
at org.springframework.data.elasticsearch.client.reactive.SingleNodeHostProvider.lambda$lookupActiveHost$4(SingleNodeHostProvider.java:108) ~[spring-data-elasticsearch-4.1.2.jar!/:4.1.2]
I know there is a configuration issue with :9200:9200 but I would like to just disable the use of reactor for my Elasticsearch client so it just uses the old way (I still need my Elasticseach client). Is this possible ?
Thanks.
After searching further I found a solution which was also suggested by P.J.Meish: disable the AutoConfiguration classes regarding the reactive elasticsearch:
I preferred the config in application.properties:
spring.autoconfigure.exclude=\
org.springframework.boot.actuate.autoconfigure.elasticsearch.ElasticSearchReactiveHealthContributorAutoConfiguration,\
org.springframework.boot.autoconfigure.data.elasticsearch.ReactiveElasticsearchRepositoriesAutoConfiguration,\
org.springframework.boot.autoconfigure.data.elasticsearch.ReactiveElasticsearchRestClientAutoConfiguration
So, we have two Liberty servers with different versions.
WAS Liberty 16.0.0.2, and
WAS Liberty 17.0.0.2
Both of servers has the same configuration
But, the problem is, even with the same configuration, WAS Liberty version 17.0.0.2 will auto load application context/servlet on start/restart without sending a request to them, while WAS Liberty version 16.0.0.2 will not auto load application context/servlet on start/restart unless we send a request on it.
As per our search regarding this issue. In the IBM Knowledge center, it says that by default Liberty defers servlet loading until a request is received for the associated web application... but in WAS Liberty version 17.0.0.2, it will automatically load the servlet/application context.
Help will be very much appreciated for this one.
Note: we did not add <webContainer deferServletLoad="false"/> in our server.xml
Liberty used to deploy the web application on first request. That was the behaviour in 16.0.0.2. I don’t recall exactly when we changed when we deploy, but we updated to deploy async during startup rather than on first request since a number of people were expecting their servlet inits to be triggered sooner than first request.
Using Spring 1.5.9.RELEASE on JDK 1.9
Would like to use the JmsHealthIndicator to indicate when a connection to a queue manager can't be established after x-number of tries. Haven't found any good online info om how to configure the JmsHealthIndicator other than it should be auto-configured. Also, not sure how often the indicator is called (i.e. can I control the frequency or not)? What endpoint it is associated with?
I have 2 ears—say, Ear1 and Ear2—for my application, which are deployed in clusters. Ear2 is having Ejb which is being called from Ear1. EJB reference is required for communication between Ear2 and Ear1. I am setting the below value to
Target Resource JNDI Name: corbaloc::ClusterServer1:2810,:ClusterServer2:2810/cell/clusters/Cluster1/ejb/com/mycompanyName/projectName/ejb/facade/EjbFacadeHome
But I am getting the below error:
Caused by: javax.naming.ServiceUnavailableException: A communication failure occurred while attempting to obtain an initial context with the provider URL: "corbaloc::mums00100251.in.net.intra:2810,:mums00100392.in.net.intra:2810/cell/clusters/Cluster1/ejb/com/bnpparibas/tradefinance/ejb/facade/EjbFacadeHome". Make sure that any bootstrap address information in the URL is correct and that the target name server is running.
Please help.
The correct format for referencing remote EJB with WebSphere Application Server 6.1 in this case would be like:
corbaloc:iiop:mums00100251.in.net.intra:2810/ejb/com/bnpparibas/tradefinance/ejb/facade/EjbFacadeHome,iiop:mums00100392.in.net.intra:2810/ejb/com/bnpparibas/tradefinance/ejb/facade/EjbFacadeHome
2810 suggests you attempted to use either the bootstrap port of node agents or deployment manager. I would check the ports (you can find the BOOTSTRAP port from the management console under Ports section of the server preferences), and if they still fail use the actual application servers' bootstrap ports.
There could also be a scoping issue which would mandate that. If you deployed your application to the Cluster scope it is possible that the naming service only in the cluster members can actually resolve the EJB.