Elastic Search index recreation fails inconsistently

Question

When re-starting the Ivy Engine (7.0.11), we found out, that elastic search index recreation fails everytime but with different objects.

We then tried to call DiCore.getGlobalInjector().getInstance(IBusinessDataManager.class).startIndexRecreation() directly multiple times and almost every time a different object is reported as having problems, eg:

first call:
bulk error: id=13a8e230cc9b47338d45e552678c1b10, index=ivy.businessdata-xxx.order, error={"type":"illegal_argument_exception","reason":"mapper [yyy.zzz] cannot be changed from type [float] to [long]"}

next call:
bulk error: id=0587301dfde5411a9caae3413ed25e7f, index=ivy.businessdata-xxx.order, error={"type":"illegal_argument_exception","reason":"mapper [yyy.zzz] cannot be changed from type [long] to [float]"}

next call:
bulk error: id=0271c00a7c5543c998bc81e5215e7949, index=ivy.businessdata-xxx.order, error={"type":"illegal_argument_exception","reason":"mapper [yyy.zzz] cannot be changed from type [long] to [float]"}

Please also note, that all three examples reference the same field of the same object type. How is this possible and how can we repair our index?

TIA

Accepted Answer

1

I assume that the field is a BigDecimal. There has been an issue with them if the first value, which was stored has been a non float number, such as BigDecimal(1). See https://jira.axonivy.com/jira/browse/XIVY-3463

The bug was addressed with 8.0 LTS and on the issue-report there is also a patch file for 7.0 LTS. So I'd advise you to migrate to the latest 7.0.14, apply the pre-liminary patch for bigDecimals and you should be fine. Please get in contact with our support to get the patch and advise how to apply it.

link

answered 22.11.2019 at 03:21

Reguel Werme... ♦♦
9.4k●3●19●58
accept rate: 70%

edited 05.12.2019 at 05:31

Hi Reguel,

yes, the fields (we have quite a lot of them) is BigDecimal. Thank you for noticing this!

I have some questions though:

Why is there a different object reported for every re-indexing run?
What is the effect of this error? Does it just mean, that we cannot search for this field or is the whole object not usable?
Because of other problems we had to switch from double to BigDecimal. This project is part of a larger installation and it is therefore not easy to go to 7.0.14. Is there any other way we could handle this problem?

(22.11.2019 at 06:25) peters

1

Hi Peter, you can install the pre-liminary patch for BigDecimal also for a 7.0.11 version. I'm not aware of any incompatibilities. The thing is, after installing the patch you will have to re-build the ElasticSearch index from scratch and reIndex all BusinessData. But the re-indexing feature is partially broken and there is no guarantee that it works unless you migrate to 7.0.14.

(25.11.2019 at 02:52) Reguel Werme... ♦♦

Elastic Search index recreation fails inconsistently

Follow this question

Related questions