jeudi 6 août 2015

Creating Static and Non-static instances of the same Elasticsearch client

I am working with Elasticsearch where we have 2 ways to instantiating a Client object. One is using a TCP connection and other using an Embedded client.

  • TCP service: The server is already running. You just connect to it and do stuff.
  • Embedded Client: It is an Elasticsearch server in itself. You do not beed any server running for this. It is generally used while testing.

I have a Client based on the TCP connection (StartTCPConn.java) which is supposed to be a Singleton so that every index creation request interacts with that one singleton object.

  • Creation of Index: This is handled by the Implement class. This class have functions that use the Singleton instance of client for initializing the index/settings/mappings. Class also has the objects of a Template class and a Config class.
  • Template class: This contains default settings/mappings of any index. This is generally independent of index creation and its creation is generally done before any index is created. This class has certain functions that need the client instance. i.e. the singleton instance
  • Config class: This is separate for every index

Every Implement object will be a different index. There are other classes similar to Implement which handle searches and use the Implement object for the index name and the same TCP singleton client for searching.

For testing purposes I need a embedded client which is independent of the TCP service. This client starts as soon as Test starts and destroys itself as soon as the test ends. The actual TCP service is not affected by this. And this client is also not singleton. Every test case will have its own Embedded client.

Issue: I require all the default settings/search functions/Index creation methods/config classes for this embedded client as well. But since they are being controlled by a Single object I have to rewrite (copy-paste) all those classes for every test case!!

I did not anticipate this issue but I think that the earlier design was flawed. Could any one suggest a better design so that there is more re-use of the classes?

Aucun commentaire:

Enregistrer un commentaire