Problem
It is possible to construct filters on the aggregate list that result in a large number of aggregates (> 1000). To display these aggregates on the aggregate list, they need to be retrieved from the customerdata service. This is achieved by sending an OData compliant message to the customerdata service, which consists of a filter looking like this:
http://<host>:<port>/customerdata/api/v1/Aggregates?$filter=(aggregateId = <...>) or (aggregateId = <...>) or ...)
When there are many aggregates (> 1000) this results in a very large call. The construction of this call, and the processing on the customerdata service side crashes when the number is larger than 1000 (it depends on the operating system and Java installation on what number exactly).
Solution
Please reconsider the modelling of the aggregate list and its filters to see if is possible to further limit the number of aggregates for that list. In most cases it does not make sense to model an aggregate list that displays so many records and if it does, it is likely to negatively impact the performance. When in doubt, please contact Blueriq support for help or discussing alternatives.
Workaround
The steps below provide a workaround for the described problem. However, it is strongly discouraged to use this workaround in production as it can negatively impact the performance of the whole Blueriq Runtime. You are advised to measure the (increased) memory usage of the Blueriq Runtime and Customerdata service and (re)size the RAM of the system accordingly. Blueriq cannot and will not guarantee acceptable performance with this workaround.
The values for the parameters described below are established with a test for 6000 aggregates, on a Windows machine with the latest Java 8 version. The values specific to your environment may need additional tuning. In case they don't suffice, start by doubling them and try again.
To be able to handle more than 1000 aggregates, the following steps need to be performed:
1. Increase the stack size available to Java for both the Runtime and the customerdata service
To increase the default stack size available to Java, the following JVM parameter can be used.
-Xss16M
In this case, the stack size is set to 16 MB. This parameter needs be set for both the Runtime and the customerdata service. Please consult the documentation of your application server how to set this parameter on startup.
2. Increase the max http header size of the customerdata service
In the configuration of the customerdata service application.yml, located in the
spring.config.additional-locationserver: max-http-header-size: 256000
Overview
Content Tools
1 Comment
Jörg Mutter
On JBoss 6.4 we also had to add a property in the standalone.xml:
<system-properties>
.......
<property name="org.apache.coyote.http11.Http11Protocol.MAX_HEADER_SIZE" value="256000"/>
</system-properties>