I have a Java 8 Spring Boot service.
It is hosted on AWS, in Kubernetes v1.13, Docker v18.06.3-ce.
Yesterday for 10 or even more hours I had a bunch of intermittent UnknownHostExceptions when trying to send http requests from my service to both internal and external services.
The exception happened at least for 5 different host names.
Today I had no issues.
In the service logs I can not find anything other than something like this:
java.net.UnknownHostException: example.com
Also, not sure if it is relevant, but the service is using Spring Boot Apache Camel v2.22.0 to send these requests. Here is a piece of code which sends them:
Exchange exchange = template.send(url, exchange1 -> {
exchange1.getIn().setHeaders(headers);
exchange1.getIn().setHeader(Exchange.HTTP_METHOD, httpMethod.toString());
exchange1.getIn().setBody(body);
});
Mvn dependencies for Apache Camel:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-spring-boot</artifactId>
<version>${apache.camel.version}</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-spring-boot-starter</artifactId>
<version>${apache.camel.version}</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-stream</artifactId>
<version>${apache.camel.version}</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core</artifactId>
<version>${apache.camel.version}</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-script</artifactId>
<version>${apache.camel.version}</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-http4</artifactId>
<version>${apache.camel.version}</version>
</dependency>
Any ideas what can be the cause of these intermittent UnknownHostExceptions? Please let me know what pieces of info would be helpful to find out the root cause of the issue.
P.S. Service was working fine for more than a year. No recent code changes. At least for this logic above.
Related
i am consuming from mqtt through camel and trying to publish to confluent kafka, but when i produce to kafka i get the following error
java.lang.IllegalArgumentException: Login module control flag is not available in the JAAS config
at org.apache.kafka.common.security.JaasConfig.loginModuleControlFlag(JaasConfig.java:85) ~[kafka-clients-3.1.1.jar:na]
at org.apache.kafka.common.security.JaasConfig.parseAppConfigurationEntry(JaasConfig.java:111) ~[kafka-clients-3.1.1.jar:na]
my camel config for building route uri looks like this
builder.setScheme("kafka");
builder.setHost(topicName);
builder.setParameter("brokers",broker);
builder.setParameter("saslMechanism","PLAIN");
builder.setParameter("securityProtocol","SASL_SSL");
builder.setParameter("saslJaasConfig", "org.apache.kafka.common.security.plain.PlainLoginModule required username=\"username\" password=\"Password\";");
i followed this link Camel-Kafka security protocol SASL_SASL not working tried to put JAAS config in RAW but it doesn't work, even i tried to externalize the jaas property as mentioned here
Kafka "Login module not specified in JAAS config" but still i am getting the same error not sure what is missing in jaas config or its a problem with camel kafka dependency
i am using following dependency chart camel version 2.25.4
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core</artifactId>
<version>${camel.version}</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-mqtt</artifactId>
<version>${camel.version}</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-spring-boot</artifactId>
<version>${camel.version}</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-kafka</artifactId>
<version>${camel.version}</version>
</dependency>
</dependencies>
i have been stuck figuring out, any help?
After some debuggiing i found that it works when i set up KafkaComponent in camel context , i set up properties in app.properties then i used KafkaComponent and set it in camel context it was able to take properties, but strangely while building uri i used the same property it didn't worked looks like camel is not able to read property from string uri in my case
KafkaComponent kafka = new KafkaComponent();
KafkaConfiguration kafkaConfiguration = new KafkaConfiguration();
kafkaConfiguration.setBrokers(kafkaBrokerUrl);
kafkaConfiguration.setSaslMechanism(saslmechanism);
kafkaConfiguration.setSecurityProtocol(saslprotocol);
kafkaConfiguration.setSaslJaasConfig(kafkajaasconfig);
kafka.setConfiguration(kafkaConfiguration);
getContext().addComponent("kafka", kafka);
I'm using Camel in Spring Boot to send messages to an ActiveMQ Artemis queue using camel-jms-starter, artemis-jms-client and camel-jms. The issue is that Jenkins has found vulnerability in nested dependency org.apache.geronimo.specs:geronimo-jms_2.0_spec.
If I exclude it, it will not work.
Is there a way to keep using Camel in Spring Boot to send message in ActiveMQ queue without Apache Geronimo JMS?
These are my Camel dependencies for ActiveMQ:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-jms</artifactId>
<version>${camel.version}</version>
</dependency>
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>artemis-jms-client</artifactId>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-jms-starter</artifactId>
<version>${camel.version}</version>
</dependency>
I do not use any configuration bean because Spring Boot does it automatically via properties
spring.artemis.mode=native
spring.artemis.host=localhost
spring.artemis.port=61616
spring.artemis.user=admin
spring.artemis.password=admin
You can explicitly exclude the Apache Geronimo dependency from artemis-jms-client, e.g.:
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>artemis-jms-client</artifactId>
<exclusions>
<exclusion>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-jms_2.0_spec</artifactId>
</exclusion>
</exclusions>
</dependency>
Then you can add a dependency on the Eclipse JMS API implementation, e.g.:
<dependency>
<groupId>jakarta.jms</groupId>
<artifactId>jakarta.jms-api</artifactId>
<version>2.0.3</version>
</dependency>
That said, it is very strange that the Apache Geronimo JMS API would be flagged with a vulnerability since it is just an API. In other words, it's just Java interface and empty class definitions.
I just upgraded to google cloud storage java 1.88.0 from 1.76.0 on an app-engine standard. I ran into the below problem when trying to read a com.google.cloud.storage.Blob object. The workaround is not going to work for big documents on app-engine, so is there a solution to this? Maybe some dependency thing I would have to check?
ByteStreams.copy(Channels.newInputStream(blob.reader()), resp.getOutputStream());
now fails with
java.lang.NoSuchMethodError: com.google.api.services.storage.Storage$Objects$Get.setReturnRawInputStream(Z)Lcom/google/api/client/googleapis/services/AbstractGoogleClientRequest;
at com.google.cloud.storage.spi.v1.HttpStorageRpc.createReadRequest(HttpStorageRpc.java:658)
at com.google.cloud.storage.spi.v1.HttpStorageRpc.read(HttpStorageRpc.java:693)
at com.google.cloud.storage.BlobReadChannel$1.call(BlobReadChannel.java:127)
at com.google.cloud.storage.BlobReadChannel$1.call(BlobReadChannel.java:124)
at com.google.api.gax.retrying.DirectRetryingExecutor.submit(DirectRetryingExecutor.java:105)
at com.google.cloud.RetryHelper.run(RetryHelper.java:76)
at com.google.cloud.RetryHelper.runWithRetries(RetryHelper.java:50)
at com.google.cloud.storage.BlobReadChannel.read(BlobReadChannel.java:123)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:65)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
at java.io.InputStream.read(InputStream.java:101)
at com.google.common.io.ByteStreams.copy(ByteStreams.java:108)
but can be replaced with, as a workaround (but is probably vastly less memory efficient):
ByteSource.wrap(storage.readAllBytes(blob)).copyTo(resp.getOutputStream());
Relevant pom entries could be:
<dependency>
<groupId>com.google.firebase</groupId>
<artifactId>firebase-admin</artifactId>
<version>6.9.0</version>
</dependency>
<dependency>
<groupId>com.google.cloud</groupId>
<artifactId>google-cloud-storage</artifactId>
<version>1.88.0</version>
</dependency>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>28.0-jre</version>
</dependency>
<!-- firestore fails with NoClassDefFoundError:
com/google/protobuf/GeneratedMessageV3 without this -->
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<version>3.6.1</version>
</dependency>
as stated in the App Engine documentation, in order to read and write from a Cloud Storage Bucket you should be using the appengine tools dependency:
<dependency>
<groupId>com.google.appengine.tools</groupId>
<artifactId>appengine-gcs-client</artifactId>
<version>0.7</version>
</dependency>
After following the previously mentioned documentation my App Engine App works just fine.
Please try this documentation and tell us if works for you.
I am working on migrating an application from RestEasy implemenation to Jersey Implementation. The main problem I am facing is in the jars required for the CDI part.
While using resteasy, we are using the following 3 resteasy related jars
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-cdi</artifactId>
<version>3.0.8-FINAL</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jaxrs</artifactId>
<version>3.0.8-FINAL</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-servlet-initializer</artifactId>
<version>3.0.8-FINAL</version>
</dependency>
Now, to migrate it to Jersey, I am using the following jars in place of the resteasy jars.
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>2.22.1</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext.cdi</groupId>
<artifactId>jersey-cdi1x-servlet</artifactId>
<version>2.22.1</version>
</dependency>
<dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
<version>1.1</version>
</dependency>
Now when I try to deploy the EAR on the JBOSS server, I get the following error.
15:04:48,156 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.subunit."abc-ear.ear"."xyz-service-impl.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."abc-ear.ear"."xyz-service-impl.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "xyz-service-impl.war" of deployment "abc-ear.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS016053: Service class org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider didn't implement the javax.enterprise.inject.spi.Extension interface
at org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:48)
at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:119)
at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:79)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
... 5 more
As you can see from stack trace, the error that I am getting is org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider didn't implement the javax.enterprise.inject.spi.Extension interface
I downloaded the source of the required jar to see if the class in question implements that interface or not. Well, it does implement the Extension interface.
Right now I am not able find a solution for this error.
I have tried various permutation and combination of different jersey jars but couldn't find a fix for this.
I have ran out of ideas. Any help would be really appreciated.
Recently I've done quite similar migration (RESTEasy 3.0.8.Final -> Jersey 2.23.1), but my migration also included the abandonment of the WildFly server. So it's quite big difference.
You haven't included any information about used Weld version, so please do it as this is very important here.
Anyway, two tips from my side before you'll update your question:
There is a big chance that your error is caused by the EAR deployment. Because CDI and EAR archives sometimes don't play well together. Can you check what happen if you change your packaging to *.war?
If you don't have a very, very good reason to migrate to a non-built-in JAX-RS implementation when still using Java EE app server and CDI, please don't do it. It's a tough task.
Ps. JFYI amount of problems with Weld and App servers which I've encountered pushed me to abandon them wherever I can.
UPDATE
You said you are using Weld 1.1.23.FINAL - this is very important information. Jersey + Weld integration changed heavily since Jersey 2.15. Personally, I wasn't able to make it work without some newer Weld version (2.3.5 in my case) - probably because this combination isn't supported.
In your case, as you're using extremely old Weld version, I would advice you to try at most Jersey 2.14.
In Jersey 2.14, needed dependencies were different. Please remove jersey-cdi1x-servlet and try this instead:
<dependency>
<groupId>org.glassfish.jersey.containers.glassfish</groupId>
<artifactId>jersey-gf-cdi</artifactId>
<version>2.14</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers.glassfish</groupId>
<artifactId>jersey-gf-cdi-ban-custom-hk2-binding</artifactId>
<version>2.14</version>
</dependency>
<!-- is it needed for you?
<dependency>
<groupId>org.jboss.weld.servlet</groupId>
<artifactId>weld-servlet-core</artifactId>
</dependency>
-->
BTW: may I know why you are changing JAX-RS implementation inside JBoss?
I have migrated to latest versions last month and this works for me.
try this.
<properties>
<version.jersey>2.23.2</version.jersey>
<version.glassfish>2.4.0</version.glassfish>
</properties>
<dependencies>
<dependency>
<groupId>org.glassfish.hk2.external</groupId>
<artifactId>asm-all-repackaged</artifactId>
<version>${version.glassfish}</version>
</dependency>
<dependency>
<artifactId>hk2-utils</artifactId>
<groupId>org.glassfish.hk2</groupId>
<version>${version.glassfish}</version>
<exclusions>
<exclusion>
<artifactId>javax.inject</artifactId>
<groupId>javax.inject</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>javax.annotation</groupId>
<artifactId>javax.annotation-api</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>javax.ws.rs-api</artifactId>
<version>2.0.1</version>
</dependency>
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.2.12</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-common</artifactId>
<version>${version.jersey}</version>
<exclusions>
<exclusion>
<groupId>org.glassfish.hk2</groupId>
<artifactId>osgi-resource-locator</artifactId>
</exclusion>
<exclusion>
<groupId>org.glassfish.hk2.external</groupId>
<artifactId>aopalliance-repackaged</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>${version.jersey}</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-multipart</artifactId>
<version>${version.jersey}</version>
</dependency>
</dependencies>
You might be using wrong dependancies. Check this:
https://jersey.java.net/documentation/latest/modules-and-dependencies.html
I'm using neo4j-jdbc in an application and get a lot of "Starting the Apache HTTP client" messages during connections.
For logging I'm using logback, slf4j and the bridges like jul-to-slf4j, jcl-over-slf4j and log4j-over-slf4j.
My configuration file is in the classpath and called logback.xml. If I set the root log level to "OFF" its working for every message beside the apache messages.
How can I turn off the "Starting the Apache HTTP client" output?
I tried using log4j which also did'nt work for that message.
Setting the specific package of the httpclient (wire, org.apache, org.restlet, etc.) also didn't work.
The output is generated via a getLogger call from org.restlet.ext.httpclient, so no direct System.out.println statement or something like that.
Any thoughts on that?
Edit: These are the relevant dependencies of the pom file:
[..]
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.5</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.0.12</version>
</dependency>
<dependency>
<groupId>org.neo4j</groupId>
<artifactId>neo4j-jdbc</artifactId>
<version>2.0.2</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.7</version>
</dependency>
[..]
As Stefan Armbruster and Michael Hunger mentioned in the comments it is fixed in the master branch.
I couldn't figure out exactly why the messages are send to the console, since it looks like a proper jcl logger is used, anyway the messages are gone in the 2.1.5-SNAPSHOT version.