Too_many_clauses: maxClauseCount is set to 1024


(Bing Shiao) #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.


(G Ann Campbell) #2

Hi,

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

 
Ann


(Dan Tran) #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


(G Ann Campbell) #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


(Dan Tran) #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


(G Ann Campbell) #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


(Dan Tran) #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 ?


(G Ann Campbell) #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


(Dan Tran) #10

Ouch!! When 7.x will become LTS?


(G Ann Campbell) #11

We’re targeting the end of May.