2
votes

I have been working on a messaging webapp using Spring MVC with ElasticSearch as the backend store for operational data. We are using a traditional approach where we are doing stateless app servers and clustering them while keeping some shared state using Hazelcast. The ElasticSearch cluster is separate and is accessed via Transport client.

I came across some examples using Node client and found that we can cluster the app servers using ElasticSearch. Each node will then be able to serve REST services as well as store operational data. I have run a small cluster of 4 nodes and it seems to work fine.

Are there ay pitfalls of using ElasticSearch in this way? Has anyone run such a setup in production? It seems all the articles and posts on this topic go towards running integration tests using embedded server but not production deployments.

1

1 Answers

1
votes

Yes there are pitfalls:

  • Are you sure you want your ES instances to shut down and re-join the cluster each time you restart your app? (which can grow out of control if deploying often)
  • As both your application and ES will be sharing the same JVM, it makes it hard to fine tune and monitor.

And I'm sure there are others to add.

As I do use an embedded instance of ElasticSearch in my webapp, I can advise I would not recommend using it this way in production unless you have very specific needs.