While doing some tests, I thought I uncovered a bug in the
cluster-health/wait-for-yellow request. No matter what settings I tried,
the request would always return immediately with no timeout. I then
realized that the request is actually something like "wait for AT LEAST
yellow state". In other words, a GREEN state would satisfy a wait for
YELLOW state.
Obviously few people are interested in waiting for when a cluster goes from
GREEN to YELLLOW, but I am one of those few. I would love to propose a true
wait-for-yellow (and even red), but it would be difficult to come up with
an appropriately named call since the waitForYellow is taken and should be
renamed (breaking code in the process).
I am assuming the current code is a feature and not a bug, in which case
the documentation should reflect that thinking (willing to fix). But in the
meantime, how can one be notified if a cluster changes its state from GREEN
without constant polling?
And while we are at it, how does one effectively use waitForEvents?
--
Ivan
On Thu, May 22, 2014 at 9:20 AM, Ivan Brusic ivan@brusic.com wrote:
While doing some tests, I thought I uncovered a bug in the
cluster-health/wait-for-yellow request. No matter what settings I tried,
the request would always return immediately with no timeout. I then
realized that the request is actually something like "wait for AT LEAST
yellow state". In other words, a GREEN state would satisfy a wait for
YELLOW state.
Obviously few people are interested in waiting for when a cluster goes
from GREEN to YELLLOW, but I am one of those few. I would love to propose a
true wait-for-yellow (and even red), but it would be difficult to come up
with an appropriately named call since the waitForYellow is taken and
should be renamed (breaking code in the process).
I am assuming the current code is a feature and not a bug, in which case
the documentation should reflect that thinking (willing to fix). But in the
meantime, how can one be notified if a cluster changes its state from GREEN
without constant polling?
Our current workflow for a rolling restart checks that the cluster goes
yellow after a data node leaves. We are using polling to validate this,
but I would much rather have a blocking wait call.
-T
On Thursday, May 22, 2014 9:20:48 AM UTC-7, Ivan Brusic wrote:
While doing some tests, I thought I uncovered a bug in the
cluster-health/wait-for-yellow request. No matter what settings I tried,
the request would always return immediately with no timeout. I then
realized that the request is actually something like "wait for AT LEAST
yellow state". In other words, a GREEN state would satisfy a wait for
YELLOW state.
Obviously few people are interested in waiting for when a cluster goes
from GREEN to YELLLOW, but I am one of those few. I would love to propose a
true wait-for-yellow (and even red), but it would be difficult to come up
with an appropriately named call since the waitForYellow is taken and
should be renamed (breaking code in the process).
I am assuming the current code is a feature and not a bug, in which case
the documentation should reflect that thinking (willing to fix). But in the
meantime, how can one be notified if a cluster changes its state from GREEN
without constant polling?
Our current workflow for a rolling restart checks that the cluster goes
yellow after a data node leaves. We are using polling to validate this,
but I would much rather have a blocking wait call.
-T
On Thursday, May 22, 2014 9:20:48 AM UTC-7, Ivan Brusic wrote:
While doing some tests, I thought I uncovered a bug in the
cluster-health/wait-for-yellow request. No matter what settings I tried,
the request would always return immediately with no timeout. I then
realized that the request is actually something like "wait for AT LEAST
yellow state". In other words, a GREEN state would satisfy a wait for
YELLOW state.
Obviously few people are interested in waiting for when a cluster goes
from GREEN to YELLLOW, but I am one of those few. I would love to propose a
true wait-for-yellow (and even red), but it would be difficult to come up
with an appropriately named call since the waitForYellow is taken and
should be renamed (breaking code in the process).
I am assuming the current code is a feature and not a bug, in which case
the documentation should reflect that thinking (willing to fix). But in the
meantime, how can one be notified if a cluster changes its state from GREEN
without constant polling?
It would be helpful to add methods like waitForGreenToYellow(),
waitForYellowToGreen(), waitFor RedToYellow(), waitForYellowToRed(), ...
for describing exactly the cluster state transitions to wait for.
Jörg
On Mon, Jun 23, 2014 at 6:33 PM, Ivan Brusic ivan@brusic.com wrote:
It appears that the documentation was updated 3 days ago. It now reflects
the true behavior of the code.
That said, I would still like to see a proper wait for yellow or red.
Our current workflow for a rolling restart checks that the cluster goes
yellow after a data node leaves. We are using polling to validate this,
but I would much rather have a blocking wait call.
-T
On Thursday, May 22, 2014 9:20:48 AM UTC-7, Ivan Brusic wrote:
While doing some tests, I thought I uncovered a bug in the
cluster-health/wait-for-yellow request. No matter what settings I tried,
the request would always return immediately with no timeout. I then
realized that the request is actually something like "wait for AT LEAST
yellow state". In other words, a GREEN state would satisfy a wait for
YELLOW state.
Obviously few people are interested in waiting for when a cluster goes
from GREEN to YELLLOW, but I am one of those few. I would love to propose a
true wait-for-yellow (and even red), but it would be difficult to come up
with an appropriately named call since the waitForYellow is taken and
should be renamed (breaking code in the process).
I am assuming the current code is a feature and not a bug, in which case
the documentation should reflect that thinking (willing to fix). But in the
meantime, how can one be notified if a cluster changes its state from GREEN
without constant polling?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.