# In Dev Tools Console, \_reindex gets error of Client request timeout

**URL:** https://discuss.elastic.co/t/in-dev-tools-console-reindex-gets-error-of-client-request-timeout/337920
**Category:** Elasticsearch
**Tags:** reindex
**Created:** [July 7, 2023, 10:18pm UTC](https://discuss.elastic.co/t/in-dev-tools-console-reindex-gets-error-of-client-request-timeout/337920 "2023-07-07T22:18:56Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![Mike\_Z](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mike_z/32/122216_2.png) [@Mike\_Z](https://discuss.elastic.co/u/Mike_Z)
#### Post date: [July 7, 2023, 10:18pm UTC](https://discuss.elastic.co/t/in-dev-tools-console-reindex-gets-error-of-client-request-timeout/337920/1 "2023-07-07T22:18:56Z")

</div>

When trying to duplicate an index by the `_reindex` command, it always gets an error saying "502, Bad Gateway" and "Client request timeout".

However, the command `GET _cat/indices/_all` shows, right after the above error, that the destination index exists.

We noticed that the resulted destination index is slightly different in size compared with the source index. The difference was 158.8mb vs. 149.5mb.

We tried the `_reindex` command on a smaller source index before, and it successfully finished without any error, and the size appeared equal between the source and destination indices. The smaller index before was 80.8mb in size.

**The sample commands and outputs:**

```shell
POST /_reindex
{
  "source": {
    "index": "my-index-000001"
  },
  "dest": {
    "index": "dest"
  }
}
# Result:
# {
# "statusCode": 502,
# "error": "Bad Gateway",
# "message": "Client request timeout"
# }

GET _cat/indices/_all
# Result:
# yellow open dest YUBT2IhRQGSnnIFPrtaI_Q 1 1 248013 0 158.8mb 158.8mb
# yellow open my-index-000001 J_ttsV5kRrSnX5_iufQD-Q 1 1 257303 0 149.5mb 149.5mb

```

**Our Questions:**

- Why did the `_reindex` command get the timeout error in the above test case?
- Why the size of the destination index got different from the source?

We are new to Elasticsearch, and we highly appreciate any hints and suggestions.

---

<div class="post-metadata">

### Author: ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)
#### Post date: [July 8, 2023, 12:27am UTC](https://discuss.elastic.co/t/in-dev-tools-console-reindex-gets-error-of-client-request-timeout/337920/2 "2023-07-08T00:27:03Z")

</div>

Hi @Mike_Z you are probably timing out so perhaps try.

`wait_for_completion=false`

Which is really what you want to do anyways. You will get a task id which then you can check the status using the [task API](https://www.elastic.co/guide/en/elasticsearch/reference/current/tasks.html)

Although 150mb is pretty small so perhaps some other reason but that is what I would try first.

> [@Mike\_Z](#):
>
> We noticed that the resulted destination index is slightly different in size compared with the source index. The difference was 158.8mb vs. 149.5mb.

You are not guaranteed the resulting index will be the exact same size in bytes as the source as they may have a different number of segments etc.

Unless you force merge both down to 1 segment after everything is done will they be the same size.

I would look closely at [the documents](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-reindex.html) as there are many options to optimize reindex for large indices

---

<div class="post-metadata">

### Author: ![Mike\_Z](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mike_z/32/122216_2.png) [@Mike\_Z](https://discuss.elastic.co/u/Mike_Z)
#### Post date: [July 10, 2023, 4:06pm UTC](https://discuss.elastic.co/t/in-dev-tools-console-reindex-gets-error-of-client-request-timeout/337920/3 "2023-07-10T16:06:40Z")

</div>

Thank you, @stephenb .

We tried the following command, and it returned right away, and the timeout did not appear.

```shell
POST /_reindex?wait_for_completion=false
{
  "source": {
    "index": "my-index-000001"
  },
  "dest": {
    "index": "sets-no-wait"
  }
}

```

After return, the index copying was still in progress, so by the command `GET _cat/indices/_all`, we saw the destination index keep increasing in size until done.

---

<div class="post-metadata">

### Author: ![Mike\_Z](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mike_z/32/122216_2.png) [@Mike\_Z](https://discuss.elastic.co/u/Mike_Z)
#### Post date: [July 10, 2023, 4:22pm UTC](https://discuss.elastic.co/t/in-dev-tools-console-reindex-gets-error-of-client-request-timeout/337920/4 "2023-07-10T16:22:16Z")

</div>

By the way, I have a related question to follow up.

I think the timeout happens on the Kibana, right? If yes, where can we find the log events?

So, I logged into the container by the command `docker exec -u root -it kibana /bin/bash`, and looked for the log files in `/var/log/`, but did not find anything.

```shell
root@51b2363988cb:/var/log# tree
.
|-- alternatives.log
|-- apt
| |-- eipp.log.xz
| |-- history.log
| `-- term.log
|-- bootstrap.log
|-- btmp
|-- dpkg.log
|-- faillog
|-- fontconfig.log
|-- lastlog
`-- wtmp

1 directory, 11 files

```

---

<div class="post-metadata">

### Author: ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)
#### Post date: [July 10, 2023, 4:38pm UTC](https://discuss.elastic.co/t/in-dev-tools-console-reindex-gets-error-of-client-request-timeout/337920/5 "2023-07-10T16:38:04Z")

</div>

The Docker container writes to stdout I believe... so you need to look there...

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)
#### Post date: [August 7, 2023, 4:38pm UTC](https://discuss.elastic.co/t/in-dev-tools-console-reindex-gets-error-of-client-request-timeout/337920/6 "2023-08-07T16:38:49Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
