Too_many_clauses: maxClauseCount is set to 1024

SonarQube Server / Community Build
1

On a multi-branch project, when I reach 1025 branches, the UI display “An error has occurred. Please contact your administrator” and log showing “too_many_clauses: maxClauseCount is set to 1024”

  • Version 6.7.6 (build 38781)
  • Branch plugin 1.0 (build 507)
Caused by: org.elasticsearch.common.io.stream.NotSerializableExceptionWrapper: too_many_clauses: maxClauseCount is set to 1024
sonarqube    |  at org.apache.lucene.search.BooleanQuery$Builder.add(BooleanQuery.java:125)
sonarqube    |  at org.apache.lucene.search.BooleanQuery$Builder.add(BooleanQuery.java:138)
sonarqube    |  at org.elasticsearch.index.query.TermsQueryBuilder.handleTermsQuery(TermsQueryBuilder.java:453)
sonarqube    |  at org.elasticsearch.index.query.TermsQueryBuilder.doToQuery(TermsQueryBuilder.java:414)
sonarqube    |  at org.elasticsearch.index.query.AbstractQueryBuilder.toQuery(AbstractQueryBuilder.java:96)
sonarqube    |  at org.elasticsearch.index.query.BoolQueryBuilder.addBooleanClauses(BoolQueryBuilder.java:444)
sonarqube    |  at org.elasticsearch.index.query.BoolQueryBuilder.doToQuery(BoolQueryBuilder.java:418)
sonarqube    |  at org.elasticsearch.index.query.AbstractQueryBuilder.toQuery(AbstractQueryBuilder.java:96)
sonarqube    |  at org.elasticsearch.index.query.QueryShardContext.lambda$toQuery$1(QueryShardContext.java:313)
sonarqube    |  at org.elasticsearch.index.query.QueryShardContext.toQuery(QueryShardContext.java:325)

I tried the following settings in sonar.properties

sonar.search.javaAdditionalOpts=-Dindices.query.bool.max_clause_count=2048

I also tried in elasticsearch.yml

indices.query.bool.max_clause_count: '2048'

neither of them would let me to override the limit.

Please advise.

28%20PM
Screen Shot 2019-03-08 at 1.05.28 PM.png2840×1604 206 KB

2

Hi,

Could you please explain your use case for having more than 1024 branches?

 
Ann

3

I am working with Bing on this issue, it turns out the auto purge of short live branches stops working. So all inactivity PRs are not removed beyond their retentionn time.

Which log can we lookup?

also we are able to restore our sonarq server from previous day, and able to bring back the ui screen. This is where we find out the PR branches are not purged

also try to switch the retentions between 1 and 3 days do not fix the issue

5

Hi Dan,

It will be fixed in 7.7 (SONAR-11439) but in versions before that, only analysis of the master branch triggers housekeeping. Are you (as I suspect) not analyzing the master branch very often? If so, running an analysis should clear out the old PRs and short-lived branches.

 
Ann

6

We are toasted :(. We no longer use master branch. we have a large source tree with many teams. Every new release rolling out new master-xxx branch. is there any other trick to do the clean up.?

Also we dont plan to upgrade to sonar 7.x unless it is LTS version

7

Hi,

Whether or not you use the master branch, all you need to do to make housekeeping kick in is to run an analysis of the project where you do not pass sonar.branch.name. It will be seen as “master” and the housekeeping routines will go to work.

 
:slight_smile:
Ann

8

It works!!

we will need scheduled Jenkins jobs as a workaround for a number of projects.

since this bug is so fatal to LTS customers, can we have the fix at 7.x backport to 6.x ?

9

Hi,

I’m glad you’ve got this working. I don’t anticipate a backport; there’s a perfectly reasonable workaround.

 
:slight_smile:
Ann

10

Ouch!! When 7.x will become LTS?

11

We’re targeting the end of May.

1 Like