Method code too large error in Elasticsearch logs

Hello,

I am investigation performance issues of Elasticsearch cluster and in the logs of the cluster I keep finding the following error:

nested: NotSerializableExceptionWrapper[runtime_exception: Method code too large!];
	at org.elasticsearch.search.SearchService.parseSource(SearchService.java:873)
	at org.elasticsearch.search.SearchService.createContext(SearchService.java:667)
	at org.elasticsearch.search.SearchService.createAndPutContext(SearchService.java:633)
	at org.elasticsearch.search.SearchService.executeQueryPhase(SearchService.java:377)
	at org.elasticsearch.search.action.SearchServiceTransportAction$SearchQueryTransportHandler.messageReceived(SearchServiceTransportAction.java:368)
	at org.elasticsearch.search.action.SearchServiceTransportAction$SearchQueryTransportHandler.messageReceived(SearchServiceTransportAction.java:365)
	at org.elasticsearch.transport.TransportRequestHandler.messageReceived(TransportRequestHandler.java:33)
	at org.elasticsearch.transport.RequestHandlerRegistry.processMessageReceived(RequestHandlerRegistry.java:77)
	at org.elasticsearch.transport.netty.MessageChannelHandler$RequestHandler.doRun(MessageChannelHandler.java:293)
	at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

So I was wondering what this error could be caused by and if it could indicate why there are performance issues?

Hey,

can you share more information? What Elasticsearch version is this, what JVM version are you running?

Can you trigger this manually? Also, can you provide the full stack trace from the node where this occured? That would be awesome!

--Alex

Yes, sure. It is Elasticsearch version 2.4.6 and it is OpenJDK version 1.8.0_191.

I am not sure if it is possible to trigger it manually and it is the full stack trace in my question.

That is a four year old version, which has seen three new major versions in between, so it is definetely not supported anymore. Any possibility for upgrading in sight?

I'd be a little surprised if that is all the loglines in question, as the first line states, that this was a nested throw (unless that exception occured many times over in the running JVM).

Are you using long scripts in your queries? Apart from that I don't have too much other ideas and given the age of your version I don't think debugging further makes a ton of sense as I don't remember a lot of the nasty details from a long time ago...

I am not sure if there is possibility of upgrading in sight.

Yes there are very long scripts in the queries, could it cause the issue?

Yes, that is my only working assumption, as scripts get compiled to code and might produce bytecode that is hitting the above limitation.