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

asked 21.11.2019 at 10:28

peters's gravatar image

peters
(suspended)
accept rate: 0%

can it be that field is defined as big decimal or number in the java object tree?

(22.11.2019 at 02:44) Reguel Werme... ♦♦ Reguel%20Wermelinger's gravatar image

there have been various issues addressed with business data and index re-creation. I'd definitively update to 7.0.14 if you are facing re-creation issues: https://developer.axonivy.com/releases/ivy/7.0.14/documents/ReleaseNotes.txt

(22.11.2019 at 03:14) Reguel Werme... ♦♦ Reguel%20Wermelinger's gravatar image

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%20Wermelinger's gravatar image

Reguel Werme... ♦♦
9.4k31958
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:

  1. Why is there a different object reported for every re-indexing run?
  2. 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?
  3. 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 peters's gravatar image
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... ♦♦ Reguel%20Wermelinger's gravatar image

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "Title")
  • image?![alt text](/path/img.jpg "Title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×22
×17
×2

Asked: 21.11.2019 at 10:28

Seen: 3,092 times

Last updated: 05.12.2019 at 05:31