New to Elastic Search, I get this exception: org.elasticsearch.action.UnavailableShardsException


(ogregras) #1

I'm new to Elastic search, the project is fantastic! In fact it works very
well most of the time. But once in a while (not sure when exactly) I get
this exception:

=======================

org.elasticsearch.action.UnavailableShardsException: [autopage][0] [2]
shardIt, [0] active : Timeout waiting for [1m], request: index
{[XXX][YYY][4], source[{"title":"A title","body":"A body"}]}
at
org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$3.onTimeout(TransportShardReplicationOperationAction.java:419)
at
org.elasticsearch.cluster.service.InternalClusterService$NotifyTimeout.run(InternalClusterService.java:305)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

=======================

Things to know:

  1. I use Elastic Search as an embeded search server in a Java web
    application (using the Play framework, but not using the Play Elastic module
    written by Felipe Oliveira ).

  2. I currently don't really need replication. My web application is not
    critical and I have a way to reindex eveything easily if a problem occures.

  3. I want something simple: I start my Java application, it starts the
    Elastic Search server. No external Elastic server.

  4. I would prefere not to use any external .yml configuration file. I'd
    prefere to set all settings using Java directly.

  5. Here's the way I currently start Elastic in my application (thanks to
    Felipe Oliveira of the Play Elastic Module, I learned a lot from his code):


ImmutableSettings.Builder settings = ImmutableSettings.settingsBuilder();
settings.put("client.transport.sniff", true);
settings.put("path.home", "/path/to/elastic/home");

// test
settings.put("index.number_of_replicas", 1);
settings.put("action.write_consistency", "one");

settings.build();

NodeBuilder nb = new NodeBuilder().settings(settings)
.local(true)
.client(false)
.clusterName(clusterName)
.data(true);
Node node = nb.node();

Client client = node.client();

I'm not sure about the "index.number_of_replicas" and
"action.write_consistency" settings. I think they may have something to do
with my problem (ie:
http://elasticsearch-users.115913.n3.nabble.com/org-elasticsearch-action-UnavailableShardsException-td2210314.html
) but I don't know what I need to use for those settings. I still have
UnavailableShardsExceptions with those current settings (I had the
exceptions without them too!).

Again, I'm a newbie and I'm still not sure to understand the differences
between indices, shards, nodes, etc.

What settings would you recommend for my application?

Thanks a lot for any help!


(OlgaT) #2

I have the same problem starting from 0.17.3 version - 0.17.2 it
doesn't happen.

On Aug 11, 3:25 am, ogregras ogreg...@gmail.com wrote:

I'm new to Elastic search, the project is fantastic! In fact it works very
well most of the time. But once in a while (not sure when exactly) I get
this exception:

=======================

org.elasticsearch.action.UnavailableShardsException: [autopage][0] [2]
shardIt, [0] active : Timeout waiting for [1m], request: index
{[XXX][YYY][4], source[{"title":"A title","body":"A body"}]}
at
org.elasticsearch.action.support.replication.TransportShardReplicationOpera tionAction$AsyncShardOperationAction$3.onTimeout(TransportShardReplicationO perationAction.java:419)
at
org.elasticsearch.cluster.service.InternalClusterService$NotifyTimeout.run( InternalClusterService.java:305)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

=======================

Things to know:

  1. I use Elastic Search as an embeded search server in a Java web
    application (using the Play framework, but not using the Play Elastic module
    written by Felipe Oliveira ).

  2. I currently don't really need replication. My web application is not
    critical and I have a way to reindex eveything easily if a problem occures.

  3. I want something simple: I start my Java application, it starts the
    Elastic Search server. No external Elastic server.

  4. I would prefere not to use any external .yml configuration file. I'd
    prefere to set all settings using Java directly.

  5. Here's the way I currently start Elastic in my application (thanks to
    Felipe Oliveira of the Play Elastic Module, I learned a lot from his code):


ImmutableSettings.Builder settings = ImmutableSettings.settingsBuilder();
settings.put("client.transport.sniff", true);
settings.put("path.home", "/path/to/elastic/home");

// test
settings.put("index.number_of_replicas", 1);
settings.put("action.write_consistency", "one");

settings.build();

NodeBuilder nb = new NodeBuilder().settings(settings)
.local(true)
.client(false)
.clusterName(clusterName)
.data(true);
Node node = nb.node();

Client client = node.client();

I'm not sure about the "index.number_of_replicas" and
"action.write_consistency" settings. I think they may have something to do
with my problem (ie:http://elasticsearch-users.115913.n3.nabble.com/org-elasticsearch-act...
) but I don't know what I need to use for those settings. I still have
UnavailableShardsExceptions with those current settings (I had the
exceptions without them too!).

Again, I'm a newbie and I'm still not sure to understand the differences
between indices, shards, nodes, etc.

What settings would you recommend for my application?

Thanks a lot for any help!


(OlgaT) #3

Sorry, it happens also in 0.17.2

On Aug 11, 7:43 am, OlgaT tubm...@gmail.com wrote:

I have the same problem starting from 0.17.3 version - 0.17.2 it
doesn't happen.

On Aug 11, 3:25 am, ogregras ogreg...@gmail.com wrote:

I'm new to Elastic search, the project is fantastic! In fact it works very
well most of the time. But once in a while (not sure when exactly) I get
this exception:

=======================

org.elasticsearch.action.UnavailableShardsException: [autopage][0] [2]
shardIt, [0] active : Timeout waiting for [1m], request: index
{[XXX][YYY][4], source[{"title":"A title","body":"A body"}]}
at
org.elasticsearch.action.support.replication.TransportShardReplicationOpera tionAction$AsyncShardOperationAction$3.onTimeout(TransportShardReplicationO perationAction.java:419)
at
org.elasticsearch.cluster.service.InternalClusterService$NotifyTimeout.run( InternalClusterService.java:305)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

=======================

Things to know:

  1. I use Elastic Search as an embeded search server in a Java web
    application (using the Play framework, but not using the Play Elastic module
    written by Felipe Oliveira ).
  1. I currently don't really need replication. My web application is not
    critical and I have a way to reindex eveything easily if a problem occures.
  1. I want something simple: I start my Java application, it starts the
    Elastic Search server. No external Elastic server.
  1. I would prefere not to use any external .yml configuration file. I'd
    prefere to set all settings using Java directly.
  1. Here's the way I currently start Elastic in my application (thanks to
    Felipe Oliveira of the Play Elastic Module, I learned a lot from his code):

ImmutableSettings.Builder settings = ImmutableSettings.settingsBuilder();
settings.put("client.transport.sniff", true);
settings.put("path.home", "/path/to/elastic/home");

// test
settings.put("index.number_of_replicas", 1);
settings.put("action.write_consistency", "one");

settings.build();

NodeBuilder nb = new NodeBuilder().settings(settings)
.local(true)
.client(false)
.clusterName(clusterName)
.data(true);
Node node = nb.node();

Client client = node.client();

I'm not sure about the "index.number_of_replicas" and
"action.write_consistency" settings. I think they may have something to do
with my problem (ie:http://elasticsearch-users.115913.n3.nabble.com/org-elasticsearch-act...
) but I don't know what I need to use for those settings. I still have
UnavailableShardsExceptions with those current settings (I had the
exceptions without them too!).

Again, I'm a newbie and I'm still not sure to understand the differences
between indices, shards, nodes, etc.

What settings would you recommend for my application?

Thanks a lot for any help!


(Shay Banon) #4

You don't need to set the write consistency, also, the number of replicas
should be 0 since you start just a single node. I would even set the node to
be local (no discovery). You don't need to set the path.home setting, you
can have it embedded in your app (jar files) and thats it.

Regarding the failure, do you get it on startup? I suggest waiting for green
health after starting the node, just to wait for it to recover itself if
needed. Note, a green health means all shards are allocated, so in your
case, make sure to set the number of replicas to 0. Also, if its a single
node, you probably don't need the default 5 shards for an index.

Here is how you wait for green health:

client.admin().cluster().prepareHealth().setWaitForGreenStatus().execute().actionGet().

On Thu, Aug 11, 2011 at 3:25 AM, ogregras ogregras@gmail.com wrote:

I'm new to Elastic search, the project is fantastic! In fact it works very
well most of the time. But once in a while (not sure when exactly) I get
this exception:

=======================

org.elasticsearch.action.UnavailableShardsException: [autopage][0] [2]
shardIt, [0] active : Timeout waiting for [1m], request: index
{[XXX][YYY][4], source[{"title":"A title","body":"A body"}]}
at
org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$3.onTimeout(TransportShardReplicationOperationAction.java:419)
at
org.elasticsearch.cluster.service.InternalClusterService$NotifyTimeout.run(InternalClusterService.java:305)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

=======================

Things to know:

  1. I use Elastic Search as an embeded search server in a Java web
    application (using the Play framework, but not using the Play Elastic module
    written by Felipe Oliveira ).

  2. I currently don't really need replication. My web application is not
    critical and I have a way to reindex eveything easily if a problem occures.

  3. I want something simple: I start my Java application, it starts the
    Elastic Search server. No external Elastic server.

  4. I would prefere not to use any external .yml configuration file. I'd
    prefere to set all settings using Java directly.

  5. Here's the way I currently start Elastic in my application (thanks to
    Felipe Oliveira of the Play Elastic Module, I learned a lot from his code):


ImmutableSettings.Builder settings = ImmutableSettings.settingsBuilder();
settings.put("client.transport.sniff", true);
settings.put("path.home", "/path/to/elastic/home");

// test
settings.put("index.number_of_replicas", 1);
settings.put("action.write_consistency", "one");

settings.build();

NodeBuilder nb = new NodeBuilder().settings(settings)
.local(true)
.client(false)
.clusterName(clusterName)
.data(true);
Node node = nb.node();

Client client = node.client();

I'm not sure about the "index.number_of_replicas" and
"action.write_consistency" settings. I think they may have something to do
with my problem (ie:
http://elasticsearch-users.115913.n3.nabble.com/org-elasticsearch-action-UnavailableShardsException-td2210314.html) but I don't know what I need to use for those settings. I still have
UnavailableShardsExceptions with those current settings (I had the
exceptions without them too!).

Again, I'm a newbie and I'm still not sure to understand the differences
between indices, shards, nodes, etc.

What settings would you recommend for my application?

Thanks a lot for any help!


(ogregras) #5

OlgaT,

Are you then using a version prior to 0.17.2 because of this? Can you
confirm this error doesn't occures in prior versions?


(ogregras) #6

Thanks for the help kimchy.

So here are my new settings :


settings.put("index.number_of_replicas", 0);
settings.put("index.number_of_shards", 1);

Is that what you suggest?

Here is how you wait for green health:

client.admin().cluster().
prepareHealth().setWaitForGreenStatus().execute().actionGet().

I'll try that. You way be right and I wasn't waiting enough before using the
Node.

Weird thing though... I try:


ClusterHealthResponse healthResponse =
client.admin().cluster().prepareHealth().setWaitForGreenStatus().execute().actionGet();
ClusterHealthStatus healthStatus = healthResponse.status();

It returns but the healthStatus is YELLOW, not GREEN. Is that normal? Even
if I used setWaitForGreenStatus()?

Thanks again for the help.


(ogregras) #7

It returns but the healthStatus is YELLOW, not GREEN. Is that normal? Even
if I used setWaitForGreenStatus()?

Hummm, now it returns GREEN as expected. Maybe I had an hallucination!

Anyway, since I deleted all the "data" folder and started from scratch, it
seems to be working well now. I just wait for the healthStatus before
running any query.

I'll let you know if the exception still occures.


(Shay Banon) #8

Its yellow possibly because the setting for number of replicas was not
applied? yellow means all primary shards are allocated, but replicas are not
(possibly yet...).

On Thu, Aug 11, 2011 at 3:18 PM, ogregras ogregras@gmail.com wrote:

Thanks for the help kimchy.

So here are my new settings :


settings.put("index.number_of_replicas", 0);
settings.put("index.number_of_shards", 1);

Is that what you suggest?

Here is how you wait for green health:

client.admin().cluster().
**> prepareHealth().**setWaitForGreenStatus().**execute().actionGet().

I'll try that. You way be right and I wasn't waiting enough before using
the Node.

Weird thing though... I try:


ClusterHealthResponse healthResponse =
client.admin().cluster().prepareHealth().setWaitForGreenStatus().execute().actionGet();
ClusterHealthStatus healthStatus = healthResponse.status();

It returns but the healthStatus is YELLOW, not GREEN. Is that normal? Even
if I used setWaitForGreenStatus()?

Thanks again for the help.


(ogregras) #9

You know better than me!

It's just a little bit odd that setWaitForGreenStatus() returns and the
status is not green! :slight_smile:

But currently everything seems to be running well. So thanks again for the
help!


(Shay Banon) #10

It waits for green status for a timeout, and then returns. It returns what
the status is now, and a flag indicating if it timed out. We don't want to
block forever :slight_smile:

On Fri, Aug 12, 2011 at 12:03 AM, ogregras ogregras@gmail.com wrote:

You know better than me!

It's just a little bit odd that setWaitForGreenStatus() returns and the
status is not green! :slight_smile:

But currently everything seems to be running well. So thanks again for the
help!


(Jamshid) #11

FYI I'm also seeing UnavailableShardsException with 0.17.4. I did not
see it with 0.16.5.

I started a test with a clean data directory, single node, created a
couple of indexes (one with five shards and another with ten) and
verified elasticsearch-head showed all was Yellow (since no replicas).

Then I tried adding a document but got that exception:

curl -XPUT http://localhost:9200/five/named/1234 -d '{"named":
{"context": "Domain001/Bucket0001", "name": "File612606243717652",
"size": "90803308" }}'

{"error":"UnavailableShardsException[[five][3] [3] shardIt, [1]
active : Timeout waiting for [1m], request: index {[five][named]
[1234], source[{....

So I killed java and restarted, this is all that got logged:

...
[2011-08-11 18:48:46,383][INFO ][node ] [Mantra]
{elasticsearch/0.17.4}[14437]:
started
[2011-08-11 18:48:46,399][INFO ][gateway ] [Mantra]
recovered [2] indices into
cluster_state

And now cluster health is stuck in red:

curl -XGET 'http://localhost:9200/_cluster/health'
{"cluster_name":"mytest","status":"red","timed_out":false,"number_of_nodes":
1,"number_of_data_nodes":1,"active_primary_shards":0,"active_shards":
0,"relocating_shards":0,"initializing_shards":0,"unassigned_shards":
45}

Same problem after another restart.

Btw elasticsearch-head shows 3 (why not 2?) replicas, all Unassigned.

Any ideas?

--Jamshid

On Aug 11, 4:27 pm, Shay Banon kim...@gmail.com wrote:

It waits for green status for a timeout, and then returns. It returns what
the status is now, and a flag indicating if it timed out. We don't want to
block forever :slight_smile:

On Fri, Aug 12, 2011 at 12:03 AM, ogregras ogreg...@gmail.com wrote:

You know better than me!

It's just a little bit odd that setWaitForGreenStatus() returns and the
status is not green! :slight_smile:

But currently everything seems to be running well. So thanks again for the
help!


(Shay Banon) #12

Can you post a curl recreation from "clean data" and notes when to stop the
server and start it?

On Fri, Aug 12, 2011 at 3:07 AM, Jamshid jamshid69@gmail.com wrote:

FYI I'm also seeing UnavailableShardsException with 0.17.4. I did not
see it with 0.16.5.

I started a test with a clean data directory, single node, created a
couple of indexes (one with five shards and another with ten) and
verified elasticsearch-head showed all was Yellow (since no replicas).

Then I tried adding a document but got that exception:

curl -XPUT http://localhost:9200/five/named/1234 -d '{"named":
{"context": "Domain001/Bucket0001", "name": "File612606243717652",
"size": "90803308" }}'

{"error":"UnavailableShardsException[[five][3] [3] shardIt, [1]
active : Timeout waiting for [1m], request: index {[five][named]
[1234], source[{....

So I killed java and restarted, this is all that got logged:

...
[2011-08-11 18:48:46,383][INFO ][node ] [Mantra]
{elasticsearch/0.17.4}[14437]:
started
[2011-08-11 18:48:46,399][INFO ][gateway ] [Mantra]
recovered [2] indices into
cluster_state

And now cluster health is stuck in red:

curl -XGET 'http://localhost:9200/_cluster/health'

{"cluster_name":"mytest","status":"red","timed_out":false,"number_of_nodes":
1,"number_of_data_nodes":1,"active_primary_shards":0,"active_shards":
0,"relocating_shards":0,"initializing_shards":0,"unassigned_shards":
45}

Same problem after another restart.

Btw elasticsearch-head shows 3 (why not 2?) replicas, all Unassigned.

Any ideas?

--Jamshid

On Aug 11, 4:27 pm, Shay Banon kim...@gmail.com wrote:

It waits for green status for a timeout, and then returns. It returns
what
the status is now, and a flag indicating if it timed out. We don't want
to
block forever :slight_smile:

On Fri, Aug 12, 2011 at 12:03 AM, ogregras ogreg...@gmail.com wrote:

You know better than me!

It's just a little bit odd that setWaitForGreenStatus() returns and
the

status is not green! :slight_smile:

But currently everything seems to be running well. So thanks again for
the

help!


(Jamshid) #13

I tried reproducing on 0.17.4 and was not able to. I'll upgrade to
0.17.6 and try to get more information if I see it again.

Thanks,
Jamshid

On Aug 12, 9:35 am, Shay Banon kim...@gmail.com wrote:

Can you post a curl recreation from "clean data" and notes when to stop the
server and start it?

On Fri, Aug 12, 2011 at 3:07 AM, Jamshid jamshi...@gmail.com wrote:

FYI I'm also seeing UnavailableShardsException with 0.17.4. I did not
see it with 0.16.5.

I started a test with a clean data directory, single node, created a
couple of indexes (one with five shards and another with ten) and
verified elasticsearch-head showed all was Yellow (since no replicas).

Then I tried adding a document but got that exception:

curl -XPUThttp://localhost:9200/five/named/1234-d '{"named":
{"context": "Domain001/Bucket0001", "name": "File612606243717652",
"size": "90803308" }}'

{"error":"UnavailableShardsException[[five][3] [3] shardIt, [1]
active : Timeout waiting for [1m], request: index {[five][named]
[1234], source[{....

So I killed java and restarted, this is all that got logged:

...
[2011-08-11 18:48:46,383][INFO ][node ] [Mantra]
{elasticsearch/0.17.4}[14437]:
started
[2011-08-11 18:48:46,399][INFO ][gateway ] [Mantra]
recovered [2] indices into
cluster_state

And now cluster health is stuck in red:

curl -XGET 'http://localhost:9200/_cluster/health'

{"cluster_name":"mytest","status":"red","timed_out":false,"number_of_nodes" :
1,"number_of_data_nodes":1,"active_primary_shards":0,"active_shards":
0,"relocating_shards":0,"initializing_shards":0,"unassigned_shards":
45}

Same problem after another restart.

Btw elasticsearch-head shows 3 (why not 2?) replicas, all Unassigned.

Any ideas?

--Jamshid

On Aug 11, 4:27 pm, Shay Banon kim...@gmail.com wrote:

It waits for green status for a timeout, and then returns. It returns
what
the status is now, and a flag indicating if it timed out. We don't want
to
block forever :slight_smile:

On Fri, Aug 12, 2011 at 12:03 AM, ogregras ogreg...@gmail.com wrote:

You know better than me!

It's just a little bit odd that setWaitForGreenStatus() returns and
the

status is not green! :slight_smile:

But currently everything seems to be running well. So thanks again for
the

help!


(lecochien) #14

Hello,
I've receive the same error (UnavailableShardsException) when i'm
trying to create an index with 0.17.6 and a s3 gateway.
the first time my index settings was :
"settings" : {
"index" : {
"number_of_shards" : 3,
"number_of_replicas" : 2,
And it doesn't work.
the second time i've changed the settings to :
"settings" : {
"index" : {
"number_of_shards" : 3,
"number_of_replicas" : 1,
and it's worked.
Maybe it could help you..
bye.
(sorry for my bad english... :wink:

On 15 août, 05:48, Jamshid jamshi...@gmail.com wrote:

I tried reproducing on 0.17.4 and was not able to. I'll upgrade to
0.17.6 and try to get more information if I see it again.

Thanks,
Jamshid

On Aug 12, 9:35 am, Shay Banon kim...@gmail.com wrote:

Can you post a curl recreation from "clean data" and notes when to stop the
server and start it?

On Fri, Aug 12, 2011 at 3:07 AM, Jamshid jamshi...@gmail.com wrote:

FYI I'm also seeingUnavailableShardsExceptionwith 0.17.4. I did not
see it with 0.16.5.

I started a test with a clean data directory, single node, created a
couple of indexes (one with five shards and another with ten) and
verified elasticsearch-head showed all was Yellow (since no replicas).

Then I tried adding a document but got that exception:

curl -XPUThttp://localhost:9200/five/named/1234-d'{"named":
{"context": "Domain001/Bucket0001", "name": "File612606243717652",
"size": "90803308" }}'

{"error":"UnavailableShardsException[[five][3] [3] shardIt, [1]
active : Timeout waiting for [1m], request: index {[five][named]
[1234], source[{....

So I killed java and restarted, this is all that got logged:

...
[2011-08-11 18:48:46,383][INFO ][node ] [Mantra]
{elasticsearch/0.17.4}[14437]:
started
[2011-08-11 18:48:46,399][INFO ][gateway ] [Mantra]
recovered [2] indices into
cluster_state

And now cluster health is stuck in red:

curl -XGET 'http://localhost:9200/_cluster/health'

{"cluster_name":"mytest","status":"red","timed_out":false,"number_of_nodes" :
1,"number_of_data_nodes":1,"active_primary_shards":0,"active_shards":
0,"relocating_shards":0,"initializing_shards":0,"unassigned_shards":
45}

Same problem after another restart.

Btw elasticsearch-head shows 3 (why not 2?) replicas, all Unassigned.

Any ideas?

--Jamshid

On Aug 11, 4:27 pm, Shay Banon kim...@gmail.com wrote:

It waits for green status for a timeout, and then returns. It returns
what
the status is now, and a flag indicating if it timed out. We don't want
to
block forever :slight_smile:

On Fri, Aug 12, 2011 at 12:03 AM, ogregras ogreg...@gmail.com wrote:

You know better than me!

It's just a little bit odd that setWaitForGreenStatus() returns and
the

status is not green! :slight_smile:

But currently everything seems to be running well. So thanks again for
the

help!


(Shay Banon) #15

How many nodes did you have allocated? By default, elasticsearch expects a
quorum of shard and replicas to be allocated in order to allow for writes.
In your first example, it expects 2 to be allocated per replication group /
partition. Check write consistency here:
http://www.elasticsearch.org/guide/reference/api/index_.html.

On Wed, Aug 17, 2011 at 6:19 PM, lecochien rgarcon@voisins-super.fr wrote:

Hello,
I've receive the same error (UnavailableShardsException) when i'm
trying to create an index with 0.17.6 and a s3 gateway.
the first time my index settings was :
"settings" : {
"index" : {
"number_of_shards" : 3,
"number_of_replicas" : 2,
And it doesn't work.
the second time i've changed the settings to :
"settings" : {
"index" : {
"number_of_shards" : 3,
"number_of_replicas" : 1,
and it's worked.
Maybe it could help you..
bye.
(sorry for my bad english... :wink:

On 15 août, 05:48, Jamshid jamshi...@gmail.com wrote:

I tried reproducing on 0.17.4 and was not able to. I'll upgrade to
0.17.6 and try to get more information if I see it again.

Thanks,
Jamshid

On Aug 12, 9:35 am, Shay Banon kim...@gmail.com wrote:

Can you post a curl recreation from "clean data" and notes when to stop
the

server and start it?

On Fri, Aug 12, 2011 at 3:07 AM, Jamshid jamshi...@gmail.com wrote:

FYI I'm also seeingUnavailableShardsExceptionwith 0.17.4. I did not
see it with 0.16.5.

I started a test with a clean data directory, single node, created a
couple of indexes (one with five shards and another with ten) and
verified elasticsearch-head showed all was Yellow (since no
replicas).

Then I tried adding a document but got that exception:

curl -XPUThttp://localhost:9200/five/named/1234-d'{"named":
{"context": "Domain001/Bucket0001", "name": "File612606243717652",
"size": "90803308" }}'

{"error":"UnavailableShardsException[[five][3] [3] shardIt, [1]
active : Timeout waiting for [1m], request: index {[five][named]
[1234], source[{....

So I killed java and restarted, this is all that got logged:

...
[2011-08-11 18:48:46,383][INFO ][node ] [Mantra]
{elasticsearch/0.17.4}[14437]:
started
[2011-08-11 18:48:46,399][INFO ][gateway ] [Mantra]
recovered [2] indices into
cluster_state

And now cluster health is stuck in red:

curl -XGET 'http://localhost:9200/_cluster/health'

{"cluster_name":"mytest","status":"red","timed_out":false,"number_of_nodes"
:

1,"number_of_data_nodes":1,"active_primary_shards":0,"active_shards":
0,"relocating_shards":0,"initializing_shards":0,"unassigned_shards":
45}

Same problem after another restart.

Btw elasticsearch-head shows 3 (why not 2?) replicas, all Unassigned.

Any ideas?

--Jamshid

On Aug 11, 4:27 pm, Shay Banon kim...@gmail.com wrote:

It waits for green status for a timeout, and then returns. It
returns

what

the status is now, and a flag indicating if it timed out. We don't
want

to

block forever :slight_smile:

On Fri, Aug 12, 2011 at 12:03 AM, ogregras ogreg...@gmail.com
wrote:

You know better than me!

It's just a little bit odd that setWaitForGreenStatus() returns
and

the

status is not green! :slight_smile:

But currently everything seems to be running well. So thanks
again for

the

help!


(system) #16