Bug or feature? WaitSet and friends

Have a great idea for extending Zimbra? Share ideas, ask questions, contribute, and get feedback.
Post Reply
leading zero
Posts: 35
Joined: Fri Apr 21, 2023 9:37 am
Location: Germany
ZCS/ZD Version: 10.0.3

Bug or feature? WaitSet and friends

Post by leading zero »

Hi everyone,

one problem that had me stumped for a while now is how ZCS handles WaitSets (on ZCS 10.0.2 NE).
I'm trying to use the [Admin]WaitSet SOAP method with expand=true to receive a detailed list of changes since the last WaitSet call.
After a lot of tinkering, I was somewhat successful. (I may post a mini-tutorial in the near future because other forum users seemed to have issues with WaitSets too.)

In [Admin]WaitSetResponse, I receive all the needed details for changes that happend since the last call. Just as I wanted.
However, if there were several changes in an account, only the first change is reported. Later changes within the same account are not contained in the response.

Example:
1. I create a WaitSet for account foobar@myzimbra using the AdminCreateWaitSet method.
2. I call the AdminWaitSet method - no changes reported (correct).
3. foobar@myzimbra receives an email.
4. foobar@myzimbra receives a second email.
5. I call the AdminWaitSet method - I would expect to get details on both emails. But the response contains information for the first email only (the one from step 3). It looks like this:

Code: Select all

 <AdminWaitSetResponse waitSet="WaitSet-6750f240-56cc-4f3d-a6bf-872271d78bbb" seq="8" xmlns="urn:zimbraAdmin">
    <a id="b37671eb-9339-4946-bc70-e022bf9ce014" changeid="21501">
       <mods id="2" xmlns="urn:zimbra">
          <created xmlns="urn:zimbraMail">
             <m t="MESSAGE" i4uid="637" f="1073742336" tn="" id="637"/>
          </created>
       </mods>
    </a>
 </AdminWaitSetResponse>
Calling AdminWaitSet with the new seq value yields an empty result. So the information for the second email is simply lost.

Using remote debugging (yay for open source software!), I think I tracked it down to this code in SomeAccountsWaitSet.signalDataRead():
zimbra-SomeAccountsWaitSet.signalDataRead.png
zimbra-SomeAccountsWaitSet.signalDataRead.png (22.48 KiB) Viewed 4420 times

Which I read as: "Only if there are no previous modifications logged for this account, add the current modification to the WaitSet".
That's because the variable mCurrentSignalledAccounts is a java.util.HashSet, so add() only returns true if the key is not yet present in the HashSet.

Thus, only one modification per account makes it into the WaitSetResponse.
That's a bummer for me. Because even though I plan on using AdminWaitSetRequest with block=1 in an endless loop, there may still be single modifications (within an account) getting lost due to race conditions.

Does anyone know if this is intentional or a bug?
The API docs describe /a/mods/created as a "list of created items", so I assume this is a bug. Because as I see it, /a/mods/created can never contain more than one item. Actually, even /a/mods can never contain more than one item.

Any thoughts on this?
Thanks!
Post Reply