Skip to content

TransportClient's ClusterStatsResponse deserialization failing within JBoss 6.1 (new issue in 5.0.0-alpha3) #18996

@fassisrosa

Description

@fassisrosa

Within JBoss 6.1, calling TransportClient::admin().cluster().prepareClusterStats().get() breaks in 5.0.0-alpha3, used to work fine in 5.0.0-alpha2

Elasticsearch version: 5.0.0-alpha3

JVM version: 1.8.0_92

OS version: Windows 2012 R2

Description of the problem including expected versus actual behavior:

We are using TransportClient within JBoss 6.1.

In 5.0.0-alpha2 we were able to make the following call:

ClusterStatsResponse clusterStatsResponse = client.admin().cluster().prepareClusterStats().get();

Now when we do the same call in 5.0.0-alpha3 we are getting the following exception:

java.nio.file.FileSystemNotFoundException: Provider "vfs" not installed

Steps to reproduce:

  1. Have the call to TransportClient::admin().cluster().prepareClusterStats().get() within JBoss 6.1

Provide logs (if relevant): Full exception from logs (only client side, not errors on elasticsearch side):

TransportSerializationException[Failed to deserialize response of type [org.elasticsearch.action.admin.cluster.stats.ClusterStatsResponse]]; nested: ExceptionInInitializerError; nested: FileSystemNotFoundException[Provider "vfs" not installed];
at org.elasticsearch.transport.netty.MessageChannelHandler.handleResponse(MessageChannelHandler.java:172)
at org.elasticsearch.transport.netty.MessageChannelHandler.messageReceived(MessageChannelHandler.java:143)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462)
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443)
at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:310)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ExceptionInInitializerError
at org.elasticsearch.action.admin.cluster.node.info.NodeInfo.readFrom(NodeInfo.java:199)
at org.elasticsearch.action.admin.cluster.node.info.NodeInfo.readNodeInfo(NodeInfo.java:191)
at org.elasticsearch.action.admin.cluster.stats.ClusterStatsNodeResponse.readFrom(ClusterStatsNodeResponse.java:85)
at org.elasticsearch.action.admin.cluster.stats.ClusterStatsNodeResponse.readNodeResponse(ClusterStatsNodeResponse.java:74)
at org.elasticsearch.common.io.stream.StreamInput.readList(StreamInput.java:769)
at org.elasticsearch.action.admin.cluster.stats.ClusterStatsResponse.readNodesFrom(ClusterStatsResponse.java:102)
at org.elasticsearch.action.support.nodes.BaseNodesResponse.readFrom(BaseNodesResponse.java:110)
at org.elasticsearch.action.admin.cluster.stats.ClusterStatsResponse.readFrom(ClusterStatsResponse.java:85)
at org.elasticsearch.transport.netty.MessageChannelHandler.handleResponse(MessageChannelHandler.java:169)
... 23 more
Caused by: java.nio.file.FileSystemNotFoundException: Provider "vfs" not installed
at java.nio.file.Paths.get(Paths.java:147)
at org.elasticsearch.common.io.PathUtils.get(PathUtils.java:75)
at org.elasticsearch.Build.getElasticsearchCodebase(Build.java:87)
at org.elasticsearch.Build.(Build.java:50)
... 32 more

Describe the feature:

Looks like some changes were made into alpha3 in the way the ClusterStatsResponse object is deserialized, this is impacting our client usage within JBoss 6.1.

Details of cause of issue:

+) Making the call to getting ClusterStatsResponse, elasticsearch server returns stream that needs to be deserialized into ClusterStatsResponse.
+) ClusterStatsResponse inherits from BaseNodesResponse.
+) readFrom method in BaseNodesResponse now has a call to 'readNodesFrom' (line 110 of BaseNodesResponse, alpha3 tag).
+) 'readNodesFrom' in ClusterStatsResponse calls readNodeResponse (line 102 of ClusterStatsResponse, alpha3 tag).
+) Eventually call makes it to ClusterStatsNodeResponse::readFrom, taht class NodeInfo.readNodeInfo (line 85 of ClusterStatsNodeResponse, alpha3 tag).
+) NodeInfo::readNodeInfo ends up calling NodeInfo::readFrom which calls Build.readBuild (line 199 of NodeInfo, alpha 3 tag).
+) Calling Build.readBuild forces the Build class static block to be executed to populate 'CURRENT'.
+) The code in getElasticsearchCodebase uses java nio (see lines 85-87 of Build, alpha3 tag). The URL returned within JBoss 6.1 is 'vfs://'.
*) There is no file system provider for 'vfs://' so exception is thrown.

This use is only for client, which probably does not care much for Build.CURRENT anyway?
Could this code be changed to either lazily calculate 'CURRRENT' or to set it to 'Unknown' if an exception is thrown attempting
to call 'getLeasticsearchCodebase' (probably better as we cannot really calculate the current build with current code)?
As it stands, this code cannot be used within JBoss 6.1.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions