I have a Java application running with an OTel agent to collect telemetries and send them to the New Relic platform.
Configuration of OTel Java agent:
-javaagent:./agents/opentelemetry-javaagent-all.jar
-Dotel.traces.exporter=otlp
-Dotel.resource.attributes=service.name=my-application
-Dotel.exporter.otlp.endpoint=https://otlp.nr-data.net:4317
-Dotel.exporter.otlp.headers=api-key=${NEW_RELIC_LICENSE_KEY}
When this app is starting an error occurs:
Caused by: java.lang.IllegalArgumentException: cannot find a NameResolver for https://otlp.nr-data.net:4317
How to resolve this problem?
I would try:
-Dotel.exporter.otlp.endpoint=otlp.nr-data.net:4317
OTLP endpoint should be officially URL (so scheme part should be included), but some implementations need it without scheme part. I guess this is your case.
The problem has been solved for me when adjusting Dockerfile forcing the download of OTel java agent on the image build process.
From:
COPY ./agents/opentelemetry-javaagent-all.jar .
To:
ADD https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/download/v1.12.1/opentelemetry-javaagent.jar .
Related
I am trying to access mapr path remotely, using a spring boot application. I have set the fs.mapr.bailout.on.library.mismatch property to false, to avoid the error on version mismatch. Still whenever the getFileStatus() function gets called, the application stops with the following error:
2020-12-15 10:07:18,7377 ERROR JniCommon fs/client/fileclient/cc/jni_MapRClient.cc:691 Thread: 123145425235968 Mismatch found for java and native libraries java build version 6.0.1.20180404222005.GA, native build version 6.0.1.20190808152212.GA java patch vserion $Id: mapr-version: 6.0.1.20180404222005.GA 1aeeb6d3c17c777fcba0, native patch version $Id: mapr-version: 6.0.1.20190808152212.GA 1aeeb6d3c17c777fcba0
2020-12-15 10:07:18,7378 ERROR JniCommon fs/client/fileclient/cc/jni_MapRClient.cc:708 Thread: 123145425235968 Client initialization failed.
Code:
FileSystem fileSystem = FileSystem.newInstance(new Configuration());
Configuration conf = fileSystem.getConf();
conf.set("fs.mapr.bailout.on.library.mismatch", "false");
Path OffsetPath = new Path(filePath);
FileStatus file = fileSystem.getFileStatus(filePath); ====> This statement gives error
hbase dependencies used:
<dependency>
<groupId>com.mapr.fs</groupId>
<artifactId>mapr-hbase</artifactId>
<version>6.0.1-mapr</version>
</dependency>
<dependency>
<groupId>org.apache.hbase</groupId>
<artifactId>hbase-client</artifactId>
<version>1.1.8-mapr-1710</version>
</dependency>
How can I correct this?
So it isn't a great idea to just disable the version mismatch error. Some mismatch is OK for some tasks, but some mismatch can be fatal.
To say much more, it would be helpful to have a little bit of clarification.
when you say remote access, are you talking from one cluster to another? Or from a client machine that is outside the cluster?
assuming that you mean the second case (client outside the cluster), what did you install on the client machine?
why did you disable the version mismatch? What versions are you worried will not match?
does the POSIX interface or the local loopback NFS work from the problem node?
does the hadoop shell work from the problem node?
I am trying to setup okta-aws-cli-assume-role, but I have a Windows machine (please don't shoot me!). I think my problem is there is some graphical components, and when I run with a Ubuntu WSL, it can't find the appropriate device.
The full error is:
Graphics Device initialization failed for : es2, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
What should I do?
While some may suggest you a workaround for this problem, I suggest you to take a look at aws-sts docker solution: it uses headless browser under the hood, so there won't be any problems related to the graphics and it is more or less platform independent.
I was exactly in the same situation using WSL, so what I did:
created config.json as described in the Readme
ReadMe suggests to create a Dockerfile, but actually I never had to use it just passing the config parameters to the basic docker image like in the template file
As the result, aws token is generated inside the docker container and put into mounted $HOME/.aws folder, so you can easily call awscli from WLS.
Here is how to make docker working properly with WLS (in short, client in WLS, server installed on Windows with exposed daemon).
One more hint: use --profile=default when generating token, so you don't have to specify it every time you use awscli.
I'm having a node-js app on Heroku using the pdfMerge.js library.
following the documentation I'm using the stream event mechanism as a callback to identify the end of the process
then an exception is thrown :
events.js:167 Error: spawn java ENOENT.
I'm almost sure it's happening because I'm messing required java installation as described here:
pdfmerger combines multiple PDF-files into a single PDF-file. It is a node module that utilizes the Apache PDFBox Library, which the required functionality are distributed along with this module. The only requirement for this module to run, is having Java 6 or higher in the path.
I'm Not familiar enough with Heroku installation/configuration process in order to make it work.
thanks in advance
You can add Java to your app by adding the heroku/jvm buildpack like this:
$ heroku buildpacks:add -i 1 heroku/jvm
Then redeploy with git commit --allow-empty and git push heroku master.
I tried to install confluence on my own ubuntu server, but always failed. The error is:
com.atlassian.util.concurrent.LazyReference$InitializationException: java.lang.IllegalStateException: Spring Application context has not been set
at com.atlassian.util.concurrent.LazyReference.getInterruptibly(LazyReference.java:149)
caused by: java.lang.IllegalStateException: Spring Application context has not been set
at com.atlassian.spring.container.SpringContainerContext.getComponent(SpringContainerContext.java:48)
I saw some solutions in the jira confluence forum saying try to fix the permission of installed directory and home directory. I tried but failed again. How can I fix the problem.
In my case the issue was corrupted confluence.cfg.xml file (contains DB connection stings and other settings). The file size was 0 bytes.
I would suggest to use a VM to create a new installation and borrow confluence.cfg.xml from that installation.
It's embarrassing that this behavior has been allowed to exist for nearly 7 years in a commercial product. This is a basic stuff...
I wish that was on instructions somewhere:
Make single backup copy of confluence.cfg.xml immediately before any writes to it by the application. Application should be able to restore from backed up copy if it gets corrupted.
Atlassian documentation lists the following causes of this problem:
The user running Confluence does not have write permissions to the home folder defined in <install>/confluence/WEB-INF/classes/confluence-init.properties or the install directory.
You are running Confluence as the root user or if you have an application firewall enabled (SeLinux or AppArmor).
The database driver is not located in the <install>/confluence/WEB-INF/lib folder or you are using a database version that is incompatible with the bundled driver.
The hostname of the server can not be resolved.
In my case I was running it as root user inside docker container.
We've installed the NewRelic java agent on our WebSphere Application / WebSphere Commerce system and in the NewRelic logs we are seeing this:
Sep 3, 2013 22:47:53 -0400 NewRelic 14 INFO: The data collector is temporarily unavailable. This can happen periodically. In the event that availability of our servers is not restored after a period of time, then please report this to New Relic. java.net.SocketException: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory
at javax.net.ssl.DefaultSSLSocketFactory.a(SSLSocketFactory.java:11)
at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:6)
at com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:161)
at com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:36)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1184)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:390)
at com.ibm.net.ssl.www2.protocol.https.b.getResponseCode(b.java:75)
at com.newrelic.agent.transport.DataSenderImpl.connectAndSend(DataSenderImpl.java:550)
at com.newrelic.agent.transport.DataSenderImpl.send(DataSenderImpl.java:600)
at com.newrelic.agent.transport.DataSenderImpl.invoke(DataSenderImpl.java:480)
at com.newrelic.agent.transport.DataSenderImpl.invokeNoRunId(DataSenderImpl.java:475)
at com.newrelic.agent.transport.DataSenderImpl.getRedirectHost(DataSenderImpl.java:203)
at com.newrelic.agent.transport.DataSenderImpl.connect(DataSenderImpl.java:193)
at com.newrelic.agent.RPMService.launch(RPMService.java:194)
at com.newrelic.agent.rpm.RPMConnectionServiceImpl$RPMConnectionTask.attemptConnection(RPMConnectionServiceImpl.java:301)
at com.newrelic.agent.rpm.RPMConnectionServiceImpl$RPMConnectionTask.access$1100(RPMConnectionServiceImpl.java:101)
at com.newrelic.agent.rpm.RPMConnectionServiceImpl$RPMConnectionTask$3.run(RPMConnectionServiceImpl.java:235)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:452)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:328)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:161)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:109)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:191)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:215)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919)
at java.lang.Thread.run(Thread.java:738)
Caused by: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory
at javax.net.ssl.SSLJsseUtil.b(SSLJsseUtil.java:125)
at javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:3)
at javax.net.ssl.HttpsURLConnection.getDefaultSSLSocketFactory(HttpsURLConnection.java:41)
at javax.net.ssl.HttpsURLConnection.<init>(HttpsURLConnection.java:46)
at com.ibm.net.ssl.www2.protocol.https.b.<init>(b.java:26)
at com.ibm.net.ssl.www2.protocol.https.Handler.openConnection(Handler.java:1)
at com.ibm.net.ssl.www2.protocol.https.Handler.openConnection(Handler.java:5)
at java.net.URL.openConnection(URL.java:957)
at com.newrelic.agent.transport.DataSenderImpl.createConnection(DataSenderImpl.java:676)
at com.newrelic.agent.transport.DataSenderImpl.connectAndSend(DataSenderImpl.java:540)
... 18 more
There seems to be some documentation about how to update an Eclipse based IDE environment to overcome this error in other situations, but nothing specific to NewRelic. Has anyone seen this before that can offer suggestions on how to fix the issue?
The next release of New Relics Java agent should make it possible to run without any configuration changes. With version 2.21.X and earlier please submit a request for support at support.newrelic.com
Read and see if this publication gives you a hint:
http://www-01.ibm.com/support/docview.wss?uid=swg21584437
I went through the same thing. As you might have gathered from the article liked by Robban WebSphere has some restriction in the SSLConnectionFactory, so a quit fix would be to just edit the newrelic.yml and configure:
# The agent communicates with New Relic via https by
# default. If you want to communicate with newrelic via http,
# then turn off SSL by setting this value to false.
# This work is done asynchronously to the threads that process your
# application code, so response times will not be directly affected
# by this change.
# Default is true.
ssl: false
Good luck.
Version 3.0.0 or later of New Relic's Java Agent should completely resolve this issue without any custom configuration, certainly without turning off SSL! Release notes.