The online guide recommends using LTS version of JDK. But the one it bundles with (12.0.2) is not LTS. Should I just use that version or downgrade?
I got the bundled version from the official docker image for 7.3.1
I assume most folks just use the bundled version then?
From looking at ES guthub commits. It seems you guys are upgrading/switching JDK like crazy.
Is the bundled JDK an experimental thing?
Does anybody have any insight into this?
One benefit and primary reason for continually upgrading is the performance and bug fixes that come along with new versions. While LTS versions would contain security fixes, large performance improvements do not get backported. Thus, we want to keep each new release of Elasticsearch with the best performance and fewest bugs available to us at the time of release.
Thanks. So would you recommend simply using the bundled version then?
JDK 12 seems to end support this month this year.
What's the best practice in general you would recommend?
Do I simply upgrade ES say from 7.3.1 to 7.5? Or just upgrade JDK while keep 7.3.1?
I understand the need to keep up to date but it sometimes contradict production deployment risks assessment.
What do you guys do in your own hosted cloud service? I assume that method would've been internally tested, hence this question.
I just wish to know the testing methodology so I can plan my own production accordingly.
Thanks again.
Yes, we advocate that all of our users use the bundled JDK. We think this is the simplest for our users, and they have full confidence that Elasticsearch has been tested against the exact version deployed. It takes away the pain of deploying and upgrading the JVM.
When we say that we support JDK N for Elasticsearch X.Y, we mean that we support it for the life of Elasticsearch X.Y, independent of the lifecycle of JDK N. So even though JDK 12 is end of life now, we still support running Elasticsearch 7.3 on it. This alleviates the pressure to upgrade the JVM when it becomes end of life.
We feel this is the best approach for users because we put out minor versions frequently, and we aim to keep upgrading between minor versions simple and straightforward. This means that for users that can deploy new versions of Elasticsearch frequently, they are almost always on a latest JDK that is not end of life.
The only time deviation from this might be necessary is if there is a security issue in the JDK that manifests as a security issue in a maintained version of Elasticsearch. To date, this has never happened, we tend to not use the components in the JDK that are prone to these sorts of issues, and we take a defense in depth approach with the use of the security manager and the use of system call filtering (e.g., seccomp). If there were such a security issue in the JDK that manifested as a security issue in Elasticsearch, we would treat it like any other security issue in Elasticsearch and put out a release that mitigated the security issue.
Rather than talk about what we do in our Cloud service, I will talk about what we are working towards. Sometime in the future (I can’t give a timeline for this), our Cloud service will switch to using the bundled JDK as well. That’s a project that is in-flight.
2 Likes
Thanks.
Bundled version it is.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.