use case:
I'm using embedded-elasticsearch for tests, where some of the tests turn elasticsearch off to simulate errors, so that between any two tests i want to validate that the elasticsearch is back on again.
for that I use a reset method:
I assume that the start() method in EmbeddedElastic is supposedly idempotent as far as the internal ElasticServer instance is concerned: because I see that it's only calling the .start() method if it receives false on isStarted() :
I'm solving this locally by wrapping the EmbeddedElastic with a proxy that has idempotent ensureStarted() and ensureStopped() by means of its own started flag. I think this is a feature that is should move into EmbeddedElastic itself so that other users may enjoy mindlessly resetting the state of the server with no need to track who did what to it beforehand.
use case: I'm using embedded-elasticsearch for tests, where some of the tests turn elasticsearch off to simulate errors, so that between any two tests i want to validate that the elasticsearch is back on again. for that I use a reset method:
I assume that the
start()
method inEmbeddedElastic
is supposedly idempotent as far as the internalElasticServer
instance is concerned: because I see that it's only calling the.start()
method if it receives false onisStarted()
:however,
isStarted()
is implemented by optimistically, lock-free reading thestarted
flag:and the
started
flag may have already been written to by another thread listening to the logs insignalElasticStarted()
:I'm solving this locally by wrapping the
EmbeddedElastic
with a proxy that has idempotentensureStarted()
andensureStopped()
by means of its ownstarted
flag. I think this is a feature that is should move intoEmbeddedElastic
itself so that other users may enjoy mindlessly resetting the state of the server with no need to track who did what to it beforehand.