# Infinite loop in Elastic Search 0.19.9

**URL:** <https://discuss.elastic.co/t/infinite-loop-in-elastic-search-0-19-9/9369>\
**Category:** Elasticsearch\
**Created:** [October 16, 2012, 7:21am UTC](https://discuss.elastic.co/t/infinite-loop-in-elastic-search-0-19-9/9369 "2012-10-16T07:21:06Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Wojciech\_Durczynski](https://avatars.discourse-cdn.com/v4/letter/w/fbc32d/32.png) [@Wojciech\_Durczynski](https://discuss.elastic.co/u/Wojciech_Durczynski)\
**Post date:** [October 16, 2012, 7:21am UTC](https://discuss.elastic.co/t/infinite-loop-in-elastic-search-0-19-9/9369/1 "2012-10-16T07:21:06Z")

</div>

Hello.  
Recently our Elastic Search nodes started to use 100% CPU. Only way to  
solve this problem is to restart broken nodes.  
Stack traces usually contain following code:

"elasticsearch[Dark Phoenix][bulk][T#1]" daemon prio=10  
tid=0x00007f0748083800 nid=0x5e3c runnable [0x00007f07d740f000]  
java.lang.Thread.State: RUNNABLE  
at  
org.elasticsearch.common.collect.RegularImmutableMap.get(RegularImmutableMap.java:164)

```
    at 

```

org.elasticsearch.index.mapper.object.ObjectMapper.serializeValue(ObjectMapper.java:583)

```
    at 

```

org.elasticsearch.index.mapper.object.ObjectMapper.serializeArray(ObjectMapper.java:573)

```
    at 

```

org.elasticsearch.index.mapper.object.ObjectMapper.parse(ObjectMapper.java:441)

```
    at 

```

org.elasticsearch.index.mapper.object.ObjectMapper.serializeObject(ObjectMapper.java:497)

```
    at 

```

org.elasticsearch.index.mapper.object.ObjectMapper.parse(ObjectMapper.java:439)

```
    at 

```

org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:494)

```
    at 

```

org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:438)

```
    at 

```

org.elasticsearch.index.shard.service.InternalIndexShard.prepareIndex(InternalIndexShard.java:309)

```
    at 

```

org.elasticsearch.action.bulk.TransportShardBulkAction.shardOperationOnPrimary(TransportShardBulkAction.java:157)

```
    at 

```

org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction.performOnPrimary(TransportShardReplicationOperationAction.java:532)

```
    at 

```

org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$1.run(TransportShardReplicationOperationAction.java:430)

```
    at 

```

java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

```
    at 

```

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

```
    at java.lang.Thread.run(Thread.java:662) 

```

What's the problem?

--

---

<div class="post-metadata">

**Author:** ![mvg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mvg/32/98890_2.png) [@mvg](https://discuss.elastic.co/u/mvg)\
**Post date:** [October 16, 2012, 11:38am UTC](https://discuss.elastic.co/t/infinite-loop-in-elastic-search-0-19-9/9369/2 "2012-10-16T11:38:01Z")

</div>

Hi Wojciech,

How often does this happen? Does it usually happen during in a bulk  
import? If so with what options do you start a bulk import?  
Would be great if you somehow were able to reproduce this issue.

Martijn

On 16 October 2012 09:21, Wojciech Durczyński  
[wojciech.durczynski@comarch.com](mailto:wojciech.durczynski@comarch.com) wrote:

> Hello.  
> Recently our Elastic Search nodes started to use 100% CPU. Only way to solve  
> this problem is to restart broken nodes.  
> Stack traces usually contain following code:
> 
> "elasticsearch[Dark Phoenix][bulk][T#1]" daemon prio=10  
> tid=0x00007f0748083800 nid=0x5e3c runnable [0x00007f07d740f000]  
> java.lang.Thread.State: RUNNABLE  
> at  
> org.elasticsearch.common.collect.RegularImmutableMap.get(RegularImmutableMap.java:164)  
> at  
> org.elasticsearch.index.mapper.object.ObjectMapper.serializeValue(ObjectMapper.java:583)  
> at  
> org.elasticsearch.index.mapper.object.ObjectMapper.serializeArray(ObjectMapper.java:573)  
> at  
> org.elasticsearch.index.mapper.object.ObjectMapper.parse(ObjectMapper.java:441)  
> at  
> org.elasticsearch.index.mapper.object.ObjectMapper.serializeObject(ObjectMapper.java:497)  
> at  
> org.elasticsearch.index.mapper.object.ObjectMapper.parse(ObjectMapper.java:439)  
> at  
> org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:494)  
> at  
> org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:438)  
> at  
> org.elasticsearch.index.shard.service.InternalIndexShard.prepareIndex(InternalIndexShard.java:309)  
> at  
> org.elasticsearch.action.bulk.TransportShardBulkAction.shardOperationOnPrimary(TransportShardBulkAction.java:157)  
> at  
> org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction.performOnPrimary(TransportShardReplicationOperationAction.java:532)  
> at  
> org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$1.run(TransportShardReplicationOperationAction.java:430)  
> at  
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)  
> at  
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)  
> at java.lang.Thread.run(Thread.java:662)
> 
> What's the problem?
> 
> --

--  
Met vriendelijke groet,

Martijn van Groningen

--

---

<div class="post-metadata">

**Author:** ![mvg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mvg/32/98890_2.png) [@mvg](https://discuss.elastic.co/u/mvg)\
**Post date:** [October 16, 2012, 2:50pm UTC](https://discuss.elastic.co/t/infinite-loop-in-elastic-search-0-19-9/9369/3 "2012-10-16T14:50:04Z")

</div>

In version 0.19.10 improvements have been mode in the ObjectMapper  
class, to prevent endless looping. Can you check it out if the 100%  
cpu usage still occurs with version 0.19.10? Instead of endless  
looping an error should occur instead.

If the 100% CPU usage still occurs with the latest version, it is also  
helpful if you provide several full hot threads exports  
([http://localhost:9200/\_nodes/hot\_threads](http://localhost:9200/_nodes/hot_threads)). This helps to pin point  
the issue better.

Martijn

On 16 October 2012 13:38, Martijn v Groningen  
[martijn.v.groningen@gmail.com](mailto:martijn.v.groningen@gmail.com) wrote:

> Hi Wojciech,
> 
> How often does this happen? Does it usually happen during in a bulk  
> import? If so with what options do you start a bulk import?  
> Would be great if you somehow were able to reproduce this issue.
> 
> Martijn
> 
> On 16 October 2012 09:21, Wojciech Durczyński  
> [wojciech.durczynski@comarch.com](mailto:wojciech.durczynski@comarch.com) wrote:
> 
> > Hello.  
> > Recently our Elastic Search nodes started to use 100% CPU. Only way to solve  
> > this problem is to restart broken nodes.  
> > Stack traces usually contain following code:
> > 
> > "elasticsearch[Dark Phoenix][bulk][T#1]" daemon prio=10  
> > tid=0x00007f0748083800 nid=0x5e3c runnable [0x00007f07d740f000]  
> > java.lang.Thread.State: RUNNABLE  
> > at  
> > org.elasticsearch.common.collect.RegularImmutableMap.get(RegularImmutableMap.java:164)  
> > at  
> > org.elasticsearch.index.mapper.object.ObjectMapper.serializeValue(ObjectMapper.java:583)  
> > at  
> > org.elasticsearch.index.mapper.object.ObjectMapper.serializeArray(ObjectMapper.java:573)  
> > at  
> > org.elasticsearch.index.mapper.object.ObjectMapper.parse(ObjectMapper.java:441)  
> > at  
> > org.elasticsearch.index.mapper.object.ObjectMapper.serializeObject(ObjectMapper.java:497)  
> > at  
> > org.elasticsearch.index.mapper.object.ObjectMapper.parse(ObjectMapper.java:439)  
> > at  
> > org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:494)  
> > at  
> > org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:438)  
> > at  
> > org.elasticsearch.index.shard.service.InternalIndexShard.prepareIndex(InternalIndexShard.java:309)  
> > at  
> > org.elasticsearch.action.bulk.TransportShardBulkAction.shardOperationOnPrimary(TransportShardBulkAction.java:157)  
> > at  
> > org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction.performOnPrimary(TransportShardReplicationOperationAction.java:532)  
> > at  
> > org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$1.run(TransportShardReplicationOperationAction.java:430)  
> > at  
> > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)  
> > at  
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)  
> > at java.lang.Thread.run(Thread.java:662)
> > 
> > What's the problem?
> > 
> > --
> 
> --  
> Met vriendelijke groet,
> 
> Martijn van Groningen

--  
Met vriendelijke groet,

Martijn van Groningen

--

---

<div class="post-metadata">

**Author:** ![Wojciech\_Durczynski](https://avatars.discourse-cdn.com/v4/letter/w/fbc32d/32.png) [@Wojciech\_Durczynski](https://discuss.elastic.co/u/Wojciech_Durczynski)\
**Post date:** [October 16, 2012, 3:13pm UTC](https://discuss.elastic.co/t/infinite-loop-in-elastic-search-0-19-9/9369/4 "2012-10-16T15:13:41Z")

</div>

I checked version 0.19.10 and infinite loop is replaced by an error in this  
version.  
Thank you - this allows me to solve problems with my mapping.

W dniu wtorek, 16 października 2012 16:50:28 UTC+2 użytkownik Martijn v  
Groningen napisał:

> In version 0.19.10 improvements have been mode in the ObjectMapper  
> class, to prevent endless looping. Can you check it out if the 100%  
> cpu usage still occurs with version 0.19.10? Instead of endless  
> looping an error should occur instead.
> 
> If the 100% CPU usage still occurs with the latest version, it is also  
> helpful if you provide several full hot threads exports  
> ([http://localhost:9200/\_nodes/hot\_threads](http://localhost:9200/_nodes/hot_threads)). This helps to pin point  
> the issue better.
> 
> Martijn
> 
> On 16 October 2012 13:38, Martijn v Groningen  
> \<[martijn.v...@gmail.com](mailto:martijn.v...@gmail.com) \<javascript:\>\> wrote:
> 
> > Hi Wojciech,
> > 
> > How often does this happen? Does it usually happen during in a bulk  
> > import? If so with what options do you start a bulk import?  
> > Would be great if you somehow were able to reproduce this issue.
> > 
> > Martijn
> > 
> > On 16 October 2012 09:21, Wojciech Durczyński  
> > \<[wojciech....@comarch.com](mailto:wojciech....@comarch.com) \<javascript:\>\> wrote:
> > 
> > > Hello.  
> > > Recently our Elastic Search nodes started to use 100% CPU. Only way to  
> > > solve  
> > > this problem is to restart broken nodes.  
> > > Stack traces usually contain following code:
> > > 
> > > "elasticsearch[Dark Phoenix][bulk][T#1]" daemon prio=10  
> > > tid=0x00007f0748083800 nid=0x5e3c runnable [0x00007f07d740f000]  
> > > java.lang.Thread.State: RUNNABLE  
> > > at
> 
> org.elasticsearch.common.collect.RegularImmutableMap.get(RegularImmutableMap.java:164)
> 
> > > ```
> > > at 
> > > 
> > > ```
> 
> org.elasticsearch.index.mapper.object.ObjectMapper.serializeValue(ObjectMapper.java:583)
> 
> > > ```
> > > at 
> > > 
> > > ```
> 
> org.elasticsearch.index.mapper.object.ObjectMapper.serializeArray(ObjectMapper.java:573)
> 
> > > ```
> > > at 
> > > 
> > > ```
> 
> org.elasticsearch.index.mapper.object.ObjectMapper.parse(ObjectMapper.java:441)
> 
> > > ```
> > > at 
> > > 
> > > ```
> 
> org.elasticsearch.index.mapper.object.ObjectMapper.serializeObject(ObjectMapper.java:497)
> 
> > > ```
> > > at 
> > > 
> > > ```
> 
> org.elasticsearch.index.mapper.object.ObjectMapper.parse(ObjectMapper.java:439)
> 
> > > ```
> > > at 
> > > 
> > > ```
> 
> org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:494)
> 
> > > ```
> > > at 
> > > 
> > > ```
> 
> org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:438)
> 
> > > ```
> > > at 
> > > 
> > > ```
> 
> org.elasticsearch.index.shard.service.InternalIndexShard.prepareIndex(InternalIndexShard.java:309)
> 
> > > ```
> > > at 
> > > 
> > > ```
> 
> org.elasticsearch.action.bulk.TransportShardBulkAction.shardOperationOnPrimary(TransportShardBulkAction.java:157)
> 
> > > ```
> > > at 
> > > 
> > > ```
> 
> org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction.performOnPrimary(TransportShardReplicationOperationAction.java:532)
> 
> > > ```
> > > at 
> > > 
> > > ```
> 
> org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$1.run(TransportShardReplicationOperationAction.java:430)
> 
> > > ```
> > > at 
> > > 
> > > ```
> 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 
> > > ```
> > > at 
> > > 
> > > ```
> 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 
> > > ```
> > > at java.lang.Thread.run(Thread.java:662) 
> > > 
> > > ```
> > > 
> > > What's the problem?
> > > 
> > > --
> > 
> > --  
> > Met vriendelijke groet,
> > 
> > Martijn van Groningen
> 
> --  
> Met vriendelijke groet,
> 
> Martijn van Groningen

--

---

<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:** [July 6, 2017, 3:08am UTC](https://discuss.elastic.co/t/infinite-loop-in-elastic-search-0-19-9/9369/5 "2017-07-06T03:08:31Z")

</div>