maxClauseCount

[roberth55706517]

I have a client where they have been talked into using AEM and scene7 as a warehouse for their images. We have run into a snag where some users are getting an exception that displays in the left toolbar stating that the maxClauseCount has been breached and that the current count is 1024. Once this happens, the UI is in an unusable state where you are unable to navigate anywhere and if you are impersonating them, the admin account can't revert back to themselves either. I found the solrconfig.xml in the CRX/DE tree and changed the MaxBooleanClauses to 10240, yes excessive I know, and added a maxClauseCount of the same value. I then restarted the AEM but there was no change in behavior. Since this does not affect all users, what should I look for that may be specific to the users having the problem?

[smacdonald2008]

What AEM version are you using - is it possible to post a screenshot so the community can see the exact behaviour. 

[roberth55706517]

smacdonald2008 wrote...

What AEM version are you using - is it possible to post a screenshot so the community can see the exact behaviour. 

This is AEM 6.1.

[Sham_HC]

The error indicates you have query that has more than 1024 Or conditions.  So query is not optimized. If it is oob query then need a fix. PLease file a support ticket with logs of exact query fired.

[roberth55706517]

The client has three instances of the AEM. One for development, one for user acceptance testing(UAT), and one for production. The only instance we are having this problem on is in UAT and it is only specific users. I can log in as the administrator and my user with no problems. Several users, however, run into the maxClauseCount exception. I understand what the issue is. The big question is where is this information that is causing the problem stored? I've also had issues where I created and saved a search. It worked great when I first created but when I try to reuse that search, I get a similar issue and it breaks the UI. If I share the search globally, it breaks the UI for everyone.

[roberth55706517]

Sham HC wrote...

The error indicates you have query that has more than 1024 Or conditions.  So query is not optimized. If it is oob query then need a fix. PLease file a support ticket with logs of exact query fired.

With all due respect, sorry but I don't accept this as being solved.

It is, however, a shorter explanation of the problem but I wouldn't consider it the resolution. Also it isn't very helpful for the community.

[smacdonald2008]

When support (sham is support) asks you to log a ticket - there is an issue that is typically beyond community to suggest how to fix. It is typically some sort of bug where support will help you and advance to ENg team if required. All of the threads I ahve read about this states that the setting in the xml should fix this. But since it does not - I suspect there may be some sort of query bug.  

[roberth55706517]

A little update:

This is being caused by the code in /apps/cq/gui/components/endor/badge/badge.jsp. When it gathers the inbox items, it sends in a blank filter to the WorkflowSession.getActiveInboxItems(long start, long maxItems, ItemFilter filter) method. That means that about the only thing filtered on might be the current user. The maxItems value is set to 3 but the underlying query does not use this to limit the number of items it retrieves but only returns the number of items requested out of all of the items found. If the code were to use the maxItems value to limit the initial returned set, then the code would be much more efficient and wouldn't break things.

Now the thing to find is where the code is looking for the maxClauseCount setting to be. I can either increase that or manually delete some of the inbox items but neither are a good solution.

[roberth55706517]

smacdonald2008 wrote...

When support (sham is support) asks you to log a ticket - there is an issue that is typically beyond community to suggest how to fix. It is typically some sort of bug where support will help you and advance to ENg team if required. 

True but it doesn't help the community much.

Maybe ask the ENg team where I need to set the maxClauseCount so I can move forward until they fix it. You may send my update on what I found to them.

[smacdonald2008]

I will pass this to them. How the process of logging a  bug  does helps the community  because when the support team finds issues - they create KB articles that in return gets distributed in community. This one is a strange issue. It may be a bug or design issue. 

[roberth55706517]

smacdonald2008 wrote...

I will pass this to them. How the process of logging a  bug  does helps the community  because when the support team finds issues - they create KB articles that in return gets distributed in community. This one is a strange issue. It may be a bug or design issue. 

Whether it is called a bug or a design issue can be debated. I'd call it a bug due to bad design. I don't have the rights to create a ticket so I can't submit this as an item to Adobe. 

[smacdonald2008]

Did you see this blog entry:

http://blogs.adobe.com/dmcmahon/tag/maxclausecount/

It provides a workaround of getting smaller result sets in the query. 

I have passed this one to internal Adobe people. 

[roberth55706517]

I've seen that and several others. The problem is that the query isn't in any code I can control. It is deeper in the com.day.cq.workflow.WorkflowSessionImpl class. Or some other class it calls to get the inbox items. Thus why I ended up here.

[Sham_HC · Accepted solution]

5.6.1 & AEM6 had issue . Tracked at GRANITE-3909 which is resolved through hotfix NPR-3590.  AEM 6.1 includes the fix.  File an support ticket with logs & query triggered will help to find is product issue or other.    Generally it happens if you have nested groups & get into redundant or conditions. 

[roberth55706517]

Sham HC wrote...

5.6.1 & AEM6 had issue . Tracked at GRANITE-3909 which is resolved through hotfix NPR-3590.  AEM 6.1 includes the fix.  File an support ticket with logs & query triggered will help to find is product issue or other.    Generally it happens if you have nested groups & get into redundant or conditions. 

So the problem that I see is that there are over 1024 tasks for given groups. How much nesting is too much? Is it also a problem when users are in multiple groups? It still seems to me that the code could be smarter so that it doesn't come close to the limit when I only want 3 records. There will still be a problem with the task list form. That form should show all of the tasks or have a way to view a subset at a time.

[roberth55706517]

roberth55706517 wrote...

Sham HC wrote...

5.6.1 & AEM6 had issue . Tracked at GRANITE-3909 which is resolved through hotfix NPR-3590.  AEM 6.1 includes the fix.  File an support ticket with logs & query triggered will help to find is product issue or other.    Generally it happens if you have nested groups & get into redundant or conditions. 

So the problem that I see is that there are over 1024 tasks for given groups. How much nesting is too much? Is it also a problem when users are in multiple groups? It still seems to me that the code could be smarter so that it doesn't come close to the limit when I only want 3 records. There will still be a problem with the task list form. That form should show all of the tasks or have a way to view a subset at a time.

Looking at the relationships, the users are in one or two groups that are members of another group that provides the needed permissions. I didn't want to have to duplicate all of the permissions for every group. Deepest inheritances is one parent. I still believe the root cause is too many inbox items.

[roberth55706517]

The nested group things doesn't work well. I'm a member of all of the groups and I don't have the issue crop up on my user account.

[roberth55706517]

I found the query that is causing the problem. This is being created somewhere way down in the code and I don't know how to change it or test a work around. 

Any ideas?

I found this by going into the diagnostics tools and looking at the query performance.