Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating a duplicate mapping throws the whole cluster #39

Closed
clintongormley opened this issue Feb 22, 2010 · 3 comments
Closed

Creating a duplicate mapping throws the whole cluster #39

clintongormley opened this issue Feb 22, 2010 · 3 comments

Comments

@clintongormley
Copy link

Hiya

I'm starting 3 nodes, then creating a mapping, then creating a duplicate (with ignoreDuplicate=false).

It is sufficient to throw the whole cluster out. It doesn't seem to recover.

Run this script a few times, and watch the server logs:

#!/bin/bash
curl -XGET 'http://127.0.0.1:9200/_cluster/nodes' 
curl -XDELETE 'http://127.0.0.2:9202/es_test_1/' 
curl -XPUT 'http://127.0.0.2:9202/es_test_1,es_test_2/test/_mapping?ignoreDuplicates=false'  -d '
{
   "properties" : {
      "num" : {
         "type" : "integer"
      },
      "text" : {
         "type" : "string"
      }
   }
}
'
curl -XPUT 'http://127.0.0.2:9202/es_test_1,es_test_2/test/_mapping?ignoreDuplicates=false'  -d '
{
   "properties" : {
      "num" : {
         "type" : "integer"
      },
      "text" : {
         "type" : "string"
      }
   }
}
'
curl -XPUT 'http://127.0.0.2:9202/es_test_1,es_test_2/test_2/_mapping?ignoreDuplicates=false'  -d '
{
   "properties" : {
      "num" : {
         "type" : "integer"
      },
      "text" : {
         "type" : "string"
      }
   }
}
'
curl -XDELETE 'http://127.0.0.2:9202/es_test_1/' 
curl -XDELETE 'http://127.0.0.2:9202/es_test_2/' 
curl -XPUT 'http://127.0.0.2:9202/es_test_1/'  -d '
{}
'
curl -XPUT 'http://127.0.0.2:9202/es_test_2/'  -d '
{}
'
curl -XPUT 'http://127.0.0.2:9202/_all/type_1/_mapping?ignoreDuplicates=false'  -d '
{
   "properties" : {
      "num" : {
         "store" : "yes",
         "type" : "integer"
      },
      "text" : {
         "store" : "yes",
         "type" : "string"
      }
   }
}
'
curl -XPUT 'http://127.0.0.2:9202/_all/type_2/_mapping?ignoreDuplicates=false'  -d '
{
   "properties" : {
      "num" : {
         "store" : "yes",
         "type" : "integer"
      },
      "text" : {
         "store" : "yes",
         "type" : "string"
      }
   }
}
'
curl -XPOST 'http://127.0.0.2:9202/_flush?refresh=true' 
@kimchy
Copy link
Member

kimchy commented Feb 23, 2010

Fixed one issue, where the proper exception was not raised (actually serialized) since you have ignoreDuplicates to false. Trying to recreate the problem you posted.

@kimchy
Copy link
Member

kimchy commented Feb 28, 2010

Hopefully, its fixed now. Since the allocation of shards is async, the create/delete/create/delete cycle caused the delete api to hand in the ack phase. Can you give it a go? (note, I added a cluster health API where you can wait for the cluster to get to a certain state)

@clintongormley
Copy link
Author

This looks like it has been fixed

dadoonet pushed a commit that referenced this issue Jun 5, 2015
This change will allow EC2 API to filter by tags, AZ, and instance state.  In the situation where you have a large number of instances/reservations, this can be a performance boost.

Note that we still do the security group filter locally due to the different strategies (all or some must match).

Closes #39.
johtani added a commit that referenced this issue Jun 5, 2015
rmuir pushed a commit to rmuir/elasticsearch that referenced this issue Nov 8, 2015
If you define some specific mapping for your file content, such as the following:

```javascript
{
    "person": {
        "properties": {
            "file": {
                "type": "attachment",
                "path": "full",
                "fields": {
                    "date": { "type": "string" }
                }
            }
        }
    }
}
```

And then, if you ask back the mapping, you get:

```javascript
{
   "person":{
      "properties":{
         "file":{
            "type":"attachment",
            "path":"full",
            "fields":{
               "file":{
                  "type":"string"
               },
               "author":{
                  "type":"string"
               },
               "title":{
                  "type":"string"
               },
               "name":{
                  "type":"string"
               },
               "date":{
                  "type":"date",
                  "format":"dateOptionalTime"
               },
               "keywords":{
                  "type":"string"
               },
               "content_type":{
                  "type":"string"
               }
            }
         }
      }
   }
}
```

All your settings have been overwrited by the mapper plugin.

See also issue elastic#22 where the issue was found.

Closes elastic#39.
ywelsch pushed a commit to ywelsch/elasticsearch that referenced this issue May 24, 2018
It is sometimes challenging to work out the sequence of events that led to a
test failure, and a contributing factor is that scheduled tasks are identified
only by their scheduled time and not by any more useful identifier. This change
adds simple descriptions to these tasks to help untangle things a bit.
henningandersen pushed a commit to henningandersen/elasticsearch that referenced this issue Jun 4, 2020
With this commit we implement the property `pecent_completed` on the
Elasticlogs bulk source to provide an informational progress indication
for the challenge `index-logs-fixed-daily-volume`. Because we cannot
specify a total number of iterations or a specific time-period we need
to rely on feedback from the generator when all data has been ingested
and thus we also need to rely on the generator to indicate progress.

Relates elastic#39
cbuescher pushed a commit to cbuescher/elasticsearch that referenced this issue Oct 2, 2023
With this commit we add a new ML-related challenge to our benchmarks.

Closes elastic#39
Relates elastic#84
cbuescher pushed a commit to cbuescher/elasticsearch that referenced this issue Oct 2, 2023
With this commit we ensure that ML-related benchmarks can be run for all
release benchmarks starting with Elasticsearch 5.4.0.

Relates elastic#39
Relates elastic#85
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants