Java Transport Client 5.4.1 NullPointerException


I am trying to upgrade my service from Elasticsearch 1.4 to Elasticsearch 5.4.1. It run without issues on Centos 6.8, but after the upgrade I am getting the following error:

Exception in thread "main" java.lang.ExceptionInInitializerError
at org.elasticsearch.common.logging.DeprecationLogger.(
at org.elasticsearch.common.xcontent.json.JsonXContentParser.(
at org.elasticsearch.common.xcontent.json.JsonXContent.createParser(
at org.elasticsearch.common.settings.Setting.parseableStringToList(
at org.elasticsearch.common.settings.Setting.lambda$listSetting$27(
at org.elasticsearch.common.settings.Setting.listSetting(
at org.elasticsearch.common.settings.Setting.listSetting(
at org.elasticsearch.client.transport.TransportClient.newPluginService(
at org.elasticsearch.client.transport.TransportClient.buildTemplate(
at org.elasticsearch.client.transport.TransportClient.(
at org.elasticsearch.transport.client.PreBuiltTransportClient.(
at org.elasticsearch.transport.client.PreBuiltTransportClient.(
at org.elasticsearch.transport.client.PreBuiltTransportClient.(
Caused by: java.lang.NullPointerException
at org.elasticsearch.Build.(
... 24 more

What could be the cause of this problem?



1 Like

Never saw that. It sounds like the manifest file is not there.
My guess is that you still have an old elasticsearch jar somewhere in your class path.

My class path has elasticsearch-5.4.1.jar and transport-5.4.1.jar and I do have a manifest file present.

There has been a thread about this issue already, but apparently it has been resolved: ES 5.3 and Java-API 5.3.0 > java.lang.NullPointerException? in Elasticsearch 5.3. However, I am still seeing that issue the the latest version (5.4.1 and 5.4.0).

@jasontedor WDYT?

To complement the information on this issue, we found that:

Returns a JarInputStream with man = null (and most of the other properties are null) possibly because is not being able to read the MANIFEST file.

To verify that there was a Manifest file we manually uncompress the elasticsearch-5.4.1.jar file and the file seems to be correct.

Any ideas what can cause this behaviour?

If it helps:
OS: Centos 6.8
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

How are you starting elasticsearch?

We are starting the elasticsearch with the following config: "elasticsearch"
node.master: true true /var/log/elasticsearch/
path.logs: /var/log/elasticsearch/ "test"

The command is:
/usr/share/elasticsearch/bin/elasticsearch -Epath.conf=/etc/elasticsearch/elasticsearch.yml

How are you starting the transport client, what is it hosted inside of?

Hi jasontedor, here is a snippet:

 val s = Settings.builder()
    .put("", clusterName)

  val client = new PreBuiltTransportClient(s)
  nodes.asScala.foreach { node =>
    client.addTransportAddress(new InetSocketTransportAddress(node))

The exception occurs on the instantiation of the PreBuiltTransportClient

We found that our elasticsearch-5.4.1.jar has a different sha1 hash from the one published on maven central.

We are investigating this issue, but I believe this is the reason why it cannot read the manifest file.

That would indeed be a problem.

Has this been fixed?

@billnbell Is what fixed? The issue reported here for this user was caused by them not using an official distribution.

@jasontedor we are using the official distribution of Elasticsearch.
After more investigation we found that the issue was in our CI system at build time when it create rpms for our Scala services.

Apparently there is some jar repackaging happening on Centos that changes the sha1 sums of the jar files and in the case of elasticsearch-5.4.1.jar when you try to instantiate a PreBuiltTransportClient it does some validation using the MANIFEST file and this was failing because of the different sha1sum.

To fix this we had to explicit remove the repackaging in the spec files generated by sbt and maven.

For sbt (Build.sbt):

import com.typesafe.sbt.packager.rpm.RpmPlugin.Names
val script =
  """%define __os_install_post \
%{_rpmconfigdir}/brp-compress \
%{!?__debug_package:%{_rpmconfigdir}/brp-strip %{__strip}} \
%{_rpmconfigdir}/brp-strip-static-archive %{__strip} \
%{_rpmconfigdir}/brp-strip-comment-note %{__strip} %{__objdump} \

maintainerScripts in Rpm += (Names.Pre -> ((maintainerScripts in Rpm).value.getOrElse(Names.Pre, Nil) :+ script))

For maven (inside the rpm-maven-plugin configuration node) :

                                <defineStatement>_unpackaged_files_terminate_build 0</defineStatement>
                                <defineStatement>__os_install_post \
%{_rpmconfigdir}/brp-compress \
%{!?__debug_package:%{_rpmconfigdir}/brp-strip %{__strip}} \
%{_rpmconfigdir}/brp-strip-static-archive %{__strip} \
%{_rpmconfigdir}/brp-strip-comment-note %{__strip} %{__objdump} \

I'm glad you've found the issue. I want to be clear about something for others that are following this thread. A repackaged distribution is not an official distribution, and we do not support repackaged distributions.

1 Like

Thanks the help and clarification @jasontedor! :slight_smile:

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.