Crazy autocomplete behaviour after p33

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
Post Reply
User avatar
gabrieles
Outstanding Member
Outstanding Member
Posts: 233
Joined: Tue Feb 14, 2017 9:40 am

Crazy autocomplete behaviour after p33

Post by gabrieles »

Hi all,
we are encountering a very strange autocomplete behaviour on a single customer.
It's a single server, Release 8.8.15_GA_3869.RHEL7_64_20190917004220 RHEL7_64 FOSS edition, Patch 8.8.15_P33.
Users have a lot of shared folders, many calendars, and three big contact lists shared to everyone.

This particular behaviour started after patching from p30 to p33, but we checked other identical installations and the problem did not emerged.
Maybe it's a simple time coincidence.

The main symptom is that the autocomplete is slow. Autocompletion that before were nearly in realtime now take 8/10 sec.
A more deep analisys showed that the autocomplete searches not only in contactlists, but EVEN IN CALENDARS.

In fact adding an accountLogger "zimbra.gal trace" to the problematic accounts gives:

Code: Select all

2022-12-02 15:00:23,062 DEBUG [qtp1704064279-46689://zmail.mydomain.com/service/soap/AutoCompleteRequest] [name=UNLUCKYUSER@mydomain.com;aname=AUTHENTICATEDADMIN@mydomain.com;mid=265;ip=192.168.XXX.XXX;port=38008;ua=ZimbraWebClient - GC106 (Linux)/8.8.15_GA_4372;soapId=393da7be;] gal - querying contact folders: (inid:7 OR underid:186888 OR inid:13 OR underid:220184 OR underid:115241 OR underid:420911 OR underid:115243 OR underid:115244 OR underid:115259 OR underid:115267 OR underid:115266 OR underid:115268 OR underid:115271 OR underid:115273 OR underid:115275 OR underid:115274 OR underid:135246 OR underid:115277 OR underid:115276 OR underid:135244 OR underid:115279 OR underid:135245 OR underid:115281 OR underid:135250 OR underid:135251 OR underid:115280 OR underid:115283 OR underid:135248 OR underid:115282 OR underid:135249 OR underid:115284 OR underid:135252 OR underid:115289 OR underid:115293 OR underid:115292 OR underid:115294 OR underid:415846 OR underid:135267 OR underid:415845 OR underid:135268 OR underid:135275 OR underid:135278 OR underid:135279 OR underid:415848 OR underid:135276 OR underid:135277 OR underid:135282 OR underid:135283 OR underid:135281 OR underid:135286 OR underid:135287 OR underid:135284 OR underid:135285 OR underid:135288 OR underid:135289 OR underid:135294 OR underid:135295 OR underid:135292 OR underid:135298 OR underid:415879 OR underid:352388 OR underid:135299 OR underid:135296 OR underid:135297 OR underid:135303 OR underid:135306 OR underid:135307 OR underid:135305 OR underid:135308 OR underid:307851 OR underid:357575 OR underid:167111 OR underid:167114 OR underid:167112 OR underid:357583 OR underid:167113 OR underid:357579 OR underid:357585 OR underid:357597 OR underid:410333 OR underid:357607 OR underid:357602 OR underid:357612 OR underid:357615 OR underid:357620 OR underid:187633 OR underid:357617 OR underid:357616 OR underid:357628 OR underid:114939 OR underid:114941 OR underid:114940 OR underid:114943 OR underid:114947 OR underid:357641 OR underid:357652 OR underid:357648 OR underid:357650 OR underid:336684 OR underid:186676 OR underid:135010 OR underid:354660 OR underid:135011 OR underid:135008 OR underid:135009 OR underid:135014 OR underid:135015 OR underid:135012 OR underid:354659 OR underid:354658 OR underid:135013 OR underid:135016 OR underid:135022 OR underid:135023 OR underid:135021 OR underid:135026 OR underid:135027 OR underid:135024 OR underid:135025 OR underid:135030 OR underid:135031 OR underid:135028 OR underid:135029 OR underid:135034 OR underid:135032 OR underid:135033 OR underid:135036 OR underid:304028 OR underid:417199 OR underid:279985 OR underid:290241 OR underid:422371 OR underid:396278)( "MYSEARCHTERM")
Folder 7 and 13 are contact lists, but other are mountpoints (type 13 on mysql) of shared contact lists and calendars. Of these mountpoints only 415845 415845 and
415848 are contactlists, all the other are calendars. Why search under calendars??
Another detail, only the correct folders are searched inid (search in that folder), all the others are searched underid (search in that folder and in the subfolders) making the query even heavier.

We tried the same test on a restored user (3rd party backup): same problem
Then tried on a freshly created new user: same problem, so it isn't a user preference or attribute

Given that the problem emerged with p33 we tested some other installation to see if it showed up on someone other: nothing.
Even identical installation, single server 8.8.15 FOSS p33 Centos 7.9 do the autocomplete correctly, searching only in contactlists:

Code: Select all

2022-12-01 10:10:45,019 DEBUG [qtp500772834-701963://mail.othercustomer.it/service/soap/AutoCompleteRequest] [name=anotheruser@anotherdomain.com.it;mid=167;oip=192.168.YYY.YYY;port=44824;ua=ZimbraWebClient - FF106 (Mac)/8.8.15_GA_4372;soapId=12cf7cab;] gal - querying contact folders: (inid:7 OR inid:13)( "other_search_term")
I've searched the release notes of the last patches and nothing is said about changes in autocomplete or similar.


What could it be?


(I've put "after p33" in the subject to point it to p33 but it could be anything, just to be more searchable.)
User avatar
gabrieles
Outstanding Member
Outstanding Member
Posts: 233
Joined: Tue Feb 14, 2017 9:40 am

Re: Crazy autocomplete behaviour after p33

Post by gabrieles »

Hi all
just an update. Drilling down this installation I found an exotic attribute that I'd never seen before.
This attribute seems to control exactly what is the current behaviour.

Code: Select all

[zimbra@zmail ~]$ zmprov desc -a zimbraGalAlwaysIncludeLocalCalendarResources
zimbraGalAlwaysIncludeLocalCalendarResources
    When set to TRUE, GAL search will always include local calendar
    resources regardless of zimbraGalMode.

               type : boolean
              value : 
           callback : 
          immutable : false
        cardinality : single
         requiredIn : 
         optionalIn : domain,globalConfig
              flags : domainAdminModifiable,domainInherited
           defaults : FALSE
                min : 
                max : 
                 id : 1093
    requiresRestart : 
              since : 6.0.7
    deprecatedSince : 
BUT nowhere in this installation I found it at TRUE, not in global, nor in domain config.
First thought was that this could be a new attribute introduced in a latest patch, but instead it seems very old: since : 6.0.7
The behaviour is common to the four domains in this installation, so it shoud be set a global config, but no, the attribute is not set.
Comparing this installation to other identical, I found it set to FALSE in many of them.
We tried to set to true, and reset to false. Nothing happened.

Inb4 zimbraGalMode: Following the description I checked even zimbraGalMode, is not set.

:(
KeyboardHammerer
Posts: 1
Joined: Tue Sep 05, 2023 5:23 pm

Re: Crazy autocomplete behaviour after p33

Post by KeyboardHammerer »

Did you have any succes resolving this issue?

One of our users is facing the exact same problems. But I haven't been able to find a solution.
Post Reply