org.elasticsearch.xpack.notification.email.Account$1.run(Account.java:55) should cast to CommandMap not javax.activation.MailcapCommandMap

Elastic Stack Elasticsearch
1

Hoping this is the right place to report this. I'm basically requesting on the offending line below to cast to CommandMap (the interface) rather than the concrete class MailcapCommandMap as our app uses a custom ComandMap.

Kibana version: 5.5.0
Elasticsearch version: 5.5.0
Server OS version: Linux 4.4.0-93-generic #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Browser version: Chrome
Browser OS version: Linux

Description of the problem including expected versus actual behavior:

When ES cluster was in a bad state (single master in test cluster was in heavy GC loop) the transport client could not initialise XPackPlugin due to an incorrect cast in the X-PACK code. We have registered a custom CommandMap called UnmodifiableMailcapCommandMap as can be seen in the logs below.

Steps to reproduce:

Get cluster into bad state.
Install a custom CommandMap into the JVM.
Try to connect with transport client and X-PACK.
Errors in browser console (if relevant):

Provide logs and/or server output (if relevant):

java.lang.ExceptionInInitializerError: null
at org.elasticsearch.xpack.XPackPlugin.(XPackPlugin.java:183) ~[x-pack-api-5.5.0.jar:5.5.0]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:1.8.0_92]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:1.8.0_92]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:1.8.0_92]
at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[?:1.8.0_92]
at org.elasticsearch.plugins.PluginsService.loadPlugin(PluginsService.java:423) ~[elasticsearch-5.5.0.jar:5.5.0]
at org.elasticsearch.plugins.PluginsService.(PluginsService.java:103) ~[elasticsearch-5.5.0.jar:5.5.0]
at org.elasticsearch.client.transport.TransportClient.newPluginService(TransportClient.java:101) ~[elasticsearch-5.5.0.jar:5.5.0]
at org.elasticsearch.client.transport.TransportClient.buildTemplate(TransportClient.java:126) ~[elasticsearch-5.5.0.jar:5.5.0]
at org.elasticsearch.client.transport.TransportClient.(TransportClient.java:265) ~[elasticsearch-5.5.0.jar:5.5.0]
at org.elasticsearch.transport.client.PreBuiltTransportClient.(PreBuiltTransportClient.java:130) ~[transport-5.5.0.jar:5.5.0]
at org.elasticsearch.xpack.client.PreBuiltXPackTransportClient.(PreBuiltXPackTransportClient.java:55) ~[x-pack-transport-5.5.0.jar:5.5.0]
at org.elasticsearch.xpack.client.PreBuiltXPackTransportClient.(PreBuiltXPackTransportClient.java:50) ~[x-pack-transport-5.5.0.jar:5.5.0]
at org.elasticsearch.xpack.client.PreBuiltXPackTransportClient.(PreBuiltXPackTransportClient.java:46) ~[x-pack-transport-5.5.0.jar:5.5.0]
...
Caused by: java.lang.ClassCastException: com.xxxx.xxxx.UnmodifiableMailcapCommandMap cannot be cast to javax.activation.MailcapCommandMap
at org.elasticsearch.xpack.notification.email.Account$1.run(Account.java:55) ~[x-pack-api-5.5.0.jar:5.5.0]
at org.elasticsearch.xpack.notification.email.Account$1.run(Account.java:51) ~[x-pack-api-5.5.0.jar:5.5.0]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_92]
at org.elasticsearch.xpack.notification.email.Account.(Account.java:51) ~[x-pack-api-5.5.0.jar:5.5.0]
... 35 more

2

Hey,

indeed this is something we do not cater for currently. From Elasticsearch 6.2 onwards we do load a different Plugin, but as this code is in a static code block we might load it anyway.

I will investigate and report back. Thanks for bringing this up!

--Alex

3

So I tested this up to 6.2, and this is the first version where this is fixed and I did not get an error back, once I set a custom mailcap and then created a client.

May I ask you to test that one and see if that works for you as well?

4

Thanks.. that's good to hear it is fixed in 6.2. We are stuck on 5.5.0 for now but we'll be upgrading hopefully in around 4 months.

5

I'd still be super happy, if you could give it a quick test (to make sure I didnt create an artificial test), but of course a few things need to be fixed before you compile.

Can you either create the transport client before you configure the mailcap or temporarily change it back to the original one as a current workaround? You should not have any problems during runtime, it is really only about the initialization I think.

--Alex

6

I wish we could do a quick test, but our application is gigantic with many dependencies that make this non-trivial I'm afraid. The way the product starts up all the utilities are initialised (like the custom mailcap) before a transport client is created.

I appreciate your help here. The issue only happens when the cluster was down but I thought it was worth reporting. I can't see the code of course but hopefully doing a search for any explicit cast on (MailcapCommandMap) is not present anywhere now?

7

even simpler: the client from 6.2 onwards does not contain that class (and that code) anymore

8

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